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

[Guido Draheim]

aaaaaaaahhhh, you want the shared libraries go to the
target system during install, and the static libraries
to stay. May I ask how do you expect the linker to
resolve with the shared library if that one is 
remote? The static lib isn't the same, so, *hhmm* I am
a bit confused. So far, I would have built two times,
one for the target system and one for the build system.

However, I see your point - unlike plain binaries, the
crosscompiled libraries are needed to be doubled for
both the real target and the build system. However, 
the same would account for quite some other things
like include-headers and manpages to stay on the build
system (it doesn't make sense for quite some targets,
esp. if those don't have a console, and we just use
an mount-path to install there on to, or the whole
install directions are just about destdir making an 
archive from it that can be copied over). It is however
uncertain, e.g. on some build hosts, you could not
read the manpages, while they are needed on the target
host. Or just the other way round, useless on the
target host, and useful on the build host.

It's not easy to decide about that. It all brings us
back to the question to consider some configure
options to make a multi build - currently, I do this
using a handmade toplevel configure that creates two
subdirectories, and then calls the real autoconf
configure from that subdirectory. i.e.

./configure <- toplevel one
./src/configure.ac <- autoconf one
./src/configure    <- generated

and the toplevel configure does check the options, so
it can see all kinds of conditions that require
multiple builds - in that case it will then do

(test -d debug || mkdir debug) && \
   (cd debug && ../src/configure $* --disable-shared)
(test -d release || mkdir release) && \
   (cd release && ../src/configure $* --with-optstuff)

And ensure to have a toplevel makefile that does
recurse into all build subdirs, for both build and
install runs. Of course, you could add any other 
option to the two configure lines, whatever conditions
you  want to check for. Well, I had never the time to 
make up some tool that could create the toplevel 
configure and makefile automatically - in your case, 
you want the two modes only in the case of 
crosscompiling, and this is a quite common wish.

Hmm, whereever that ends. May be you can live with
the model just presented, atleast it works, so
far I can assure you.

-- guido



Es schrieb Dan Kegel:
> 
> You'd think so, but playing games like that might really
> confuse libtool.
> 
> What I'd like to see is a fully-worked out example of how
> to use libtool, with both static and shared libraries,
> in a cross-compile situation, without the static libraries
> leaking out onto the target system.  We may need to split
> --libdir into --libdir and --buildlibdir, or something
> awful like that?
> 
> Thinking about libtool and cross-compiling is giving me
> serious heartburn.
> - Dan
> 
> Guido Draheim wrote:
> >
> > --bindir vs. --libdir ?
> >
> > Es schrieb Dan Kegel:
> > >
> > > I'm cross-developing.  I want to build a package
> > > that has both static libraries and binaries.
> > > The binaries should go to the target system;
> > > the libraries should stay on the build system.
> > > What do I pass to configure and to make?
> > >
> > > If I do
> > > configure --build=pentium-unknown-linux address@hidden@-unknown-linux
> > > --disable-shared --with-gnu-ld --prefix=/usr
> > > make -C @IXIA_PORTARCH@/src/lib DESTDIR=$(DEST) install
> > >
> > > the library ends up in the right place (DEST/usr/lib)
> > > but the binary ends up in the wrong place (DEST/usr/bin).
> > >
> > > If instead I do
> > >
> > > make -C @IXIA_PORTARCH@/src/lib DESTDIR=$(DEST)/fsimg install
> > > the library ends up in the wrong place (DEST/fsimg/usr/lib)
> > > but the binary ends up in the right place (DEST/fsimg/usr/bin).
> > >
> > > What to do?  In cross-development environments, is it not
> > > supported to have static libraries go to the build system,
> > > but binaries go to the target?
> > >
> > > - Dan

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