Re: Baking linker flags into generated cross-ld

["Yann E. MORIN" <yann dot morin dot 1998 at free dot fr>]

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