[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Confused by .la file removal vs static linking support



On Sun, 2 May 2010 13:17:08 +0400
"Nikita V. Youshchenko" <yoush@debian.org> wrote:

> I'm going to unload a new version, and, among other things, I was
> going to remove .la file, per release-goal

(Thanks for the reminder, the lack of a bug report led to me completely
forgetting that I meant to do something about this goal for my own
packages.)

(Not having .la files that need mangling with dpkg-cross would make
cross-building easier too - apart from the .pc files, the rest of the
dpkg-cross changes would just be moving files around, not modifying
them. One less thing to go wrong, so I'm in favour of removing .la
files generally. Simply removing the contents of dependency_libs isn't
as good - it the .la is an issue, remove all of it IMHO.)

> In http://ftp-master.debian.org/~aba/la/current.txt, package is
> listed as 'libetpan: dependency_libs', so I thoughty I just need to
> remove .la file from -dev package
> 
> However I'm confused with how this interfers with static linking
> support. I've seen talks on this in list archives, but no
> project-scope resolution.

In the discussion that led to the release goal:

"It might happen that we come to the conclusion that
we need to keep a few la-files around, as they might be a help for
static compiling, but static compiling is at best "not the default",
so I would be quite surprised if that's more than 5-10 files (and then
that's the exception that confirms the rule)."
http://lists.debian.org/debian-devel/2009/08/msg00783.html

That's about as resolved as it got AFAICT. Static linking is generally
discouraged, ergo static linking support is expendable if such support
gets in the way of more useful things, like binNMUs - which it does.

> libetpan-dev depends on several other -dev packages because libraries
> from those are mentioned in dependency_libs, and because libraries
> provided by those -dev packages are needed to link statically against
> libetpan.

But does any package in Debian actually do the static linking?

> So, should I:
> 
> (1) just drop .la file, or
> (2) drop .la file, downgrade dependences on -dev packages to
> recommends: or suggests:, or
> (3) drop .la file and dependences on -dev packages, but keep
> libetpan.a, or
> (4) drop .la file and dependences on -dev packages and libetpan.a
> 
> Perhaps (4) is the most consistent solution, since nobody cares about 
> static linking these days. However AFAIU debian's policy is still to 
> provide static libraries.

8.3 - The static library (libraryname.a) is usually provided in
addition to the shared version.

That reads more like Policy documenting usual practice rather than
mandating that static linking is necessarily desirable or should be
explicitly supported even if it causes issues elsewhere.

> (3) looks like plain inconsistency: package will provide .a file, but
> not ensure things required for using .a file into system.
> So I likely should choose from (1) and (2).

Removing the .la and retaining the .a is useful because?

(To actually statically link without the .la (or with an .la 'mangled'
to empty the dependency_libs field) largely amounts to reconstructing
the information that was in the .la originally. That should be
sufficient disincentive to try to statically link at all. Hence, is it
worth wasting archive space on the inevitably much larger .a files?)

Personally, I'm thinking of dropping static support in the Debian
packages by removing the .la and the .a but preserving dependencies
where needed for shared library builds (i.e. Requires: in the .pc file,
not Requires.private, where my library directly exports symbols in it's
own API that are resolved in another shared library.)

-- 


Neil Williams
=============
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/

Attachment: pgpoX7E13Frsm.pgp
Description: PGP signature


Reply to: