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

[Guido Draheim]

Es schrieb Dan Kegel:
> 
> Guido Draheim wrote:
> > > ...
> > > I don't think this does the trick, though.  I can't see
> > > how it lets you install binaries and shared libs to a staging
> > > area for transfer to the target, and everything else to
> > > their final location on the build system, while making
> > > sure that libtool is told the proper final location
> > > of shared libraries as they will appear upon boot of the target.
> >
> > now that's a good one - the .la file does have the information
> > where the lib will be on the target system. And we want to
> > retain it on the build system to have it ready for other
> > packages to benefit from the information. That would be
> > perfect to compile a complete series of packages during
> > cross-compiling.
> 
> Yes, but just because it gets copied to the staging
> area doesn't mean it's unavailable to the build system.
> We just have to tell whoever is looking for .la's and
> shared libraries at build time to look in the staging area.

not quite. atleast this is not common behaviour at the
moment. See - the libtool crossgcc support (to which I did 
contribute some of the time) can simply ask the cross-gcc 
for the local searchpath via `gcc -print-search-dirs` - 
this is needed for win32 compiles atleast, and I have a
patch on my disk which generalizes the idea for all
cross-gcc targets (since there have been problems with
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.


> 
> > However, hmm,
> > *scratchinghead* in the case that we did run a crosscompiler,
> > the configure does know the default location of our cross
> > build tools anyway *hmmm* - still, the biggest support would
> > be needed in the makefile to install into a buildtool path
> > and WITHOUT the need to relink there.
> >
> > does this get us on the right track?
> 
> I dunno, I think we need an example project to illustrate this.
> A 'hello world' where main writes 'hello' and a shared libarary
> writes 'world', maybe.

it is even more complicated, since a single hello/sharedlib does
not show the problemspace. We need two projects, one is creating
a sharedlib and installs it, and the other shall depend on it.
We check that the second configure can see the necessary header
files (or even libraries?), and that the build can correctly 
resolve with these build-installed libraries.

cheers,
-- guido                                    http://freespace.sf.net/guidod
GCS/E/S/P C++/++++$ ULHS L++w- N++@ d(+-) s+a- r+@>+++ y++ 5++X- (geekcode)