I'll postpone for a while. I thought that value of "2" is the same as "1", I'll try to find better doc.
seems that I didn''t specify "march" and that might be the cause. сб, 20 апр. 2024 г. в 15:21, Willy Tarreau <w...@1wt.eu>: > On Sat, Apr 20, 2024 at 03:11:19PM +0200, ???? ??????? wrote: > > ??, 20 ???. 2024 ?. ? 15:07, Willy Tarreau <w...@1wt.eu>: > > > > > On Sat, Apr 20, 2024 at 02:49:38PM +0200, ???? ??????? wrote: > > > > ??, 11 ???. 2024 ?. ? 21:05, Willy Tarreau <w...@1wt.eu>: > > > > > > > > > Hi Ilya, > > > > > > > > > > On Thu, Apr 11, 2024 at 08:27:39PM +0200, ???? ??????? wrote: > > > > > > do you know maybe how this was supposed to work ? > > > > > > haproxy/Makefile at master · haproxy/haproxy (github.com) > > > > > > <https://github.com/haproxy/haproxy/blob/master/Makefile#L499> > > > > > > > > > > That's this: > > > > > > > > > > ifneq ($(shell $(CC) $(CFLAGS) -dM -E -xc - </dev/null > 2>/dev/null | > > > > > grep -c 'LOCK_FREE.*1'),0) > > > > > USE_LIBATOMIC = implicit > > > > > endif > > > > > > > > > > It calls the compiler with the known flags and checks if for this > arch, > > > > > it's configured to require libatomic. > > > > > > > > > > > > > macros has changed from 1 to 2: > > > > > > > > ilia@fedora:~/Downloads$ cc -dM -E -xc - </dev/null 2>/dev/null | > grep > > > LOCK > > > > #define __GCC_ATOMIC_CHAR_LOCK_FREE 2 > > > > #define __GCC_ATOMIC_CHAR32_T_LOCK_FREE 2 > > > > #define __GCC_ATOMIC_BOOL_LOCK_FREE 2 > > > > #define __GCC_ATOMIC_POINTER_LOCK_FREE 2 > > > > #define __GCC_ATOMIC_INT_LOCK_FREE 2 > > > > #define __GCC_ATOMIC_WCHAR_T_LOCK_FREE 2 > > > > #define __GCC_ATOMIC_LONG_LOCK_FREE 2 > > > > #define __GCC_ATOMIC_CHAR16_T_LOCK_FREE 2 > > > > #define __GCC_ATOMIC_LLONG_LOCK_FREE 2 > > > > #define __GCC_ATOMIC_SHORT_LOCK_FREE 2 > > > > > > This means it's always lock-free, implemented natively thus doesn't > > > require libatomic. Value 1 means "sometimes lock-free" and implemented > > > as a function provided by libatomic. > > > > > > Did the problem appear when I changed the flags in the makefile ? Maybe > > > I accidently lost one and it's falling back to a subset of the target > > > arch ? > > > > > > > > > the problem appears only with QuicTLS manually built with "-m32" flag. it > > does not appear with "-m32" if built and linked against system OpenSS:L > > > > but after I modify condition (the same as previously enforcing libatomic > in > > ADDLIB), it builds fine. > > OK thanks for that, but was it already present before my changes in the > makefile ? Could you check that the -m32 flag is properly passed to this > test ? > > On 32-bit ix86, there are different cases that require libatomic: > > $ gcc -march=i686 -m32 -dM -E -xc - < /dev/null |grep -c LOCK.*1 > 0 > $ gcc -march=i586 -m32 -dM -E -xc - < /dev/null |grep -c LOCK.*1 > 0 > $ gcc -march=i486 -m32 -dM -E -xc - < /dev/null |grep -c LOCK.*1 > 1 > $ gcc -march=i386 -m32 -dM -E -xc - < /dev/null |grep -c LOCK.*1 > 10 > > Only i386 and i486 require it. That makes me think, maybe it's quictls > that was built against it and adds a dependency to it. You can check > it using objdump -p|grep NEEDED. > > If so that would make sense to just manually add it (or any other > required dependencies) in ADDLIB since they're here just to satisfy > external dependencies. > > Willy >
