Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 12 May 2014 12:48:58 +0200
From:      Tijl Coosemans <tijl@FreeBSD.org>
To:        Matthias Andree <mandree@FreeBSD.org>
Cc:        freebsd-ports@FreeBSD.org
Subject:   Re: To all port maintainers: libtool
Message-ID:  <20140512124858.14ed0301@kalimero.tijl.coosemans.org>
In-Reply-To: <537054DE.70701@FreeBSD.org>
References:  <20140508002420.5d37e7f6@kalimero.tijl.coosemans.org> <537054DE.70701@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 12 May 2014 06:58:06 +0200 Matthias Andree wrote:
> Issue #1: .la files
> 
> I just received PR 189491 (which proposes USES=libtool:keepla) and
> looked at it, and thought it good to kill the .la files, so I have tried
> USES=libtool, without keepla or stuff.

The ports are depended on by a lot of other ports so I'd be careful with
deleting the .la files.

> The port also has a patch to flip from -avoid-version to -version-info
> 0:0:0, and I tried to build with or without.
> (It should not matter much because libdb does not have non-system
> requisites, i. e. the port has no LIB_DEPENDS - it only uses libpthreads.)
> 
> Now, with USES=libtool added, I either have both the foo.so.0 and
> foo.so.0.0.0 files, with the SONAME being the libdb-4.8.so.0, or if I
> leave the original upstream -avoid-version setting, I get libdb-4.8.so
> as SONAME and see libdb-4.8.so.0 files missing.
> 
> With USES=libtool:keepla, this does not happen.
> 
> It is utterly unclear to me how that fits together, so my first question
> is: can you reproduce this behaviour, or is my system goofing up?
> 
> What concerns me about that is (1) that the file matching the SONAME of
> the library is merely a symlink, and (2) that the USES=libtool:keepla
> option apparently might have more effects than documented, namely,
> adding more library_names with the .0.0.0 and .0 suffix.

During compilation and installation the behaviour with and without :keepla
is exactly the same.  So except for the .la files you should see exactly
the same content in the staging area.

For ports like this though, that meddle with version-info it's ok to add
something like this to the Makefile:

# TODO: remove :oldver together with patch-dist::configure
USES=	libtool:oldver

Then it will be dealt with when we can start moving away from :oldver.
I already did something like this in graphics/imlib, graphics/jpeg and
graphics/tiff.

> Issue #2: libpthread.  An .la file might look like this:
> 
> [...]
>> # Linker flags that can not go in dependency_libs.
>> inherited_linker_flags=' -pthread'
>> 
>> # Libraries that this one depends upon.
>> dependency_libs=' -lpthread'
> [...]
> 
> Now, if I remove the .la file, and a slave port that uses libtool to
> link will then have to list -pthread explicitly on the newer FreeBSD
> releases (because those fail linking if indirect .so requisites are
> missing).

Yes, but this is no different from other libraries.  If some other
port needs libpthread it should link to it itself.  It's not this
port's responsibility.

> :keepla causes the inherited_linker_flags=-pthread to remain set, so I
> presume it is safe in this case.
>   However, it does not appear to me that keepla is a temporary measure
> here, but it looks like it needs to stay forever.

:keepla will stay yes, because it's possible for a port to use them,
e.g. in combination with libltdl.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140512124858.14ed0301>