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

[Dan Kegel]

Guido Draheim wrote:
> 
> aaaaaaaahhhh, you want the shared libraries go to the
> target system during install, and the static libraries
> to stay.

Yes.  Also, binaries should go to the target system.

> May I ask how do you expect the linker to
> resolve with the shared library if that one is
> remote? 

Normally, I'd just pass it a -L, I suppose.  I dunno
about libtool libraries.

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

Yes.  Doc and headers would stay on the build system.

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

Not worried about those cases.  They are well served
by the current situation.
 
> 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.

Yes, I'm doing something like that now.  (For each
open source package I install, I have a top-level
Makefile.in that knows how to unpack, configure, and
install the open source package.)

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.
- Dan

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