Re: GNU Libtool 1.9d released (alpha release)

[Paul Smith]

%% Bob Friesenhahn <address@hidden> writes:

  bf> I am not aware of any particular efforts to support
  bf> cross-compilation for 2.x.  The best approach is to post email
  bf> regarding specific problems to this list (or the libtool-bugs
  bf> list) so that they can be addressed.  Progress must be made one
  bf> step at a time.  Sometimes small steps result in big leaps.
  bf> Patches are welcome.

OK, I'll try to generate some problem reports.  It's quite difficult
because the environment is very complex and it's hard to explain it well
enough to write a straightforward bug report.


At a 10,000 foot level the situation is this: we build OSS packages,
including libtool-ized packages, with a specific --prefix, but then we
use DESTDIR (for those packages that support it) or some other method to
install them somewhere else.  So, we might do this:

    ./configure --prefix=/opt/foo
    make
    make install DESTDIR=/images/ppc/psmith

and as a result, things go in /images/ppc/psmith/opt/foo.

Now when we build other packages we will use CFLAGS, etc. to get
configure to look in /images/ppc/psmith/opt/foo/{include,lib} instead
of/in addition to the "normal" places.


It gets more complex than that, though, because once the entire image is
built it is moved around in two ways.  First, it is bundled up into a
root fs image and loaded on the destination hardware; when that happens
it really DOES live in /opt/foo.  In fact the idea is that the entire
directory hierarchy below the DESTDIR is loaded verbatim as / on the
destination.  So we really want all the built-in runtime linker paths to
be /opt/foo, etc. so during normal runtime it all Just Works without
special LD_LIBRARY_PATH settings.

The second way is that it's copied around to other DESTDIR directories,
like maybe /images/ppc/stable or whatever.

So in all these scenarios the install directories at build time, at
install time, AND at "runtime" are different.


The main problem we have with libtool seems to be that the .la files
have all these hardcoded pathnames etc. in them and there doesn't seem
to be any way to give the scripts alternatives dynamically, as they're
invoked.  This makes it very complicated to use libtool-ized setups in
our environment.

We have similar problems with pkgconfig-type stuff, but those seem much
simpler to solve; tracing through libtool scripts to try to figure out
what's going on can be very frustrating.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <address@hidden>   HASMAT--HA Software Mthds & Tools
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.