[Lpr-discuss] Re: build environment

[Danek D. <dd...@en...>]

On Fri, Jun 01, 2001 at 06:08:10PM -0400, James Antill wrote:

>  Executable objects should get compiled without PIC in all cases, and
> nothing should change when playing with en/dis able-static/shared as
> they should always be static (as I understand it).

Yes, that does seem to be the case.

>  Note that I've almost never really looked at the command line stuff,
> but it _should_ work just as a compiler option. So -llib with -Ldir
> would be the approach I'd use.

Sadly, it doesn't.  There's a footnote in the libtool manual that explains
it:

    you should avoid using `-L' or `-l' flags to link against an
    uninstalled libtool library.  Just specify the relative path to the
    `.la' file, such as `../intl/libintl.la'.  This is a design decision to
    eliminate any ambiguity when linking against uninstalled shared
    libraries.

So it's a feature, not a bug.  :)  I don't know why it seems to work in
1.4; maybe I'm just getting lucky.

>  When I've seen this before it's because libtool didn't understand
> that .lib/libfoo.so was a shared library. It tried to find this out by
> running the "file" command on the file and then grepping for known
> shared library descriptions. If this is the problem then a quick hack
> to the scripts to recognise Solaris shared libraries should be easy.

I'd be surprised if this were the case, but possibly.  If I'm so inclined,
I'll smack it around some more later.  At this point I have something
working, and libtool is making my brain hurt.  ("Smithers, massage my
brain!")

> > The only problem I'm running into is that our configure script barfs
> > when it can't find ltconfig, which isn't part of libtool 1.4.  Norm and
> > I are working on this now.
> 
> This needs to be fixed anyway, as I'm using unstable debian and that has
> moved to libtool-1.4 so I can't re ./autogen.sh

It shouldn't be a problem for you; that turned out to be a local
installation error on my part.

Danek