Bug 76363

Summary: libtool15 port must install .la files
Product: Ports & Packages Reporter: Joe Orton <jorton>
Component: Individual Port(s)Assignee: Ade Lovett <ade>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: Latest   
Hardware: Any   
OS: Any   

Description Joe Orton 2005-01-17 18:30:31 UTC 
The libtool .la files are a well-defined part of the libtool interface, yet the libtool15 port has been patched to not install .la files.  The Apache APR project, the portability used by projects such as Apache httpd 2.0 and Subversion, relies upon the existence of .la files for carrying inter-library dependencies between projects.

Yes, the .la files are superfluous for carrying inter-library dependencies on some platforms such as FreeBSD.  This is not true for all platform, so APR chose a solution which *is* portable to all platforms: link against the libtool .la file.

Now, with this fundamental part of the libtool interface removed in the FreeBSD port, people cannot correctly use APR, with strange failure modes due to missing .la files.  Please can this be reverted?

Fix: 

revert the patch to regain upstream behaviour
Comment 1 Michael Nottebrock freebsd_committer freebsd_triage 2005-01-17 21:01:43 UTC 
Responsible Changed
From-To: freebsd-ports-bugs->ade

Over to maintainer.
Comment 2 Michael Nottebrock 2005-01-17 21:08:39 UTC 
As a KDE port-maintainer (and KDE also very much liking and depending on 
libtool-archives, too, at times) I quite agree about not installing libtool 
archives by default being somewhat stupidly egocentric.

However: FreeBSD ports can use a simple modification that will cause libtool 
archives to be installed (usually the port Makefile just needs to specify 
USE_INC_LIBTOOL_VER instead of USE_LIBTOOL_VER).

So, if you could point out individual ports that should install libtool 
archives, the respective maintainers could make them do so.

-- 
   ,_,   | Michael Nottebrock               | lofi@freebsd.org
 (/^ ^\) | FreeBSD - The Power to Serve     | http://www.freebsd.org
   \u/   | K Desktop Environment on FreeBSD | http://freebsd.kde.org
Comment 3 jorton 2005-01-17 21:19:14 UTC 
On Mon, Jan 17, 2005 at 10:08:39PM +0100, Michael Nottebrock wrote:
> As a KDE port-maintainer (and KDE also very much liking and depending on 
> libtool-archives, too, at times) I quite agree about not installing libtool 
> archives by default being somewhat stupidly egocentric.
> 
> However: FreeBSD ports can use a simple modification that will cause libtool 
> archives to be installed (usually the port Makefile just needs to specify 
> USE_INC_LIBTOOL_VER instead of USE_LIBTOOL_VER).
> 
> So, if you could point out individual ports that should install libtool 
> archives, the respective maintainers could make them do so.

The issue I'm concerned about is making the default behaviour of libtool
correct for people who build applications on FreeBSD outside the ports
framework.

Making platform-specific hacks to libtool like this in the packaged
versions of libtool is a real headache for projects trying to write
portable software based on libtool.  The whole point of libtool is that
it is supposed to provide a consistent interface for building libraries
across platforms.  Changing it so radically for $host in *freebsd really
defeats that point.

Regards,

joe
Comment 4 Michael Nottebrock 2005-01-17 22:08:04 UTC 
What you want it the devel/gnu-libtool port.

-- 
   ,_,   | Michael Nottebrock               | lofi@freebsd.org
 (/^ ^\) | FreeBSD - The Power to Serve     | http://www.freebsd.org
   \u/   | K Desktop Environment on FreeBSD | http://freebsd.kde.org
Comment 5 Ade Lovett freebsd_committer freebsd_triage 2005-01-18 00:12:55 UTC 
Joe Orton wrote:
>  The issue I'm concerned about is making the default behaviour of libtool
>  correct for people who build applications on FreeBSD outside the ports
>  framework.

For developing applications, you'll probably find considerably better 
luck using the devel/gnu-libtool, devel/gnu-autoconf, and 
devel/gnu-automake ports -- particularly for use with IDEs.

Due to some truly staggering deficiences in the whole 
libtool/autoconf/automake code -- an almost endemic lack of caring 
regarding backwards compatibility for one, the primary focus of the 
"versioned autotools" ports in the tree is to provide a vaguely coherent 
build infrastructure FOR OTHER PORTS IN THE TREE.

Anything else is pretty much a bonus, which is why the gnu-* ports came 
into being, since after considerable thought, it was going to be 
essentially impossible for one set of autotools-ports to handle both 
in-tree and out-of-tree building.

The GNOME IDEs use these, and KDE probably should be too.  Of course, 
should anything require newer versions than what's available in the 
gnu-* ports, then there's the whole headache of versioning again, but 
that issues lies squarely at the feet of the autotools developers.

>  The whole point of libtool is that
>  it is supposed to provide a consistent interface for building libraries
>  across platforms.

Unfortunately, any semblence of consistency has already been destroyed 
by the two amazingly incompatible versions of libtool out there that are 
in heavy use, namely 1.3.5 and 1.5.10 -- and things get even sillier for 
autoconf and automake.

Various hacks employed by various other operating systems, such as 
providing wrapper scripts which attempt to detect the "correct" version 
of the tool to use suffer from their own significant problems, not the 
least of which are the huge number of configure-style scripts out there 
that blindly assume that if aclocal (for example) happens to be in the 
PATH, then it *must* be used, even though (a) it usually doesn't need to 
be and (b) short of hacking the script itself, which sometimes causes 
its own problem, there is NO way to turn this behavior off.

Of course, if someone out there believes they can do better and 
understands the constraints, I'll quite happily hand over maintainership 
of these ports.

Last time around, the response was underwhelming :)

-aDe
Comment 6 Michael Nottebrock 2005-01-18 06:56:46 UTC 
Ade Lovett wrote:

> The GNOME IDEs use these, and KDE probably should be too.

The problem with KDE is more that some KDE programs would like their 
dependencies to install libtool-archives and it is a bit of a nuisance^W^W^W^W 
world of pain to make port maintainers forget all the "libtool archives are 
bad" crap they have been taught by portlint and various committers who keep 
the anti-.la movement alive.

And this is not just me ranting, I am currently making patches for imlib2 to 
use USE_INC_LIBTOOL_VER - imlib2 uses lt_dlopenext to load its image plugins, 
but of course the port was made to be portlint-conformant, thus, in this case, 
broken.

FWIW, I am not blaming you, Ade - I do not know who really started the 
we-dont-need-no-libtool-archives urban legend in FreeBSD, must have happened 
somewhere around a.out->elf switch time and I've not been around back then. 
Whoever did it, it is one hell of a legacy...

-- 
    ,_,   | Michael Nottebrock               | lofi@freebsd.org
  (/^ ^\) | FreeBSD - The Power to Serve     | http://www.freebsd.org
    \u/   | K Desktop Environment on FreeBSD | http://freebsd.kde.org
Comment 7 peter 2005-01-18 15:56:24 UTC 
Hi,
Slightly off-topic, but if the freebsd libtool port maintainers could 
possibly join the libtool mailing list we might manage to ship a 
libtool that makes you happy. We are unlikely to do so without your 
help. As far as I know none of the current libtool maintainers use 
FreeBSD as their main system.

Peter

P.S. Please install the .la files we use them for lt_dlopen and linking.
Comment 8 Ade Lovett freebsd_committer freebsd_triage 2005-01-18 16:14:04 UTC 
State Changed
From-To: open->closed

This is neither "serious", nor "high", nor does it contain anything 
that has not been repeatedly discussed on the freebsd mailing lists 
before.