Re: poudriere loop: llvm19-19.1.7: missed shlib PORTREVISION chase

From: Mark Millard <marklmi_at_yahoo.com>
Date: Sat, 01 Feb 2025 16:45:03 UTC 
On Feb 1, 2025, at 07:52, Guido Falsi <mad@madpilot.net> wrote:

> On 01/02/25 16:24, Mark Millard wrote:
>> On Feb 1, 2025, at 03:04, Nuno Teixeira <eduardo@freebsd.org> wrote:
>>> Hello Mark!
>>> 
>>> Note: I do not know why, but aarch64 does not get MULTILIB to
>>> also span armv7 (aarch32). So aarch64 might not have this
>>> problem being visible as stands.
>>> 
>>> I confirm that aarch64 doesn't have this problem.
>> This suggests the test of trying to use poudriere-devel with
>> PKG_NO_VERSION_FOR_DEPS=yes to build, say, gcc13 with MULTILIB
>> disabled for the target architecture(s) that would otherwise
>> have it enabled --in order to see if things then work overall,
>> absent the 32-bit support being built for the 64-bit target
>> archtecture.
> 
> I posted sample output fr gcc13 just because I knew it was having the problem at hand. Also other ports (all llvm versions for example, go compilers too) have the same issue, and no similar option.

devel/llvm* use the system libraries. The somewhat analogous
test for the llvm* ports would appear to using poudriere(-devel)
jails that had been built with:

     WITHOUT_LIB32
             On 64-bit platforms, do not build 32-bit library set and a
             ld-elf32.so.1 runtime linker.

If go, for example, just uses the system libraries, the same
sort of thing might apply there. (I do not claim to know.)

I'm only looking at investigative paths for some potentially
useful information. I've made no claim to have identified the
correct overall fix to anything. At this point I can not
tell if the existence of the libraries with the same name but
different paths is required for the problem to occur vs. not.

I will note that there are examples like:

/usr/lib/clang/19/lib/freebsd/libclang_rt.asan-i386.so
/usr/lib/clang/19/lib/freebsd/libclang_rt.asan-x86_64.so

that have distinct file names as well. These may not be
a problem under the new pkg versions. But there are also
the likes of:

/usr/local/llvm19/lib/clang/19/lib/i386-portbld-freebsd15.0/libclang_rt.asan.so
/usr/local/llvm19/lib/clang/19/lib/x86_64-portbld-freebsd15.0/libclang_rt.asan.so

for which the path is different but the file names are not.

Yet both styles are for libclang_rt.asan* .

> Disabling MULTTILIB can at best be a very specific workaround for gcc, and would not solve the underlaying issue whatever that is.

My intent was just to produce some investigative information,
not to provide a fix or even a somewhat useful workaround.

> My patch to poudriere is also a workaround, but I do hope this helps identifying the real problem.



===
Mark Millard
marklmi at yahoo.com