This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Trevor, Dimitry, All, On Wednesday 31 March 2010 22:50:24 Dimitry Andric wrote: > On 2010-03-31 22:37, Trevor Woerner wrote: > > Just out of curiosity... I keep thinking about this question off and > > on and I just can't figure out what the advantage would be to having a > > toolchain that doesn't use the build host's language libraries. So it > > can be copied to and run from another machine (one which may be using > > a different version of, say, glibc)? > - glibc is always compiled with a 'minimum supported kernel version', > so even if you link your application statically with it, that does not > guarantee that the application runs on any lower kernel version. > > - newer glibc versions are always compatible with older glibc versions > (on the same architecture, of course), but not the other way around. That, plus: - glibc has issues with NSS (Name Service Switch) when compiled statically. Although I don't see why a toolchain would need to resolve host or user names... Nice to keep in mind whenever building statically with glibc. > So linking all toolchain executables completely static is really a tiny > bit overkill. :) It is mostly enough to: I would tend to agree with you, Dimitry. But, think about this hypotetical situation (which I do *not* condone): - responsible for build tools, you build updated toolchains for you team, and make those available to all your developpers; - you have a fast, very recent multi-core machine, so you can easily experiment with new toolchains, and build them *fast*; most probably, being a recent machine, you installed the latest (stable?) version of your favourite distro (Debian/Udbuntu/Fedora/...) - OTOH, your developpers have lower-end machines, that date a few years back, if not more (I know some situations where this is the case, up to 6 year-old machines), that have not been updated, out of lazyness, or just because "It Works (TM)"; - so if you give them your shared-linked toolchain, Kaboom! it breaks on their machines... > - build your toolchain on an "oldish" Linux distro (at least, one with > an oldish version of glibc), such as Debian Stable or Red Hat 5, or even > 4, if you really want to go for lowest common denominator. Or you can do that, of course! :-) Anyone has an yggdrasil handy? > - make sure any extra dependencies, usually libgmp and/or libmpfr, > *are* statically linked into the toolchain executables, since not > everybody will have those as .so files on their system, or may have > different, incompatible versions. Yes, and those *I* was not able to properly build statically (yet!)... :-( 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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |