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. [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. > > > 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)
