[SOLVED] Slackbuilds and "don't ship .la files"

JayByrd · 09-08-2021, 12:21 PM

I understand that it has been practice for many years now to remove .la files from software packages before calling makepkg. I've read volkerdi's post where he explained the rationale.

Accordingly, I've added the standard "remove .la" routine to a SlackBuild script that I'm working on.

Code:

# Don't ship .la files:
rm -f $PKG/{,usr/}lib${LIBDIRSUFFIX}/*.la

When complete, I notice that there are still about a dozen *.la files in my final package. Apparently, they (the retained .la files) are being missed by the above "rm" command because they do not reside in usr/lib64. Rather, for this package, "make install" places them in usr/lib64/subdirectory1/subdirectory2/blahblah.la

Based on the aforementioned post--where volkerdi states the goal of "shipping as few .la files as possible (and hopefully someday none at all)"--I've gone ahead and replaced the simple "rm" with the following:

Code:

# Don't ship .la files:
#rm -f $PKG/{,usr/}lib${LIBDIRSUFFIX}/*.la
find $PKG/usr/lib${LIBDIRSUFFIX} -name "*.la" -exec rm -v "{}" \+

This worked: I now have a package with "none at all"--i.e., all *.la files have been successfully purged before invoking makepkg.

But, seeing as how the simple "rm" command quoted above was taken directly from Slackware's official SlackBuild scripts, it seems that Slackware itself is content to let slide those *.la files that are found in subdirectories of usr/lib(64). (or am I missing something?)

In light of this, I'm beginning to question whether my "find" command is too aggressive. That is to say, do we really want to remove all *.la files, or just the ones in lib(64) itself?

TIA,
Jay

LuckyCyborg · 09-08-2021, 12:27 PM

Quote:

Originally Posted by JayByrd

Based on the aforementioned post--where volkerdi states the goal of "shipping as few .la files as possible (and hopefully someday none at all)"--I've gone ahead and replaced the simple "rm" with the following:

Code:

# Don't ship .la files:
#rm -f $PKG/{,usr/}lib${LIBDIRSUFFIX}/*.la
find $PKG/usr/lib${LIBDIRSUFFIX} -name "*.la" -exec rm -v "{}" \+

This worked: I now have a package with "none at all"--i.e., all *.la files have been successfully purged before invoking makepkg.

That's bad.

It was discussed in the past about this "full" removal of the .la files, and I understand that's quite bad, because the plugins, drivers, whatever things which are libraries outside of the standard library paths, they still need their .la files.

So, the .la files should be removed only from the library paths (just like Slackware do), otherwise bad things will happen.

ponce · 09-08-2021, 12:36 PM

Hi Jay, it seems you missed an important part of what Pat wrote in the ChangeLog: I'll paste the whole bit below

Quote:

Originally Posted by Pat

Thu Apr 19 01:04:06 UTC 2018
Hi folks, and welcome to the third ever Slackware Mass Rebuild (and the
longest ChangeLog entry in project history). There were two primary
motivations for rebuilding everything in the main tree. The first was to
switch to the new C++ ABI. The second was to get rid of all the .la files
in the LD_LIBRARY_PATH. Really, having .la files installed has been mostly
obsolete since things began to use pkg-config instead, but it's not easy
to get rid of them unless you do it all at once. If you just take them out
of one package, any other packages containing .la files that refer to the
removed ones will be broken. We've removed a few here and there before
(and then handled any packages that had referred to them with a rebuild),
but it was time to finally remove all the ones in /lib{,64} and
/usr/lib{,64}. One of the reasons that this really needed to happen is that
many projects are starting to migrate to build systems other than autotools,
and those systems do not generate .la files. So if we didn't get rid of them
now, we might end up in a situation later on where they are being removed
by upstream and then we would have to chase down the dependency breakage and
recompile (possibly many) other packages. The .la files that are outside of
the LD_LIBRARY_PATH were not removed (and shouldn't be) - those ones are
often used by the lt_dlopen() function to load plugins and removing those
ones can break things. But those ones don't cause problems... they aren't
likely to try to infect .la files produced by other packages.
IMPORTANT NOTE: If you have any third party or other packages installed on
your system that don't come with Slackware, and those packages have installed
any .la files, it is very likely that they refer to some .la files which we
have just removed, and that trying to compile against these packages will no
longer work. Luckily, the solution is simple: remove them. This command will
remove any stale .la files from the LD_LIBRARY_PATH:
rm /{,usr/}lib{,64}/*.la
Moving forward, nothing shipped in Slackware will contain any .la files in
those directories, and any SlackBuilds intended to be used with Slackware 15.0
should contain this bit of script:
# Don't ship .la files:
rm -f $PKG/{,usr/}lib${LIBDIRSUFFIX}/*.la

JayByrd · 09-08-2021, 12:52 PM

Thanks, LC and ponce. It turns out my intuition was right...

That is, after I read volkerdi's statement about "none at all," I added the "find" command. Since I had about an hour of build time to contemplate the situation, I began to think to myself: "But if this 'find' was really necessary, wouldn't volkerdi put it in his SlackBuilds?"

The fact that official Slackware build scripts remove the *.la files from only lib(64) and usr/lib(64) led me to question my use of the "find" command to remove them all.

@ponce
Another valuable lesson you've imparted: always search the Changelog first!

Thanks again, both of you.
Marking this as solved.

Toutatis · 09-08-2021, 02:07 PM

I have still .la files in /usr/lib64 from packages l/libgtop-2.40.0-x86_64-4.txz and xfce/mousepad-0.5.6-x86_64-1.txz

drumz · 09-08-2021, 03:19 PM

Quote:

Originally Posted by Toutatis

I have still .la files in /usr/lib64 from packages l/libgtop-2.40.0-x86_64-4.txz and xfce/mousepad-0.5.6-x86_64-1.txz

Confirmed here:

Code:

# find /usr/lib64 -maxdepth 1 -name "*.la"
/usr/lib64/libgtop-2.0.la
/usr/lib64/libmousepad.la

# grep usr/lib64/libgtop-2.0.la /var/lib/pkgtools/packages/*
/var/lib/pkgtools/packages/libgtop-2.40.0-x86_64-4:usr/lib64/libgtop-2.0.la

# grep usr/lib64/libmousepad.la /var/lib/pkgtools/packages/*
/var/lib/pkgtools/packages/mousepad-0.5.6-x86_64-1:usr/lib64/libmousepad.la

Both SlackBuilds are missing the

Code:

# Don't ship .la files:
rm -f $PKG/{,usr/}lib${LIBDIRSUFFIX}/*.la

bit.

Skaendo · 09-08-2021, 03:45 PM

Quote:

Originally Posted by JayByrd

I understand that it has been practice for many years now to remove .la files from software packages before calling makepkg. I've read volkerdi's post where he explained the rationale.

Accordingly, I've added the standard "remove .la" routine to a SlackBuild script that I'm working on.

Code:

# Don't ship .la files:
rm -f $PKG/{,usr/}lib${LIBDIRSUFFIX}/*.la

When complete, I notice that there are still about a dozen *.la files in my final package. Apparently, they (the retained .la files) are being missed by the above "rm" command because they do not reside in usr/lib64. Rather, for this package, "make install" places them in usr/lib64/subdirectory1/subdirectory2/blahblah.la

Based on the aforementioned post--where volkerdi states the goal of "shipping as few .la files as possible (and hopefully someday none at all)"--I've gone ahead and replaced the simple "rm" with the following:

Code:

# Don't ship .la files:
#rm -f $PKG/{,usr/}lib${LIBDIRSUFFIX}/*.la
find $PKG/usr/lib${LIBDIRSUFFIX} -name "*.la" -exec rm -v "{}" \+

This worked: I now have a package with "none at all"--i.e., all *.la files have been successfully purged before invoking makepkg.

But, seeing as how the simple "rm" command quoted above was taken directly from Slackware's official SlackBuild scripts, it seems that Slackware itself is content to let slide those *.la files that are found in subdirectories of usr/lib(64). (or am I missing something?)

In light of this, I'm beginning to question whether my "find" command is too aggressive. That is to say, do we really want to remove all *.la files, or just the ones in lib(64) itself?

TIA,
Jay

I've actually been using:

Code:

find $PKG -type f -name '*.la' -delete

on current for quite a while and have had no issues.

solarfields · 09-09-2021, 01:00 AM

Quote:

Originally Posted by Skaendo

I've actually been using:

Code:

find $PKG -type f -name '*.la' -delete

on current for quite a while and have had no issues.

Isn't this going to remove all *.la files, something that is not recommended?

drumz · 09-09-2021, 07:31 AM

Quote:

Originally Posted by Skaendo

I've actually been using:

Code:

find $PKG -type f -name '*.la' -delete

on current for quite a while and have had no issues.

Quote:

Originally Posted by solarfields

Isn't this going to remove all *.la files, something that is not recommended?

Yes it would.

Candelabrus · 09-09-2021, 09:39 AM

I never had a problem to delete all the .la files, i do this for all my slackbuilds and i do not remember having some problem related to it.

What would be the eventual problem?

Skaendo · 09-09-2021, 10:09 AM

IIRC, Arch Linux doesn't ship ANY *.la files.

I have been removing ALL *.la files from my own packages for literally years and haven't had any issues.

And this is what the OP was considering as well.

Do I recommend it? I dunno. I can only say from my own experience that I have not had any problems removing them all from my own packages.

My SlackBuilds on SBo will come with the "standard" that they use of course.

Skaendo · 09-09-2021, 10:42 AM

It looks like Arch Linux hasn't shipped any *.la files since at least 2005:
https://bbs.archlinux.org/viewtopic.php?id=14936

Further reading: https://flameeyes.blog/2008/04/14/wh...hose-la-files/

drumz · 09-09-2021, 03:10 PM

Quote:

Originally Posted by Toutatis

I have still .la files in /usr/lib64 from packages l/libgtop-2.40.0-x86_64-4.txz and xfce/mousepad-0.5.6-x86_64-1.txz

Fixed in latest update:

Code:

Thu Sep 9 18:51:50 UTC 2021
a/grub-2.06-x86_64-3.txz: Rebuilt.
       Fix unreadable XFS filesystem with v4 superblock. Thanks to Didier Spaier.
d/python-setuptools-58.0.4-x86_64-1.txz: Upgraded.
d/rust-1.55.0-x86_64-1.txz: Upgraded.
l/gst-plugins-base-1.18.5-x86_64-1.txz: Upgraded.
l/gst-plugins-good-1.18.5-x86_64-1.txz: Upgraded.
l/gst-plugins-libav-1.18.5-x86_64-1.txz: Upgraded.
l/gstreamer-1.18.5-x86_64-1.txz: Upgraded.
l/libgtop-2.40.0-x86_64-5.txz: Rebuilt.
       Don't ship .la files. Thanks to Toutatis.
l/pipewire-0.3.35-x86_64-1.txz: Upgraded.
n/dnsmasq-2.86-x86_64-1.txz: Upgraded.
xfce/mousepad-0.5.6-x86_64-2.txz: Rebuilt.
       Don't ship .la files. Thanks to Toutatis.