mailarchive of the ptxdist mailing list
 help / color / mirror / Atom feed
* [ptxdist] [PATCH] openssl: add dependency to libatomic
@ 2023-04-04  8:00 Robert Schwebel
  2023-04-08 13:08 ` Robert Schwebel
  0 siblings, 1 reply; 7+ messages in thread
From: Robert Schwebel @ 2023-04-04  8:00 UTC (permalink / raw)
  To: ptxdist; +Cc: Robert Schwebel

Since openssl 3.x, libcrypto needs libatomic, at least on several 32 bit
platforms (and on 64 bit it doesn't harm).

Signed-off-by: Robert Schwebel <r.schwebel@pengutronix.de>
---
 rules/openssl.in | 1 +
 1 file changed, 1 insertion(+)

diff --git a/rules/openssl.in b/rules/openssl.in
index 629ee3057..a86ca66a2 100644
--- a/rules/openssl.in
+++ b/rules/openssl.in
@@ -4,6 +4,7 @@ menuconfig OPENSSL
 	tristate
 	select LIBC_DL
 	select GCCLIBS_GCC_S
+	select GCCLIBS_ATOMIC
 	select CRYPTODEV_API		if OPENSSL_CRYPTODEV && BUILDTIME
 	prompt "openssl                       "
 	help
-- 
2.39.2




^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [ptxdist] [PATCH] openssl: add dependency to libatomic
  2023-04-04  8:00 [ptxdist] [PATCH] openssl: add dependency to libatomic Robert Schwebel
@ 2023-04-08 13:08 ` Robert Schwebel
  2023-04-08 13:20   ` Christian Melki
  0 siblings, 1 reply; 7+ messages in thread
From: Robert Schwebel @ 2023-04-08 13:08 UTC (permalink / raw)
  To: ptxdist

On Tue, Apr 04, 2023 at 10:00:26AM +0200, Robert Schwebel wrote:
> Since openssl 3.x, libcrypto needs libatomic, at least on several 32 bit
> platforms (and on 64 bit it doesn't harm).
> 
> Signed-off-by: Robert Schwebel <r.schwebel@pengutronix.de>
> ---
>  rules/openssl.in | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/rules/openssl.in b/rules/openssl.in
> index 629ee3057..a86ca66a2 100644
> --- a/rules/openssl.in
> +++ b/rules/openssl.in
> @@ -4,6 +4,7 @@ menuconfig OPENSSL
>  	tristate
>  	select LIBC_DL
>  	select GCCLIBS_GCC_S
> +	select GCCLIBS_ATOMIC
>  	select CRYPTODEV_API		if OPENSSL_CRYPTODEV && BUILDTIME
>  	prompt "openssl                       "
>  	help

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.

rsc
-- 
Pengutronix e.K.                           | Dipl.-Ing. Robert Schwebel  |
Steuerwalder Str. 21                       | https://www.pengutronix.de/ |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-9    |



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [ptxdist] [PATCH] openssl: add dependency to libatomic
  2023-04-08 13:08 ` Robert Schwebel
@ 2023-04-08 13:20   ` Christian Melki
  2023-04-08 20:30     ` Robert Schwebel
  0 siblings, 1 reply; 7+ messages in thread
From: Christian Melki @ 2023-04-08 13:20 UTC (permalink / raw)
  To: ptxdist

On 4/8/23 15:08, Robert Schwebel wrote:
> On Tue, Apr 04, 2023 at 10:00:26AM +0200, Robert Schwebel wrote:
>> Since openssl 3.x, libcrypto needs libatomic, at least on several 32 bit
>> platforms (and on 64 bit it doesn't harm).
>>
>> Signed-off-by: Robert Schwebel <r.schwebel@pengutronix.de>
>> ---
>>  rules/openssl.in | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/rules/openssl.in b/rules/openssl.in
>> index 629ee3057..a86ca66a2 100644
>> --- a/rules/openssl.in
>> +++ b/rules/openssl.in
>> @@ -4,6 +4,7 @@ menuconfig OPENSSL
>>  	tristate
>>  	select LIBC_DL
>>  	select GCCLIBS_GCC_S
>> +	select GCCLIBS_ATOMIC
>>  	select CRYPTODEV_API		if OPENSSL_CRYPTODEV && BUILDTIME
>>  	prompt "openssl                       "
>>  	help
> 
> 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. I'd be more interested why and where this pops up
than adding a blanket _ATOMIC.
Ie. I agree on the drop. :)

/C

> rsc




^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [ptxdist] [PATCH] openssl: add dependency to libatomic
  2023-04-08 13:20   ` Christian Melki
@ 2023-04-08 20:30     ` Robert Schwebel
  2023-04-08 20:57       ` Christian Melki
  0 siblings, 1 reply; 7+ messages in thread
From: Robert Schwebel @ 2023-04-08 20:30 UTC (permalink / raw)
  To: ptxdist, christian.melki

On Sat, Apr 08, 2023 at 03:20:25PM +0200, Christian Melki wrote:
> On 4/8/23 15:08, Robert Schwebel wrote:
> > On Tue, Apr 04, 2023 at 10:00:26AM +0200, Robert Schwebel wrote:
> >> Since openssl 3.x, libcrypto needs libatomic, at least on several 32 bit
> >> platforms (and on 64 bit it doesn't harm).
> >>
> >> Signed-off-by: Robert Schwebel <r.schwebel@pengutronix.de>
> >> ---
> >>  rules/openssl.in | 1 +
> >>  1 file changed, 1 insertion(+)
> >>
> >> diff --git a/rules/openssl.in b/rules/openssl.in
> >> index 629ee3057..a86ca66a2 100644
> >> --- a/rules/openssl.in
> >> +++ b/rules/openssl.in
> >> @@ -4,6 +4,7 @@ menuconfig OPENSSL
> >>  	tristate
> >>  	select LIBC_DL
> >>  	select GCCLIBS_GCC_S
> >> +	select GCCLIBS_ATOMIC
> >>  	select CRYPTODEV_API		if OPENSSL_CRYPTODEV && BUILDTIME
> >>  	prompt "openssl                       "
> >>  	help
> > 
> > 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 :)

rsc
-- 
Pengutronix e.K.                           | Dipl.-Ing. Robert Schwebel  |
Steuerwalder Str. 21                       | https://www.pengutronix.de/ |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-9    |



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [ptxdist] [PATCH] openssl: add dependency to libatomic
  2023-04-08 20:30     ` Robert Schwebel
@ 2023-04-08 20:57       ` Christian Melki
  2023-04-11  6:24         ` Robert Schwebel
  0 siblings, 1 reply; 7+ messages in thread
From: Christian Melki @ 2023-04-08 20:57 UTC (permalink / raw)
  To: Robert Schwebel; +Cc: ptxdist

On 4/8/23 22:30, Robert Schwebel wrote:
> On Sat, Apr 08, 2023 at 03:20:25PM +0200, Christian Melki wrote:
>> On 4/8/23 15:08, Robert Schwebel wrote:
>>> On Tue, Apr 04, 2023 at 10:00:26AM +0200, Robert Schwebel wrote:
>>>> Since openssl 3.x, libcrypto needs libatomic, at least on several 32 bit
>>>> platforms (and on 64 bit it doesn't harm).
>>>>
>>>> Signed-off-by: Robert Schwebel <r.schwebel@pengutronix.de>
>>>> ---
>>>>  rules/openssl.in | 1 +
>>>>  1 file changed, 1 insertion(+)
>>>>
>>>> diff --git a/rules/openssl.in b/rules/openssl.in
>>>> index 629ee3057..a86ca66a2 100644
>>>> --- a/rules/openssl.in
>>>> +++ b/rules/openssl.in
>>>> @@ -4,6 +4,7 @@ menuconfig OPENSSL
>>>>  	tristate
>>>>  	select LIBC_DL
>>>>  	select GCCLIBS_GCC_S
>>>> +	select GCCLIBS_ATOMIC
>>>>  	select CRYPTODEV_API		if OPENSSL_CRYPTODEV && BUILDTIME
>>>>  	prompt "openssl                       "
>>>>  	help
>>>
>>> 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? What mips are we talking about?
If a sufficiently modern gcc doesn't provide a complete set of
intrinsics for atomics then libatomic is going to be the only choice.

Can you figure out what symbols would be attached to libatomic?
I'm suspecting that if you have an older gcc(?) some intrinsics might
not be available.

Regards,
Christian

> 
> rsc




^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [ptxdist] [PATCH] openssl: add dependency to libatomic
  2023-04-08 20:57       ` Christian Melki
@ 2023-04-11  6:24         ` Robert Schwebel
  2023-04-11  6:47           ` Christian Melki
  0 siblings, 1 reply; 7+ messages in thread
From: Robert Schwebel @ 2023-04-11  6:24 UTC (permalink / raw)
  To: ptxdist, christian.melki

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

> What mips are we talking about?

See above, mips-softfloat-linux-gnu.

> 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"

> 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

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

rsc
-- 
Pengutronix e.K.                           | Dipl.-Ing. Robert Schwebel  |
Steuerwalder Str. 21                       | https://www.pengutronix.de/ |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-9    |



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [ptxdist] [PATCH] openssl: add dependency to libatomic
  2023-04-11  6:24         ` Robert Schwebel
@ 2023-04-11  6:47           ` Christian Melki
  0 siblings, 0 replies; 7+ messages in thread
From: Christian Melki @ 2023-04-11  6:47 UTC (permalink / raw)
  To: Robert Schwebel, ptxdist

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




^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2023-04-11  6:48 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-04-04  8:00 [ptxdist] [PATCH] openssl: add dependency to libatomic Robert Schwebel
2023-04-08 13:08 ` Robert Schwebel
2023-04-08 13:20   ` Christian Melki
2023-04-08 20:30     ` Robert Schwebel
2023-04-08 20:57       ` Christian Melki
2023-04-11  6:24         ` Robert Schwebel
2023-04-11  6:47           ` Christian Melki

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox