.la files are removed

[marek...@gmail.com]

Hi,

I'm trying to add some custom software to the Container Linux image, but there is a problem – no .la files are installed in /usr/lib64/soft/plugins/. It isn't about INSTALL_MASK (even tried to comment out .la handling from cores-overlay/profiles/coreos/base/make.defaults) or libtool file pruning. I tried to import some software from Gentoo using .la files for plugins (imagemagick for example) for testing and all .la files are removed from these as well.

Does someone have idea why it's happening and how I can fix this?

Regards,

-- 

Marek Svent

[Andrew Jeddeloh]

Try using

equery-amd64-usr f <package> | grep '.la'

to see if the .la files are in the package to begin with. If they're
not, check the use flags (equery-amd64-usr u <package>) and make sure
they're not being compile time disabled from some use flag.

Hope that helps,
- Andrew

[marek...@gmail.com]

On Wednesday, March 13, 2019 at 6:44:05 PM UTC+2, Andrew Jeddeloh wrote:

Try using

equery-amd64-usr f <package> | grep '.la'

.la files ar not there.

 

to see if the .la files are in the package to begin with. If they're
not, check the use flags (equery-amd64-usr u <package>) and make sure
they're not being compile time disabled from some use flag.

They are not, the package doesn't use any use flags at all. But the package

from the very same ebuild in Gentoo has .la files. And for example imagemagick

imported from Gentoo into CoreOS doesn't have any .la files either. That's why I

think it's something from CoreOS environment.

AFAICS .la files are there after src_install() phase in the temporary location, but

they will not put into package. I just can't find out why.

 

Hope that helps,
 - Andrew

Many thanks for trying, but not yet :).

Regards,

-- 

Marek Svent

[David Michael]

On Wed, Mar 13, 2019 at 5:23 PM <marek...@gmail.com> wrote:
> On Wednesday, March 13, 2019 at 6:44:05 PM UTC+2, Andrew Jeddeloh wrote:
>> Try using
>>
>> equery-amd64-usr f <package> | grep '.la'
>
> .la files ar not there.
>
>> to see if the .la files are in the package to begin with. If they're
>> not, check the use flags (equery-amd64-usr u <package>) and make sure
>> they're not being compile time disabled from some use flag.
>
> They are not, the package doesn't use any use flags at all. But the package
> from the very same ebuild in Gentoo has .la files. And for example imagemagick
> imported from Gentoo into CoreOS doesn't have any .la files either. That's why I
> think it's something from CoreOS environment.
>
> AFAICS .la files are there after src_install() phase in the temporary location, but
> they will not put into package. I just can't find out why.

There can be many points where libtool files are being removed. It
depends on the specific package you're building.

If you're installing packages for a production image, you'll also have
to edit profiles/coreos/targets/generic/prod/make.defaults to remove
.la files from INSTALL_MASK.

Make sure nothing sets the AUTOTOOLS_PRUNE_LIBTOOL_FILES variable.

Look for prune_libtool_files calls in ebuilds.

Build static libraries. The ltprune eclass default install function
removes .la files without a matching .a file (and some ebuilds do this
directly without the eclass).

These are some ways I saw in a few packages I checked; there may be
others. Check all the eclasses inherited by the packages you're
trying to build if that doesn't cover it.

Thanks.

David

[marek...@gmail.com]

On Thursday, March 14, 2019 at 12:00:08 AM UTC+2, David Michael wrote:

If you're installing packages for a production image, you'll also have
to edit profiles/coreos/targets/generic/prod/make.defaults to remove
.la files from INSTALL_MASK.

OK, that was actually it. I knew it's there and thought I tested to remove it, but

obviously not. Or probably I just held it wrong.

The point is that there was no need to remove it before (as seen from

comment as well), but it has been changed probably with last portage

upgrade. Portage had a shell code to deal with INSTALL_MASK before,

but it was switched to python fnmatch(). And now the pattern matches really

any *.la file regardless directory depth while it was meant to match only *.la

files under /usr/lib/ directly.

Many thanks,

-- 

Marek Svent