Re: [ptxdist] [PATCH] openssl: add dependency to libatomic

[Christian Melki <christian.melki@t2data.com>]

On 4/11/23 08:24, Robert Schwebel wrote:
> On Sat, Apr 08, 2023 at 10:57:44PM +0200, Christian Melki wrote:
>>>>> Hmm, with ptxdist-2023.04.0, I don't get the corresponding error any
>>>>> more (and instead a reason warning that libatomic is unused). Let's drop
>>>>> this for now.
>>>>
>>>> atomic is going to be highly dependent on toolchain, arch etc.
>>>> unless you're going to be more specific I suspect complains will happen
>>>> in both directions.
>>>
>>> True - now with the change removed, I see the issue on MIPS. Our
>>> "reason" checker now claims that /usr/lib/libcrypto.so.3 depends on
>>> libatomic.so.1 which is not there. v7a and v8a and x86_64 seem to be
>>> happy without it.
>>>
>>>> I'd be more interested why and where this pops up than adding a
>>>> blanket _ATOMIC.  Ie. I agree on the drop. :)
>>>
>>> I'm a bit unsure what to do now :)
>>
>> Toolchain versions?
> 
> Same as before: 
> OSELAS.Toolchain-2022.10.0/mips-softfloat-linux-gnu/gcc-12.2.1-glibc-2.36-binutils-2.39-kernel-6.0.5-sanitized
> 

Ack.

>> What mips are we talking about?
> 
> See above, mips-softfloat-linux-gnu.
>

Hmm, the actual target mips is? I don't know what gcc does for mips if
you're not specifying a emission set or some tune.

>> If a sufficiently modern gcc doesn't provide a complete set of
>> intrinsics for atomics then libatomic is going to be the only choice.
> 
> At least some configure scripts report
> "checking for lock-free atomic intrinsics... yes"
> 

Actually, this line would indicate that it shouldn't be dependent on
libatomic. Lock-free atomic intrinsics Sounds like a bug? Or something
in the build that is forcing -latomic anyway.

>> Can you figure out what symbols would be attached to libatomic?
> 
> rsc@dude05:~/work/DistroKit$ selected_toolchain/mips-softfloat-linux-gnu-nm -n platform-mips/packages/openssl-3.1.0/usr/lib/libcrypto.so.3 | grep LIBATOMIC
>          U __atomic_fetch_or_8@LIBATOMIC_1.0
>          U __atomic_is_lock_free@LIBATOMIC_1.0
>          U __atomic_load_8@LIBATOMIC_1.0
> 

Ok. So iiuc, 64-bit atomics and it should be covered?
Hmm. -wl as-needed for latomics? Or something is forcing linking.

>> I'm suspecting that if you have an older gcc(?) some intrinsics might
>> not be available.
> 

Ok. So we can drop this track. Not old.

> rsc