[Slackbuilds-users] openzfs warning during compilation

[Jeremy Hansen]

On Mon, Jul 22, 2024, 8:09 AM Matt via SlackBuilds-users <
slackbuilds-users at slackbuilds.org> wrote:

> > Hi all,
> > I'm trying to compile openzfs using SBo.
> >
> > I got a long warning list while running the SB:
> >
> > libtool: warning: relinking 'libzfs_core.la'
> > libtool: warning: 'libzfs.la' has not been installed in '/lib64'
> > libtool: warning: 'libnvpair.la' has not been installed in '/lib64'
> > libtool: warning: relinking 'contrib/pam_zfs_key/pam_zfs_key.la'
> > libtool: warning: '/tmp/SBo/zfs-2.2.4/libzfs_core.la' has not been
> > installed in '/lib64'
>
> ...
>
> > installed in '/lib64'
> > libtool: warning: 'libzfs_core.la' has not been installed in '/lib64'
> > libtool: warning: '/tmp/SBo/zfs-2.2.4/libnvpair.la' has not been
> > installed in '/lib64'
> > libtool: warning: 'libnvpair.la' has not been installed in '/lib64'
> > libtool: warning: 'libuutil.la' has not been installed in '/lib64'
> >
> >
> > Those should be considered critical or this is something expected?
>
> Hi Alessandro,
>
> I ignore these warnings with no issues. If you look at line 118 of
> openzfs.SlackBulid, you can see that the .la files are intentionally
> removed. This is consistent with the SBo autotools template:
> https://slackbuilds.org/templates/autotools-template.SlackBuild
>
> As far as why SBo doesn't ship .la files, I do know. Can anyone share why?
>

This is to match what Slackware does (which historically SBo tries to do).
Pat removed most .la files during the development of 15.0 and SBo rolled it
out when they pushed their 15.0 repo and updated their templates.

Here's the changelog entry from 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
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
In addition to those goals, the opportunity was taken to clean up slack-desc
files and make many trivial fixes to build scripts. We've also made it easy
to recompile everything again should there be a good reason to do so.
You'll also find various updates scattered throughout this long list.
Enjoy, and sorry about the bandwidth. ;-)

Jeremy

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.slackbuilds.org/pipermail/slackbuilds-users/attachments/20240722/3f08f8da/attachment-0001.htm>