Re: Making a private lib for linking

[James Henstridge <james daa com au>]

On 29/07/2003 7:33 AM, Curtis C. Hovey wrote:

> On Mon, 2003-07-28 at 01:23, James Henstridge wrote:
>  
>
> > > > > I recently upgraded my autotools while using jhbuild, but I discovered
> > > > > Medusa wasn't making its .a private libs after that even though its
> > > > > Makefile contains 'LDFLAGS = -static'.  I removed AM_DISABLE_STATIC and
> > > > > all is better.  Is this the right thing to do when I'm making a private
> > > > > lib to link into my main lib?  Is there a better way?
> > > > >          
> > It is probably a bug in your makefiles and/or configure script.  Other 
> > packages such as Pango build fine with the newer libtool.
> >    
>
> I think it is a bug in Medusa's configure.in.  
>
> Pango is a bad example, it never uses 'LDFLAGS = -static', to build
> Nautilus and Medusa jhbuild pulled a lot of modules, but only 
>
> ./ORBit2/test/everything/Makefile.am
> ./medusa/medusa-idled/Makefile.am
>
> contain this command.
Setting LDFLAGS like that is evil.  Maybe the reason you are having 
problems is because you are doing that?  If you tell automake to build a 
"noinst" library, it will be a static lib suitable for linking against 
another shared library or application.  You shouldn't need any weird flags.

If it is a library you want to install and have used by other 
applications, why do you need it to be static?

> > The AM_DISABLE_STATIC macro does exactly the same thing as 
> > AC_DISABLE_STATIC (in fact it just calls the AC_ version).  These macros 
> > just make --disable-static the default (rather than --enable-static).  
> > So this is not very likely to be the problem.
> >    
> Is there a preference for AC_, the newer, versus, AM_ the older?
The original automake-1.4 would only work if it saw "AM_PATH_LIBTOOL" in 
your configure.in.  However, any of the automake-1.4-pX series will 
accept either form, and so will automake >= 1.5.

The libtool docs say that the AM_* names are deprecated, so you may as 
well use the new names.

> > One other thing to try is building from a clean source tree -- 
> > libtool-1.5 handles .lo files in a different way to 1.4.x, so if you 
> > have any .lo files left over from a previous build, they could be 
> > causing problems.
> >    
>
> I did.  New checkout, And I tried it as a new user too.  That clued me
> in that this problem was not related to jhbuild.  Unless someone can
> give good reason, I don't think I should restore AM_DISABLE_STATIC to
> configure.in.  The idle daemon in an anachronism from Medusa's days as a
> system app anyway.  It'll be reworked/phased out in time.
>  
It would be helpful if you could explain (a) what this library needs to 
do, (b) why it needs to be static, and (c) whether it needs to be 
compiled as PIC (position independent code; suitable for linking in 
shared libraries).

James.

--
Email: james daa com au
WWW:   http://www.daa.com.au/~james/