[RFC] Removing .la files from x86

[RFC] Removing .la files from x86

[Yaakov Selkowitz]

Libtool .la files are generally a waste of time and space.  They slow 
down linking of other libraries with libtool, and they cause otherwise 
unnecessary private dependencies to be pulled in by -devel packages. 
Therefore, the major distros generally remove them from their packages 
unless they are really necessary.

When we first enabled Cygwin for x86_64, as we had no backwards 
compatibility to worry about, I made removing all .la files the default. 
  AFAIK this has worked well, and any missing link libraries that the 
presence thereof would have masked have already been fixed.

In order to do the same for x86 without breaking builds of other 
packages, AFAICS we would need a perpetual postinstall script which will 
continually remove them.  The downside is that (unless the script is 
made a *LOT* more complicated) a number of -devel packages will show up 
as "Incomplete" until such time they are rebuilt with a new version of 
cygport.

Any objections?

-- 
Yaakov

Re: [RFC] Removing .la files from x86

[Warren Young]

On Aug 2, 2016, at 9:09 PM, Yaakov Selkowitz <yselkowitz@cygwin.com> wrote:
> 
> Any objections?

This script would need to consult the same package database cygcheck uses to find out if an installed Cygwin package owns each *.la file it proposes to remove.  It should not remove any other *.la file just because it happens to be in /usr/lib.

It should not remove anything in other common libdirs like /usr/local/lib.  If I’ve installed something from source and its make install rule installs the *.la file, that’s an issue for the upstream provider.

Doesn’t libtool provide some of the magic library dependency chasing that exists on Linux but almost nowhere else?

That is, if library B depends on library C, and library A depends on B, on Linux you generally only need to explicitly link to library A, and the linker will chase down B and C for you.  This doesn’t usually happen on other systems, so you may have to explicitly link to library B, and sometimes to library C as well.

A common practical example is that libpng depends on zlib, but it is sufficient on Linux to link only with -lpng, whereas porting such software to non-Linux systems generally requires appending -lz.

Would we still have that behavior on Windows without the .la files?  If not, it’s possible that some build systems would break.

Re: [RFC] Removing .la files from x86

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1441 bytes --]

On Aug  2 22:09, Yaakov Selkowitz wrote:
> Libtool .la files are generally a waste of time and space.  They slow down
> linking of other libraries with libtool, and they cause otherwise
> unnecessary private dependencies to be pulled in by -devel packages.
> Therefore, the major distros generally remove them from their packages
> unless they are really necessary.
> 
> When we first enabled Cygwin for x86_64, as we had no backwards
> compatibility to worry about, I made removing all .la files the default.
> AFAIK this has worked well, and any missing link libraries that the presence
> thereof would have masked have already been fixed.
> 
> In order to do the same for x86 without breaking builds of other packages,
> AFAICS we would need a perpetual postinstall script which will continually
> remove them.  The downside is that (unless the script is made a *LOT* more
> complicated) a number of -devel packages will show up as "Incomplete" until
> such time they are rebuilt with a new version of cygport.
> 
> Any objections?

User confusion about incomplete packages?

What I wonder is, if cygport builds don't create/install .la files
anymore, don't we end up without them at one point anyway?  Isn't it
sufficient if they go away over time?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [RFC] Removing .la files from x86

[Marco Atzeri]

On 03/08/2016 10:00, Corinna Vinschen wrote:
> On Aug  2 22:09, Yaakov Selkowitz wrote:
>> Libtool .la files are generally a waste of time and space.  They slow down
>> linking of other libraries with libtool, and they cause otherwise
>> unnecessary private dependencies to be pulled in by -devel packages.
>> Therefore, the major distros generally remove them from their packages
>> unless they are really necessary.
>>
>> When we first enabled Cygwin for x86_64, as we had no backwards
>> compatibility to worry about, I made removing all .la files the default.
>> AFAIK this has worked well, and any missing link libraries that the presence
>> thereof would have masked have already been fixed.
>>
>> In order to do the same for x86 without breaking builds of other packages,
>> AFAICS we would need a perpetual postinstall script which will continually
>> remove them.  The downside is that (unless the script is made a *LOT* more
>> complicated) a number of -devel packages will show up as "Incomplete" until
>> such time they are rebuilt with a new version of cygport.
>>
>> Any objections?
>
> User confusion about incomplete packages?
>
> What I wonder is, if cygport builds don't create/install .la files
> anymore, don't we end up without them at one point anyway?  Isn't it
> sufficient if they go away over time?
>
>
> Corinna

I prefer just the change in cygport behaviour.

Please note we have still some *.la files on x86_64
for other reasons and we can not run an indiscriminate prune
on x86.

  $ ls -1 /usr/lib/*.la
/usr/lib/libguilereadline-v-17.la
/usr/lib/libguilereadline-v-18.la
/usr/lib/libguile-srfi-srfi-13-14-v-3.la
/usr/lib/libguile-srfi-srfi-1-v-3.la
/usr/lib/libguile-srfi-srfi-4-v-3.la
/usr/lib/libguile-srfi-srfi-60-v-2.la
/usr/lib/libltdl.la
/usr/lib/libntl.la

Regards
Marco

Re: [RFC] Removing .la files from x86

[Yaakov Selkowitz]

On 2016-08-03 04:18, Marco Atzeri wrote:
> On 03/08/2016 10:00, Corinna Vinschen wrote:
>> On Aug  2 22:09, Yaakov Selkowitz wrote:
>>> Any objections?
>>
>> User confusion about incomplete packages?

That is my concern, although we are generally dealing with -devel 
packages here.  AFAICS the only way to work around that is to make the 
script much more complicated (and hence slower).

>> What I wonder is, if cygport builds don't create/install .la files
>> anymore, don't we end up without them at one point anyway?  Isn't it
>> sufficient if they go away over time?

The problem with that approach is that it would have to be done in a 
top-down order, otherwise builds of other packages would break.  For 
example, libFLAC.la (from flac-devel) requires libogg.la (from 
libogg-devel).  If libogg.la is removed by rebuilding libogg with a new 
cygport but libFLAC.la is not, then any libtool-based packages which 
link with -lFLAC will fail because of the missing libogg.la mentioned 
therein.  Hence, the only way not to break things once they're there is 
to either remove them from the top-down (mass rebuild), or all at once 
(a perpetual postinstall).

> Please note we have still some *.la files on x86_64
> for other reasons and we can not run an indiscriminate prune
> on x86.

I know. :-)  The modules that are kept on x86_64 would be left alone by 
the script.

-- 
Yaakov