This is the mail archive of the crossgcc@sources.redhat.com 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] |
Daniel Kegel <dank@kegel.com> wrote: > Hey all, > it looks like supporting x86_64 means using --with-sysroot, and > that means the libraries built by crosstool will be split > between /lib and /usr/lib instead of being just in /lib as they > were before, at least for x86_64. I have recently built all my own glibcs as if they were for the native platform and copied the prebuilt glibcs 'as is' from the '.rpm's and '.deb's. So they have always these '/lib' and '/usr/lib' plus all kind of weird stuff in 'sbin', 'libexec' etc. subdirs... I think this issue about "how-to-symlink" was at least partially discussed recently but maybe it didn't become clear that it is not "nuclear science" (or at least "nuclear shit science", hiding nuclear waste inside rock, with which I sometimes took part. I wouldn't use the name "rocket science" after NASA mixing miles and kilometers and the last ESA failure in these Mars expeditions... I have some experience about one organization which could have been mixed in the ESA project from my "nuclear shit science" age... Definitely having my attitude, I didn't want them being mixed in producing the device used to test bentonite properties, the clay used to surround the nuclear shit containers... Geosciences were then always in higher level than the space sciences...) Ok, I hadn't any serious problems with the 'x86_64-linux-gnu' target. I first built my own two 64-bit and 32-bit glibcs, the 32-bit one using my 'athlon_xp-linux-gnu' toolchain, but then thought this being insane and just copied the glibc stuff from the SuSE 9.0/x86_64 distribution. I cannot imagine any other current x86_64 system for which I could require to produce executables (besides the unaccessible Enterprise Servers from RedHat and SuSE). Later all the X11, GUI-toolkit libs etc. can be copied and added to the toolchain. Of course there were weird things in the original symlinks between the SuSE 9.0 glibc files, but normalizing them wasn't hard... Anyway here is my $prefix/$target for x86_64-linux-gnu showing the symlinks : /usr/local/x86_64-linux-gnu > l total 3 drwxr-xr-x 2 root root 1024 Apr 25 2003 bin drwxr-xr-x 2 root root 1024 Apr 15 2003 bin-gcc lrwxrwxrwx 1 root root 36 Dec 17 18:13 include -> /home1/host-x 86_64-linux/usr/include lrwxrwxrwx 1 root root 34 Dec 17 18:11 lib -> /home1/host-x86_6 4-linux/usr/lib64 drwxr-xr-x 2 root root 1024 Nov 18 11:15 sys-include and here is the sysrooted '/usr' : /home1/host-x86_64-linux/usr > l total 10 drwxr-xr-x 2 root root 1024 Dec 18 23:59 bin drwxr-xr-x 28 root root 3072 Dec 19 00:03 include drwxr-xr-x 3 root root 2048 Dec 17 18:35 lib drwxr-xr-x 2 root root 1024 Dec 19 00:21 lib64 drwxr-xr-x 2 root root 1024 Dec 18 23:29 libexec drwxr-xr-x 2 root root 1024 Dec 17 16:50 sbin drwx------ 4 root root 1024 Dec 18 23:57 share Hmmm, I must use 'chmod' for this 'share'... Maybe the only extra symlinks needed in the sysroot'ed cross-tools were those for libc.so.6 and ld-linux*.so.2, and for the multilib'ed '32' subdirectory: /home1/host-x86_64-linux/usr/lib64 > l 32 libc.so.6 ld-linux* lrwxrwxrwx 1 root root 6 Dec 17 18:15 32 -> ../lib lrwxrwxrwx 1 root root 32 Dec 17 18:01 ld-linux-x86-64.so.2 -> ../../lib64/ld-linux-x86-64.so.2 lrwxrwxrwx 1 root root 21 Dec 19 00:16 libc.so.6 -> ../../lib64/libc.so.6 /home1/host-x86_64-linux/usr/lib64 > cd 32 /home1/host-x86_64-linux/usr/lib > l libc.so.6 ld-linux* lrwxrwxrwx 1 root root 23 Dec 17 17:12 ld-linux.so.2 -> ../../lib/ld-linux.so.2 lrwxrwxrwx 1 root root 19 Dec 17 17:12 libc.so.6 -> ../../lib/libc.so.6 A native x86_64-linux-gnu install doesn't have these symlinks from '/usr/lib' to '/lib'. 'Normalize' scripts like: /home1/host-x86_64-linux/usr/bin > cat fix-64bit-symlinks.sh ln -f -s ../../lib64/ld-linux.so.2 ld-linux.so.2 ln -f -s ../../lib64/libanl.so.1 libanl.so ln -f -s ../../lib64/libBrokenLocale.so.1 libBrokenLocale.so ln -f -s ../../lib64/libc.so.6 libc.so.6 ln -f -s ../../lib64/libcrypt.so.1 libcrypt.so ln -f -s ../../lib64/libdb.so.2 libdb1.so ln -f -s ../../lib64/libdl.so.2 libdl.so ln -f -s ../../lib64/libnsl.so.1 libnsl.so ln -f -s ../../lib64/libnss_compat.so.2 libnss_compat.so ln -f -s ../../lib64/libnss_dns.so.2 libnss_dns.so ln -f -s ../../lib64/libnss_files.so.2 libnss_files.so ln -f -s ../../lib64/libnss_hesiod.so.2 libnss_hesiod.so ln -f -s ../../lib64/libnss_nisplus.so.2 libnss_nisplus.so ln -f -s ../../lib64/libnss_nis.so.2 libnss_nis.so ln -f -s ../../lib64/libresolv.so.2 libresolv.so ln -f -s ../../lib64/librt.so.1 librt.so ln -f -s ../../lib64/libthread_db.so.1 libthread_db.so ln -f -s ../../lib64/libutil.so.1 libutil.so (these were only for the 'minimal' C libraries) were required to fix the symlinks in the original SuSE 9.0 glibcs. Quite equivalent script with '../../lib' was required to fix the symlinks in the 32-bit SuSE 9.0 glibc-2.3.2. The '-rpath-link' required for the '32' multilib is of course a nuisance when the 64-bit default libs will be found automagically... Hmmm, maybe I should have the 'ld-linux.so.2' symlinked to the 'lib64' (to the default $prefix/$target/lib) too in order to fix this, the $prefix/$target/lib will be scanned for the 'dynamic linker' in the 64-bit case... With the '-rpath-link' in place is 'specs' there weren't problems in compiling and linking 64-bit and 32-bit executables. As seen, using the '--with-sysroot' wasn't at all obligatory, but maybe the X11, GUI-toolkits etc. extra stuff would require for instance a '-L/usr/X11R6/lib' working in the cross case too... All the previous assumes the GCC builder/installer knowing what one is doing, ie. knowing the usual/standard Linux install conventions. Adding some extra symlinks for the '32' subdir and the 'libc.so.6'/'ld-linux*.so.2' files isn't that hard and I wouldn't expect these causing problems if the C library would be used in a NFS mounted native toolchain (a small embedded x86_64-linux-gnu target board may though sound a little wacky...). But how to automatize all this with a script has been left out. In this x86_64 case the sanity in the self built glibcs is also unsolved. One can build and use them in the previous scheme, but whether the produced binaries will then run on SuSE 9.0 or on the x86_64 ES-models from RedHat and SuSE, is more or less unclear. Cheers, Kai ------ Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/ Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |