SDK environment LDFLAGS problem?

SDK environment LDFLAGS problem?

[Patrick Turley]

I used the meta-toolchain-sdk recipe to produce an SDK, and I installed it. Here's an interesting line from the environment setup script:

  export LDFLAGS="-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed"

All these linker options are preceded by "-Wl", which indicates the SDK is *expecting* them to be given to gcc and then passed on to ld.

If you look at the help for the ld command line, all these options are available, but with the "-Wl," omitted. In fact, if you use these options exactly as shown here, ld will complain that they aren't recognized and fail.

So, the SDK is giving me a value of LDFLAGS that *cannot* be used with ld. Of course, the C compiler driver can link and produce executables, and that muddies the issue somewhat.

Here's an example where this is causing me real problems…

I'm building an external module against the kernel produced by Yocto. Here's an extract from my output:


make -C /home/pturley/yocto-mpu-build/tmp/work/dm8148_mpu-poky-linux-gnueabi/linux-ti81xx-psp-2.6.37-r0+spawnlabs+r0/git M=`pwd` ARCH=arm CROSS_COMPILE=/opt/poky/1.3/sysroots/x86_64-pokysdk-linux/usr/bin/armv7a-vfp-neon-poky-linux-gnueabi/arm-poky-linux-gnueabi- \
                EXTRA_CFLAGS="-DUSE_UDEV=1 -DMAX_POOLS=128" modules
.
.
.
  LD [M]  /home/pturley/z3-work/z3-centaurus-dm814x_RPS-20120626/ezsdk/component-sources/linuxutils_3_22_00_02/packages/ti/sdo/linuxutils/cmem/src/module/cmemk.ko
/opt/poky/1.3/sysroots/x86_64-pokysdk-linux/usr/bin/armv7a-vfp-neon-poky-linux-gnueabi/arm-poky-linux-gnueabi-ld: unrecognized option '-Wl,-O1'


As you can see here, the kernel Make files are interpreting LDFLAGS as something that *can* be given directly to ld, so they fail.


My questions are:

1) Has anyone else run into this before?

2) If so, how did you resolve it?

3) Since the Yocto kernel build is *not* failing, I infer that it is *not* using the ld options the SDK gives me. So, the Yocto kernel build has its own pathway through which it computes its value for LDFLAGS. Why would Yocto use its own SDK in a way that no user is expected to?

Re: SDK environment LDFLAGS problem?

[Eric Bénard]

Hi Patrick,

Le Tue, 15 Jan 2013 16:52:14 +0000,
Patrick Turley <PatrickTurley@gamestop.com> a écrit :
> 1) Has anyone else run into this before?
> 
> 2) If so, how did you resolve it?
> 
> 3) Since the Yocto kernel build is *not* failing, I infer that it is *not* using the ld options the SDK gives me. So, the Yocto kernel build has its own pathway through which it computes its value for LDFLAGS. Why would Yocto use its own SDK in a way that no user is expected to?
> 
to build a kernel using the SDK (so outside Yocto) you need to unset
LDFLAGS like :
LDFLAGS="" CROSS_COMPILE=arm-oe-linux-gnueabi- ARCH=arm make

When building the kernel inside oe-core that's done in
kernel.bbclass :
	unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS MACHINE

Eric

Re: SDK environment LDFLAGS problem?

[Brian Lloyd]

[-- Attachment #1: Type: text/plain, Size: 2853 bytes --]

The kernel is a special case, where the SDK is really designed for
developing user applications (which the kernel is not).

I found it pretty easy to create a kernel-module-MYMODULE.bbclass file
and build the kernel and module in the OE/Poky build system directly,
and then have it included in the image made for the device.

See
http://www.yoctoproject.org/docs/1.4/kernel-dev/kernel-dev.html#incorporating-out-of-tree-modules for details.

Brian

On Tue, 2013-01-15 at 16:52 +0000, Patrick Turley wrote:

> I used the meta-toolchain-sdk recipe to produce an SDK, and I installed it. Here's an interesting line from the environment setup script:
> 
>   export LDFLAGS="-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed"
> 
> All these linker options are preceded by "-Wl", which indicates the SDK is *expecting* them to be given to gcc and then passed on to ld.
> 
> If you look at the help for the ld command line, all these options are available, but with the "-Wl," omitted. In fact, if you use these options exactly as shown here, ld will complain that they aren't recognized and fail.
> 
> So, the SDK is giving me a value of LDFLAGS that *cannot* be used with ld. Of course, the C compiler driver can link and produce executables, and that muddies the issue somewhat.
> 
> Here's an example where this is causing me real problems…
> 
> I'm building an external module against the kernel produced by Yocto. Here's an extract from my output:
> 
> 
> make -C /home/pturley/yocto-mpu-build/tmp/work/dm8148_mpu-poky-linux-gnueabi/linux-ti81xx-psp-2.6.37-r0+spawnlabs+r0/git M=`pwd` ARCH=arm CROSS_COMPILE=/opt/poky/1.3/sysroots/x86_64-pokysdk-linux/usr/bin/armv7a-vfp-neon-poky-linux-gnueabi/arm-poky-linux-gnueabi- \
>                 EXTRA_CFLAGS="-DUSE_UDEV=1 -DMAX_POOLS=128" modules
> .
> .
> .
>   LD [M]  /home/pturley/z3-work/z3-centaurus-dm814x_RPS-20120626/ezsdk/component-sources/linuxutils_3_22_00_02/packages/ti/sdo/linuxutils/cmem/src/module/cmemk.ko
> /opt/poky/1.3/sysroots/x86_64-pokysdk-linux/usr/bin/armv7a-vfp-neon-poky-linux-gnueabi/arm-poky-linux-gnueabi-ld: unrecognized option '-Wl,-O1'
> 
> 
> As you can see here, the kernel Make files are interpreting LDFLAGS as something that *can* be given directly to ld, so they fail.
> 
> 
> My questions are:
> 
> 1) Has anyone else run into this before?
> 
> 2) If so, how did you resolve it?
> 
> 3) Since the Yocto kernel build is *not* failing, I infer that it is *not* using the ld options the SDK gives me. So, the Yocto kernel build has its own pathway through which it computes its value for LDFLAGS. Why would Yocto use its own SDK in a way that no user is expected to?
> 
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
> 



[-- Attachment #2: Type: text/html, Size: 3352 bytes --]

Re: SDK environment LDFLAGS problem?

[Patrick Turley]

[-- Attachment #1: Type: text/plain, Size: 3220 bytes --]


On Jan 15, 2013, at 11:38 AM, Brian Lloyd <blloyd@familyhonor.net<mailto:blloyd@familyhonor.net>>
 wrote:

The kernel is a special case, where the SDK is really designed for developing user applications (which the kernel is not).

Yes, it's clear to me that, in this one respect, the SDK is unsuitable for building kernels or kernel modules.

My point is that this is a problem, and it might be reasonable to fix it.

I found it pretty easy to create a kernel-module-MYMODULE.bbclass file and build the kernel and module in the OE/Poky build system directly, and then have it included in the image made for the device.

See http://www.yoctoproject.org/docs/1.4/kernel-dev/kernel-dev.html#incorporating-out-of-tree-modules for details.

Thanks for pointing me at that.  As it happens, I can't use that method because I'm not going to create a recipe.

Brian

On Tue, 2013-01-15 at 16:52 +0000, Patrick Turley wrote:

I used the meta-toolchain-sdk recipe to produce an SDK, and I installed it. Here's an interesting line from the environment setup script:

  export LDFLAGS="-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed"

All these linker options are preceded by "-Wl", which indicates the SDK is *expecting* them to be given to gcc and then passed on to ld.

If you look at the help for the ld command line, all these options are available, but with the "-Wl," omitted. In fact, if you use these options exactly as shown here, ld will complain that they aren't recognized and fail.

So, the SDK is giving me a value of LDFLAGS that *cannot* be used with ld. Of course, the C compiler driver can link and produce executables, and that muddies the issue somewhat.

Here's an example where this is causing me real problems…

I'm building an external module against the kernel produced by Yocto. Here's an extract from my output:


make -C /home/pturley/yocto-mpu-build/tmp/work/dm8148_mpu-poky-linux-gnueabi/linux-ti81xx-psp-2.6.37-r0+spawnlabs+r0/git M=`pwd` ARCH=arm CROSS_COMPILE=/opt/poky/1.3/sysroots/x86_64-pokysdk-linux/usr/bin/armv7a-vfp-neon-poky-linux-gnueabi/arm-poky-linux-gnueabi- \
                EXTRA_CFLAGS="-DUSE_UDEV=1 -DMAX_POOLS=128" modules
.
.
.
  LD [M]  /home/pturley/z3-work/z3-centaurus-dm814x_RPS-20120626/ezsdk/component-sources/linuxutils_3_22_00_02/packages/ti/sdo/linuxutils/cmem/src/module/cmemk.ko
/opt/poky/1.3/sysroots/x86_64-pokysdk-linux/usr/bin/armv7a-vfp-neon-poky-linux-gnueabi/arm-poky-linux-gnueabi-ld: unrecognized option '-Wl,-O1'


As you can see here, the kernel Make files are interpreting LDFLAGS as something that *can* be given directly to ld, so they fail.


My questions are:

1) Has anyone else run into this before?

2) If so, how did you resolve it?

3) Since the Yocto kernel build is *not* failing, I infer that it is *not* using the ld options the SDK gives me. So, the Yocto kernel build has its own pathway through which it computes its value for LDFLAGS. Why would Yocto use its own SDK in a way that no user is expected to?

_______________________________________________
yocto mailing list
yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>
https://lists.yoctoproject.org/listinfo/yocto





[-- Attachment #2: Type: text/html, Size: 4182 bytes --]

Re: SDK environment LDFLAGS problem?

[Bruce Ashfield]

On 13-01-15 12:59 PM, Patrick Turley wrote:
>
> On Jan 15, 2013, at 11:38 AM, Brian Lloyd <blloyd@familyhonor.net
> <mailto:blloyd@familyhonor.net>>
>   wrote:
>
>> The kernel is a special case, where the SDK is really designed for
>> developing user applications (which the kernel is not).
>
> Yes, it's clear to me that, in this one respect, the SDK is unsuitable
> for building kernels or kernel modules.
>
> My point is that this is a problem, and it might be reasonable to fix it.

You probably want Jessica or Richard to comment on the architecture /
design of the SDK with respect to kernel elements. The only packaging
for out of tree / non build system builds that I know I've ever looked
into are on target, or staging directory builds of modules.

>
>> I found it pretty easy to create a kernel-module-MYMODULE.bbclass file
>> and build the kernel and module in the OE/Poky build system directly,
>> and then have it included in the image made for the device.
>>
>> See
>> http://www.yoctoproject.org/docs/1.4/kernel-dev/kernel-dev.html#incorporating-out-of-tree-modules
>> for details.
>
> Thanks for pointing me at that.  As it happens, I can't use that method
> because I'm not going to create a recipe.

Everyone/Everything has their reasons for the different workflow(s).
(I maintain the ability to build all the boards covered in linux-yocto
without the need for any build system at all, as an example). And all
workflows are definitely valid, but it is expected that the primary
workflow for anything oe/bitbake based would be centered around recipes.

Cheers,

Bruce

>
>> Brian
>>
>> On Tue, 2013-01-15 at 16:52 +0000, Patrick Turley wrote:
>>> I used the meta-toolchain-sdk recipe to produce an SDK, and I installed it. Here's an interesting line from the environment setup script:
>>>
>>>    export LDFLAGS="-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed"
>>>
>>> All these linker options are preceded by "-Wl", which indicates the SDK is *expecting* them to be given to gcc and then passed on to ld.
>>>
>>> If you look at the help for the ld command line, all these options are available, but with the "-Wl," omitted. In fact, if you use these options exactly as shown here, ld will complain that they aren't recognized and fail.
>>>
>>> So, the SDK is giving me a value of LDFLAGS that *cannot* be used with ld. Of course, the C compiler driver can link and produce executables, and that muddies the issue somewhat.
>>>
>>> Here's an example where this is causing me real problems…
>>>
>>> I'm building an external module against the kernel produced by Yocto. Here's an extract from my output:
>>>
>>>
>>> make -C /home/pturley/yocto-mpu-build/tmp/work/dm8148_mpu-poky-linux-gnueabi/linux-ti81xx-psp-2.6.37-r0+spawnlabs+r0/git M=`pwd` ARCH=arm CROSS_COMPILE=/opt/poky/1.3/sysroots/x86_64-pokysdk-linux/usr/bin/armv7a-vfp-neon-poky-linux-gnueabi/arm-poky-linux-gnueabi- \
>>>                  EXTRA_CFLAGS="-DUSE_UDEV=1 -DMAX_POOLS=128" modules
>>> .
>>> .
>>> .
>>>    LD [M]  /home/pturley/z3-work/z3-centaurus-dm814x_RPS-20120626/ezsdk/component-sources/linuxutils_3_22_00_02/packages/ti/sdo/linuxutils/cmem/src/module/cmemk.ko
>>> /opt/poky/1.3/sysroots/x86_64-pokysdk-linux/usr/bin/armv7a-vfp-neon-poky-linux-gnueabi/arm-poky-linux-gnueabi-ld: unrecognized option '-Wl,-O1'
>>>
>>>
>>> As you can see here, the kernel Make files are interpreting LDFLAGS as something that *can* be given directly to ld, so they fail.
>>>
>>>
>>> My questions are:
>>>
>>> 1) Has anyone else run into this before?
>>>
>>> 2) If so, how did you resolve it?
>>>
>>> 3) Since the Yocto kernel build is *not* failing, I infer that it is *not* using the ld options the SDK gives me. So, the Yocto kernel build has its own pathway through which it computes its value for LDFLAGS. Why would Yocto use its own SDK in a way that no user is expected to?
>>>
>>> _______________________________________________
>>> yocto mailing list
>>> yocto@yoctoproject.org  <mailto:yocto@yoctoproject.org>
>>> https://lists.yoctoproject.org/listinfo/yocto
>>>
>>
>
>
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>

Re: SDK environment LDFLAGS problem?

[Wolfgang Denk]

Dear Bruce,

In message <50F59A91.5080806@windriver.com> you wrote:
>
> > Yes, it's clear to me that, in this one respect, the SDK is unsuitable
> > for building kernels or kernel modules.
> >
> > My point is that this is a problem, and it might be reasonable to fix it.

This is indeed a problem, and not only with the kernel, but also for
example with U-Boot - fortunately there are not that many software
packages that need to tweak with linker scripts etc. so they need to
call the linker directly.

> You probably want Jessica or Richard to comment on the architecture /
> design of the SDK with respect to kernel elements. The only packaging
> for out of tree / non build system builds that I know I've ever looked
> into are on target, or staging directory builds of modules.
...

> Everyone/Everything has their reasons for the different workflow(s).
> (I maintain the ability to build all the boards covered in linux-yocto
> without the need for any build system at all, as an example). And all
> workflows are definitely valid, but it is expected that the primary
> workflow for anything oe/bitbake based would be centered around recipes.

I found it difficult to find any formal definition of what LDFLAGS is
supposed to be.  The most authoritative appears to be the definition
as given by the make(1) documentation - as this is where LDFLAGS
actually gets used:

	`LDFLAGS'
	     Extra flags to give to compilers when they are supposed
	     to invoke the linker, `ld'.

Note the phrase "flags to give to compilers", i. e. this clearly
states that the linking is supposed to be done by running the compiler
frontend, and not the linker directly.

So even though we feel the recent version breaks old habits, it seems
that simply our old habits were based on incorrect assumptions.

I see no reason to fix the current settings, but perhaps it would be
helpful to clearly document this behaviour and recommend a workaround.

At least this was what we did for our Yocto based ELDK [1].

[1] http://www.denx.de/wiki/view/ELDK-5/FrequentlyAskedQuestionsAndAnswers#Compiling_U_Boot_or_Linux_fails

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Steal five dollars and you were a petty  thief.  Steal  thousands  of
dollars and you are either a government or a hero.
                                   - Terry Pratchett, _Going_Postal_

Re: SDK environment LDFLAGS problem?

[Eric Bénard]

Le Tue, 15 Jan 2013 17:59:10 +0000,
Patrick Turley <PatrickTurley@gamestop.com> a écrit :
> Yes, it's clear to me that, in this one respect, the SDK is unsuitable for building kernels or kernel modules.
> 
> My point is that this is a problem, and it might be reasonable to fix it.
> 
set LDFLAGS="" and you can build kernel and/or modules with the SDK.

Eric