xmerlin: that's unexpected, there's no match for '.libs' in the package itself, can you send me the steps to reproduce?

jperkin, as I can see the problem is related to a pkgconf rebuild ...if I use the pkgconf from pkgsrc.smartos.org/packages/SmartOS…2022Q4/x86_64/All/pkgconf-1.8.0.tgz the output is pastebin.com/8LjvR1V3 --> ok but if I rebuild pkgconf the output is pastebin.com/x7UL2ejV

I've tried pkgconf 1.8.0 (release 2022Q4) and 1.9.4/1.9.5 from trunk

why do you need to rebuild it?

jperkin, because I have my own tree and all the packages are rebuild and signed with the same key

jperkin, Why should a rebuilt package perform differently from the one uploaded to the main mirror?

something in the environment will be different, are you using pkgbuild?

I build only some packages so I build pkgconf using a simple bmake package

the pkgbuild is configured using your guide

one of the main differences is that our packages are always built in a clean environment, pbulk ensures that no other packages are installed prior to each build, so while pkgbuild helps mitigate any changes on the host there may still be issues due to extra packages installed in the chroot

if you perform the build in a clean sandbox first without doing any other builds is it better?

we try to avoid such issues with quite a lot of infrastructure such as buildlink, but sometimes upstream software is too nosy about what it can find by itself and we can't catch all corner cases

I have built the package in a clean sandbox and the result is the same

ok, so I think I'd start looking at differences between your libtool build and mine, that is what will be doing the .libs stuff and maybe it has changed behavior - you should be able to just diff the libtool script itself

but otherwise this is something you'll need to debug

jperkin, there is no difference between mine and yours but as I can see there are some differences between the tools and opt version pastebin.com/U7esWADK

nothing special