Es schrieb Guido Draheim: > crosscompiling linux-to-linux). Now the result is simply > grepped for the "libraries:" entry, at it usually spits > out a couple of directories very close the installation > of the crossgcc himself. > > [guidod@pc3 guidod]$ i386-mingw32-gcc -print-search-dirs | grep libraries: > libraries: > /usr/lib/gcc-lib/i386-mingw32/2.95.3/: > /usr/lib/gcc/i386-mingw32/2.95.3/: > /usr/i386-mingw32/lib/i386-mingw32/2.95.3/: > /usr/i386-mingw32/lib/ > > Now I'd say for the build-install, we could simply extract > the last entry of this setting - in this case it would be > /usr/i386-mingw32/lib - and a similar entry exists for > the native compiler that would be /usr/lib on linux. This > entry is in the default libpath of the gcc-linker, and it > is damn needed since other crosscompiled programs must > resolve to the libs being found in the libsearchpath - if > there would be no such default, you might need to give > another way to have it added for libtool compiles. And > the staging area is never a default path to be deduced > from the --host=cross-target identification, IMO. >
might not be that interesting, but I had a couple of thoughts about it the last days, nothing conclusive so the following text is looong and winding.... * let's come back to one of th ideas to have automake support for a copy of the libs on the build host. My first guess above was about using the last part of print-search-dirs, and possibly derive the incudedir from it. That's one idea. The other idea is about that staging area, and actually this might be a good idea as well for the build host, to let it access the libs in the staging area. One could even let autoconf-tests to be able to try_link with those and even get back the install-location on the target system. But there are some problems. See, the current gcc does not use this scheme, it does always install itself according to the FHS of the build host, and it was quite common to let the gcc have all the target differences embodied in its lib/gcc subtree. That way, one was able to take one toplevel gcc and just switch the target-system for the current compile job. But I think this idea is outdated and autoconf uses the other way, checking for a <host>-gcc in the path. Well, libtool has a list of hardcoded fhs entries for the libsearchpath of quite some target systems, but that would be nothing worth without the staging area prefix. Now, let's assume we change the gcc and do not copy the target support files into one of its package subdirs (as discussed above), but it uses a staging area for it - in a way it simulates that the system headers and libs are just there on the target system mounted via some network-aware system. Currently, my crossgcc uses a simple prefix for the cross compile support dirs, i.e. the initial libdir would be /usr/i386-mingw32/lib alongside of an /usr/i386-mingw32/include, while for a simulation of the target host, the latter should not use a "/lib" subdir particle, as that would not be the final location on such a target system I guess. That one boils down to the fact, that we do not need any automake support when a staging area (a chroot-like target host simulation-filetree) is being used, it would just be a different DESTDIR, and it would also provide the support for any other build support file, like includeheaders or some other modules, one could even use a binary package for the target host, and install under a reloc-prefix. That gives a good future compatibility as we do not need to know anymore which of the files need a copy on the build host (if in doubt, install them all), and there is just one problem left - where is the staging area, and how is the fhs being used in there. That is sure no easy answer. The print-search-dirs scheme migh help, but I didn't come to any conclusive so far. your ideas? cheers, -- guido http://freespace.sf.net/guidod GCS/E/S/P C++/++++$ ULHS L++w- N++@ d(+-) s+a- r+@>+++ y++ 5++X- (geekcode)
