Re: For devel/llvm18 context: Bad llvm18 *.so file names? Bad references to llvm18 *.so file names? libLLVM-18.so vs. libLLVM-18rc.so ?

On Feb 6, 2024, at 16:44, Brooks Davis <brooks@freebsd.org> wrote:

> On Tue, Feb 06, 2024 at 04:22:51PM -0800, Mark Millard wrote:
>> On Feb 6, 2024, at 15:11, Mark Millard <marklmi@yahoo.com> wrote:
>> 
>>> On Feb 6, 2024, at 15:02, Mark Millard <marklmi@yahoo.com> wrote:
>>> 
>>>> Using BE_STANDRD, I built llvm18 as part of a poudriere
>>>> bulk run, which resulted in:
>>>> 
>>>> # ls -Tlod /usr/local/llvm18/lib/libLLVM*.so
>>>> lrwxr-xr-x  1 root wheel uarch        15 Feb  6 13:34:30 2024 /usr/local/llvm18/lib/libLLVM-18.1.0rc.so -> libLLVM-18rc.so
>>>> -rwxr-xr-x  1 root wheel uarch 138305928 Feb  6 13:30:11 2024 /usr/local/llvm18/lib/libLLVM-18rc.so
>>>> lrwxr-xr-x  1 root wheel uarch        15 Feb  6 13:34:30 2024 /usr/local/llvm18/lib/libLLVM.so -> libLLVM-18rc.so <http://libllvm-18rc.so/>
>>> Sorry for the confusing additional notation:
>>> 
>>>> <http://libllvm-18rc.so/>
>>> 
>>> that showed in in the E-mail. I had not noticed at the time that
>>> the mail program was helping me in that way: it was not deliberate
>>> on my part.
>>> 
>>>> But later in the pooudriere bulk run when mesa-dri tried to build
>>>> it complained about not finding libLLVM-18.so <http://libllvm-18.so/> :
>>>> 
>>>> [amd64_ZFS] Extracting llvm-18_1,1: .......... done
>>>> ===>   mesa-dri-23.3.5 depends on shared library: libLLVM-18.so - not found
>> 
>> The following suggest more names that might be problematical
>> in devel/llvm18 as thigns are --and includes the *rc.so one:
>> 
>> # grep "\<rc\>" /usr/ports/devel/llvm18/pkg-plist
>> bin/llvm-rc%%LLVM_SUFFIX%%
>> llvm%%LLVM_SUFFIX%%/bin/llvm-rc
>> llvm%%LLVM_SUFFIX%%/lib/libLLVM-%%LLVM_RELEASE%%rc.so
>> %%CLANG%%llvm%%LLVM_SUFFIX%%/lib/libclang.so.%%LLVM_RELEASE%%rc
>> %%LLDB%%llvm%%LLVM_SUFFIX%%/lib/liblldb.so.%%LLVM_RELEASE%%rc
> 
> This comes from upstream and will change with the release:
> 
> https://github.com/llvm/llvm-project/commit/22683463740e55e7e0d7e664395c30899b229205
> 
> I wonder if mesa is inappropriately hard coding the library name or if
> there's a cmake file issue that should be resolved upstream (those
> generally seem to reference static libs though).
> 
> $ llvm-config18 --libs
> -lLLVM-18rc
> 

Looking at /usr/ports/Mk/Uses/llvm.mk it does not
seem to deal with the "rc" naming unless
_LLVM_MK_VALID_VERSIONS has the rc listed. Picking
the .so notation handling as an example . . .

_LLVM_MK_VALID_VERSIONS=        10 11 12 13 14 15 16 17 18

will not produce _LLVM_MK_LIBLLVM with an rc via
its notation: libLLVM-${_LLVM_MK_VERSION}.so

unless _LLVM_MK_VALID_VERSIONS is instead:

_LLVM_MK_VALID_VERSIONS=        10 11 12 13 14 15 16 17 18rc


In turn:

_LLVM_MK_PATH_lib= ${_LLVM_MK_LIBLLVM}
LLVM_LIBLLVM= ${_LLVM_MK_LIBLLVM}
LLVM_VERSION= ${_LLVM_MK_VERSION}

would not have rc for the just "18" case.

There are other problems like comparisons, such as:

.    if ${_LLVM_MK_CONSTRAINT_min} > ${_LLVM_MK_VERSION}

where if _LLVM_MK_VERSION and/or _LLVM_MK_CONSTRAINT_min
contains the rc the result is possibly not as desired?

So is:

_LLVM_MK_VALID_VERSIONS=        10 11 12 13 14 15 16 17 18rc

the intent during the rc stages? Does that really work?


===
Mark Millard
marklmi at yahoo.com