[SOLVED] Question about "Don't ship .la files"

I have browsed a few slackbuilds over the years and have noticed that slackbuild scripts for current have the "Don't ship .la files" bit that removes these files from the build directory before building the package.

Today I was poking around /var/lib/pkgtools/packages/ and I started noticing .la files. Then I entered the following bit and the result surprised me:

cat /var/lib/pkgtools/packages/* | grep -c "\.la$"
1501

Is anyone else seeing this?

My system was last upgraded around 2 weeks ago so its not too far behind the most recent current development. If you take the "-c" off grep it shows lots of files that are from recent slackware upgrades (within the last months).

I'm hoping that this is a silly question and that things are not borked here. I'm not sure what changed but this doesn't appear normal.

here I don't see any *.la file in /usr/lib64 installed by packages that come with Slackware, there are some in subdirectories but those are not to be removed, as explained in the ChangeLog:

Originally Posted by The ChangeLog 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

also, if you have installed third party packages they might ship their own *.la files in /usr/lib${LIBDIRSUFFIX}.
the scripts of the unofficial SBo fork for current are an example, and they will be edited to remove *.la files only when Slackware 15.0 will be about to be released, but if you built your packages from that repository on a current installation post-april 2018, you shouldn't need to remove them as indicated in the ChangeLog, everything should work as it is.

Thanks for pointing out that changelog ponce. I have read it before but its been a while so it slipped my mind. The majority of these .la files are in subdirectories of /usr/lib64/, with only 28 actually in /usr/lib64. I'm guessing those are from 3rd party packages and I'll go through those to see where they came from.

At least I'm not going crazy!

Edit: Looks like the remainders in /usr/lib64 are from some alien packages I have installed recently.