Re: cross-compiling question: static libraries and binaries to different places?

[Guido Draheim]

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.
> 
> address@hidden 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)