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]

(Fwd) Re: crosstool switching to /lib + /usr/lib ?


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]