Re: Baking linker flags into generated cross-ld

[CT NG <crosstoolng at mrblade dot de>]

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