Baking linker flags into generated cross-ld

Baking linker flags into generated cross-ld

[CT-NG]

 Hi,

I built a tool-chain for a ARM device with kernel 2.6.32.12 on a x86_x64 linux
machine.
Because the target's glibc is quite old (2.5) and I want the newest g++ I
decided to use a newer glibc when building the cross gcc and use that also on
the target system for all binaries I built with the cross-toolchain.
After building everything and copying the sysroot and debugroot folders to the
target I am only able to run i.e. gdb if I chroot it...this make sense, since it
is compiled against the newer glibc and does use some features from it.
Also if I now build programs with this toolchain I have to run them chroot'ed or
I can add the --rpath=... and --dynamic-linker=... options to the ld.
This works but has two disadvantages:
- I have to modify all builds to add those two arguments
- The gdb built by crosstool-ng still has to be run chroot'ed.

My idea now is to "bake" those two arguments (--rpath & --dynamic-linker)
somehow into the cross-ld so they are active automatically without specifying
them.
This would ease everything dramatically.

Is this possible?

I tried setting ct-ng menuconfig -> Target options -> Target LDFLAGS but this
leads to
checking dynamic linker characteristics... configure: error: Link tests are not
allowed after GCC_NO_EXECUTABLES.

Any suggestions?

Regards,

Rüdiger

--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: Baking linker flags into generated cross-ld

[Trevor Woerner]

Hi,

On Sun, Feb 10, 2013 at 10:01 AM, CT-NG <crosstoolng@mrblade.de> wrote:
> Any suggestions?

Does it help if you set the LD_LIBRARY_PATH environment variable?
E.g.

$ LD_LIBRARY_PATH=/path/to/chroot/lib ./path/to/executable

Best regards,
    Trevor

--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: Baking linker flags into generated cross-ld

[CT NG]

Hi Trevor!

This helps solving the library-finding problem but it does not allow to specify the different ld.so library.
Maybe that it nevertheless works but my plan is to make it as invisible as possible.

Rüdiger


-------------------------
Rüdiger Stevens

Dipl.-Ing. Informationstechnik (BA)


On 10.02.2013, at 16:27, Trevor Woerner <twoerner@gmail.com> wrote:

> Hi,
> 
> On Sun, Feb 10, 2013 at 10:01 AM, CT-NG <crosstoolng@mrblade.de> wrote:
>> Any suggestions?
> 
> Does it help if you set the LD_LIBRARY_PATH environment variable?
> E.g.
> 
> $ LD_LIBRARY_PATH=/path/to/chroot/lib ./path/to/executable
> 
> Best regards,
>    Trevor
> 
> --
> For unsubscribe information see http://sourceware.org/lists.html#faq
> 

--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: Baking linker flags into generated cross-ld

[Trevor Woerner]

On Sun, Feb 10, 2013 at 12:02 PM, CT NG <crosstoolng@mrblade.de> wrote:
> This helps solving the library-finding problem but it does not allow to specify the different ld.so library.

If you want to use a specific runtime linker you can invoke it
manually (although this doesn't help you make it transparent):
$ /lib64/ld-linux-x86-64.so.2 /usr/bin/ls /
bin  boot  dev  etc  home  lib  lib64  lost+found  media  mnt  opt
proc  root  run  sbin  selinux  srv  sys  tmp  usr  var

I seem to think there is some way to influence which linker gets
called, otherwise on a system with both 32-bit and 64-bit runtime
linkers, how would it know which one to call?

$ /lib/ld-linux.so.2 /usr/bin/ls
/usr/bin/ls: error while loading shared libraries: /usr/bin/ls: wrong
ELF class: ELFCLASS64

--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: Baking linker flags into generated cross-ld

[CT-NG]

Hello Trevor!

Thank you for your hint.

I tried a combination of setting LD_LIBRARY_PATH & starting via ld:

export LD_LIBRARY_PATH=/opt/rst/lib
/opt/rst/lib/ld-linux.so.3 /opt/rst/usr/bin/gdb

This leads to a flooding of my console with messages like

Name collision between linux linux linux linux linux linux linux linux linux
linux linux linux linux linux linux linux linux linux linux linux linux linux
linux linux linux linux linux linux linux
Name collision between linux-m linux-m linux-m linux-m linux-m linux-m linux-m
linux-m linux-m linux-m linux-m linux-m linux-m linux-m linux-m linux-m linux-m
linux-m linux-m linux-m linux-m linux-m linux-m linux-m linux-m linux-m linux-m
linux-m linux-m


until I killed the process...

If this had worked I would use it as second best solution.

Although I do not know if these message would also occur if gdb has been built
with --rpath=/opt/rst/lib --dynamic-linker=/opt/rst/lib/ld-linux.so.3 ...
In my little hello world test program these message do not occur...I think just
because it does not use any locale functions.

Rüdiger

Trevor Woerner <twoerner@gmail.com> hat am 10. Februar 2013 um 19:34
geschrieben:
> On Sun, Feb 10, 2013 at 12:02 PM, CT NG <crosstoolng@mrblade.de> wrote:
> > This helps solving the library-finding problem but it does not allow to
> > specify the different ld.so library.
>
> If you want to use a specific runtime linker you can invoke it
> manually (although this doesn't help you make it transparent):
> $ /lib64/ld-linux-x86-64.so.2 /usr/bin/ls /
> bin  boot  dev  etc  home  lib  lib64  lost+found  media  mnt  opt
> proc  root  run  sbin  selinux  srv  sys  tmp  usr  var
>
> I seem to think there is some way to influence which linker gets
> called, otherwise on a system with both 32-bit and 64-bit runtime
> linkers, how would it know which one to call?
>
> $ /lib/ld-linux.so.2 /usr/bin/ls
> /usr/bin/ls: error while loading shared libraries: /usr/bin/ls: wrong
> ELF class: ELFCLASS64
>
> --
> For unsubscribe information see http://sourceware.org/lists.html#faq
>

--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: Baking linker flags into generated cross-ld

[Yann E. MORIN]

Rüdiger, All,

On Sunday 10 February 2013 CT-NG wrote:
> Because the target's glibc is quite old (2.5) and I want the newest g++ I
> decided to use a newer glibc when building the cross gcc and use that also on
> the target system for all binaries I built with the cross-toolchain.
> After building everything and copying the sysroot and debugroot folders to the
> target I am only able to run i.e. gdb if I chroot it...this make sense, since it
> is compiled against the newer glibc and does use some features from it.
> Also if I now build programs with this toolchain I have to run them chroot'ed or
> I can add the --rpath=... and --dynamic-linker=... options to the ld.
> This works but has two disadvantages:
> - I have to modify all builds to add those two arguments
> - The gdb built by crosstool-ng still has to be run chroot'ed.

It is expected that it is not (generally) possible to run a program
linked against a new glibc, against an older glibc. (The opposite is
possible, however).

So, the fact that you need to be chrooted is normal behavior.

crosstool-NG was not designed to allow building for an existing system,
but rather for building systems from scratch.

> My idea now is to "bake" those two arguments (--rpath & --dynamic-linker)
> somehow into the cross-ld so they are active automatically without specifying
> them.
> This would ease everything dramatically.
> 
> Is this possible?

There is no support in crosstool-NG for creating an ld wrapper that 
unconditonally pases additional arguments to the real ld.

(In fact, crosstool-NG may already install a ld wrapper, if you use gold
and the legacy bfd ld, but it's a shell script).

> I tried setting ct-ng menuconfig -> Target options -> Target LDFLAGS but this
> leads to
> checking dynamic linker characteristics... configure: error: Link tests are not
> allowed after GCC_NO_EXECUTABLES.

No real clue about that, but it certainly is a Bad Idea (TM). ;-)
But that would not solve your issue, because those target LDFLAGS are
not persistent after the toolchain is built, so they are in action only
inside the crosstool-NG build process.

I find it dubious to add a ld wrapper that feeds aditional args to the
real wrapper. Going this route implies we should also be allowed to add
such a wrapper for gcc, g++, as and so on...

I believe this wrapper thinggy should not be part of crosstool-NG, but
that of an upper-layer buildsystem. For example, buildroot does exactly
that: they build a wrapper for a select set of tools (ld is not currently
part of  that set, but there's work on it) that forcibly calls the real
versions of the tools with extra {CPP,C,CXX}FLAGS set by buildroot itself.
See: http://git.buildroot.net/buildroot/tree/toolchain/toolchain-external

However, as much as I thing this does not belong in crosstool-NG, I also
had such a need sometime ago, and I highly resisted the urge to push that
upstream. This means: you can try to convince me! ;-)

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: Baking linker flags into generated cross-ld

[CT NG]

I know crosstool-ng is meant to build a new system image. Nevertheless it is also vers useful to build a new compiler (and in my case new glibc) for an existing system. My specific requirement is that I own a Synology Diskstation where you only find the rather old gcc 4.2 as a compiler for. Since I'd like to use some C++11 features I have not that much options...and crosstool-ng helps a lot here :-)

Maybe it is not necessary to have a wrapper around the ld. I can specify the linker options for my own code when compiling it. But what would defenitly helps would be to build the target debug programs wirh these options.

Maybe i should also try to put the options in the CCFLAGS using -Wl,... As this is the way I'm currently doing for my own code....


-------------------------
Rüdiger Stevens

Dipl.-Ing. Informationstechnik (BA)


On 15.02.2013, at 19:25, "Yann E. MORIN" <yann.morin.1998@free.fr> wrote:

> Rüdiger, All,
> 
> On Sunday 10 February 2013 CT-NG wrote:
>> Because the target's glibc is quite old (2.5) and I want the newest g++ I
>> decided to use a newer glibc when building the cross gcc and use that also on
>> the target system for all binaries I built with the cross-toolchain.
>> After building everything and copying the sysroot and debugroot folders to the
>> target I am only able to run i.e. gdb if I chroot it...this make sense, since it
>> is compiled against the newer glibc and does use some features from it.
>> Also if I now build programs with this toolchain I have to run them chroot'ed or
>> I can add the --rpath=... and --dynamic-linker=... options to the ld.
>> This works but has two disadvantages:
>> - I have to modify all builds to add those two arguments
>> - The gdb built by crosstool-ng still has to be run chroot'ed.
> 
> It is expected that it is not (generally) possible to run a program
> linked against a new glibc, against an older glibc. (The opposite is
> possible, however).
> 
> So, the fact that you need to be chrooted is normal behavior.
> 
> crosstool-NG was not designed to allow building for an existing system,
> but rather for building systems from scratch.
> 
>> My idea now is to "bake" those two arguments (--rpath & --dynamic-linker)
>> somehow into the cross-ld so they are active automatically without specifying
>> them.
>> This would ease everything dramatically.
>> 
>> Is this possible?
> 
> There is no support in crosstool-NG for creating an ld wrapper that 
> unconditonally pases additional arguments to the real ld.
> 
> (In fact, crosstool-NG may already install a ld wrapper, if you use gold
> and the legacy bfd ld, but it's a shell script).
> 
>> I tried setting ct-ng menuconfig -> Target options -> Target LDFLAGS but this
>> leads to
>> checking dynamic linker characteristics... configure: error: Link tests are not
>> allowed after GCC_NO_EXECUTABLES.
> 
> No real clue about that, but it certainly is a Bad Idea (TM). ;-)
> But that would not solve your issue, because those target LDFLAGS are
> not persistent after the toolchain is built, so they are in action only
> inside the crosstool-NG build process.
> 
> I find it dubious to add a ld wrapper that feeds aditional args to the
> real wrapper. Going this route implies we should also be allowed to add
> such a wrapper for gcc, g++, as and so on...
> 
> I believe this wrapper thinggy should not be part of crosstool-NG, but
> that of an upper-layer buildsystem. For example, buildroot does exactly
> that: they build a wrapper for a select set of tools (ld is not currently
> part of  that set, but there's work on it) that forcibly calls the real
> versions of the tools with extra {CPP,C,CXX}FLAGS set by buildroot itself.
> See: http://git.buildroot.net/buildroot/tree/toolchain/toolchain-external
> 
> However, as much as I thing this does not belong in crosstool-NG, I also
> had such a need sometime ago, and I highly resisted the urge to push that
> upstream. This means: you can try to convince me! ;-)
> 
> Regards,
> Yann E. MORIN.
> 
> -- 
> .-----------------.--------------------.------------------.--------------------.
> |  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
> | +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
> | +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
> | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
> '------------------------------^-------^------------------^--------------------'
> 
> --
> For unsubscribe information see http://sourceware.org/lists.html#faq
> 

--
For unsubscribe information see http://sourceware.org/lists.html#faq