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]

Re: !(fun) with tls


sarge's glibc 2.3.2 is not really 2.3.2.  In addition to Debian-local
enhancements, it has almost everything from upstream 2.3.5 backported,
including a last-minute ABI change related to POSIX real-time thread
scheduling that can result in binary incompatibility with even closely
related distros (e. g., Ubuntu "breezy").  (You haven't run into that,
but you probably will next if you try to point fix arount the TLS
issue.)

To do what you're trying to do, you will probably need to massage the
substantive changes in sarge "glibc 2.3.2" into a patch in the
appropriate subdirectory of patches/.  Then you will get sarge's API
and ABI changes in your cross-compiler's headers and libraries.  If
all goes well, you can install the sarge glibc on the target instead
of your toolchain's version, which seems to be what you're aiming to
do.  (It's not clear to me why you're cross-compiling instead of
compiling natively inside a chroot; perhaps if you explain the
motivation I can be more specific.)

One thing I would definitely discourage is the use of binaries that
dynamically link against different libc's within the same library
namespace (i. e., without the use of a chroot).  It's fairly common
for userspace threading mechanisms and their locking sequences to
change subtly from patch to patch, and you don't want to wind up with
two threading libraries inside one process.  Either put sarge's libc6
on your target system or use your toolchain's.

Cheers,
- Michael

--
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]