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