BUG: libtool warning: '../src/libseccomp.la' has not been installed in '/usr/lib64' when running configure

[sailinggalaxians]

I'm trying to correctly package libseccomp-static for Mageia as such package doesn't exist amongst the libseccomp related packages. The reason is that the snapd.spec file demands this package in order for snapd to be built. As I run rpmbuild -ba libseccomp.spec I run into this warning message during the output:

libtool: warning: '../src/libseccomp.la' has not been installed in '/usr/lib64'

Secondly before that I see:

libtool: warning: remember to run 'libtool --finish /usr/lib64'

Here's the spec file libseccomp spec file.log

What's the easiest way to fix that?

[pcmoore]

Hi @sailinggalaxians,

Have you looked at how other distros package and ship libseccomp? Here at the upstream project we generally don't spend a lot of time looking at how distros package libseccomp so I don't have a lot of ideas off the top of my head, but we can look into this if the problem is widespread.

Please report back and let us know what you find with respect to other distros.

[zippy2]

It was added by the following commit which does not justify it at all:

https://src.fedoraproject.org/rpms/snapd/c/635e8856c417ac58768fa7a347ec46e76dfba3f9

Looking into libseccomp.spec I can see it defines -static package:

https://src.fedoraproject.org/rpms/libseccomp/blob/rawhide/f/libseccomp.spec

@sailinggalaxians maybe you need to fix the specfile in Mageia then? I have no idea where those live for Mageia, sorry.

[Umeaboy]

I'm no expert, but is this an issue with ./configure? Should I run autoreconf before?

[Umeaboy]

I can reproduce the issue with the Rawhide spec as well. It builds, but the error about libseccomp.la not being put in /usr/lib64 still remains.

Should I run a flag with configure or is this bigger than that?

I can try to build a local version of libtool to see if I can reproduce this then.

[Umeaboy]

I have also checked how the other distributions package it and they basically use the same reasoning overall.

[pcmoore]

Hi all,

I'm not sure there is a lot we can do to help this upstream, it seems like a distro packaging issue to me, or am I misunderstanding things? Does anyone have a suggested change for upstream? If not, I'm tempted to close this out as NOTABUG ...

Thoughts @drakenclimber?

[MageiaLinuxOnSiliconDevices]

This happens even if you manually try to build from the source so this is an issue with either the source itself or with the way autoreconf works. I'm not an expert at all though.

[pcmoore]

I'm sorry all, but I'm still having difficulty finding what we would need to change in the upstream code; there is no hardcoded library path in src/Makefile.am and in all the build/install tests I've done on my test system, the "libseccomp.la" file ends up in the proper ${libdir} directory and I see nothing in the make install output showing the error you've reported.

If you can help me understand what we are doing wrong upstream we'll do our best to fix it, but from everything I can see we are doing the right things. I really need some pointers on what we should be doing differently ...

For reference, here is how I installed under "\<prefix>/usr/lib64":

% mkdir /tmp/seccomp
% ./configure --prefix=/tmp/seccomp --libdir=/tmp/seccomp/usr/lib64 --enable-python
% make
% make install

[MageiaLinuxOnSiliconDevices]

That fixed my issue. Seems like Mageia forgot (or chose NOT to use it?) to use --libdir=/usr/lib64 --enable-python in their spec. Closing this as fixed from my sailinggalaxians user. Feel free to reopen if anyone still have this issue.

[sailinggalaxians]

My mistake......... It won't build even with the right instructions, therefore reopening.

[sailinggalaxians]

Here's the spec file I used libseccomp.txt .

[sailinggalaxians]

Libseccomp build output.txt

Build log

[pcmoore]

Here's the spec file I used libseccomp.txt .

Have you considered using the %configure macro instead of a raw configure call? For example:

%configure --enable-python

You can look at the Fedora specfile as an example.

If you are using a raw configure call, you may need to use other macros for "libdir". This may not be correct, but something like this:

configure --enable-python --libdir=%{buildroot}/%{_libdir}

[pcmoore]

It has been a few months and I believe the RPM macro solution is the proper answer to this problem so I'm going to close this issue, if you feel that there is still a problem please re-open this issue.