It is not cross-built. Debian builds armhf from arm64 builders. It seems
Ubuntu is also using arm64 hardware to build armhf.
An alternative that could work is to use QEMU user emulation. You can
directly use "qemu-debootstrap --arch=armhf" to get a working chroot.
--
Format a program to help the reader understand it.
- The Elements of Programming Style (Kernighan & Plauger)
――――――― Original Message ―――――――
From: Илья Шипицин <[email protected]>
Sent: 9 septembre 2020 20:38 +05
Subject: Re: Haproxy 2.2.3 source
To: Willy Tarreau
Cc: Vincent Bernat; Alex Evonosky; [email protected]
> how do you build armh ? can you share details ?
> if that's cross build, we can easily add to github actions, for example.
>
> unfortunately, it is hard to get armh native CI.
>
> ср, 9 сент. 2020 г. в 20:01, Willy Tarreau <[email protected]>:
>
>> On Tue, Sep 08, 2020 at 11:47:25PM +0200, Vincent Bernat wrote:
>> > ? 8 septembre 2020 16:13 -04, Alex Evonosky:
>> >
>> > > Just compiling 2.2.3 and getting this reference:
>> > >
>> > >
>> > > /haproxy-2.2.3/src/thread.c:212: undefined reference to
>> > > `_Unwind_Find_FDE'
>> >
>> > I am getting the same issue on armhf only. Other platforms don't get
>> > this issue. On this platform, we only get:
>> >
>> > 00000000 w DF *UND* 00000000 GLIBC_2.4 __gnu_Unwind_Find_exidx
>> > 000165d0 g DF .text 0000000c GCC_3.0 _Unwind_DeleteException
>> > 0000d1f6 g DF .text 00000002 GCC_3.0 _Unwind_GetTextRelBase
>> > 00016e1c g DF .text 00000022 GCC_4.3.0 _Unwind_Backtrace
>> > 00016df8 g DF .text 00000022 GCC_3.0 _Unwind_ForcedUnwind
>> > 00016dd4 g DF .text 00000022 GCC_3.3 _Unwind_Resume_or_Rethrow
>> > 0000d1f0 g DF .text 00000006 GCC_3.0 _Unwind_GetDataRelBase
>> > 0001662c g DF .text 00000036 GCC_3.5 _Unwind_VRS_Set
>> > 00016db0 g DF .text 00000022 GCC_3.0 _Unwind_Resume
>> > 000169d8 g DF .text 000002ba GCC_3.5 _Unwind_VRS_Pop
>> > 00017178 g DF .text 0000000a GCC_3.0 _Unwind_GetRegionStart
>> > 000165cc g DF .text 00000002 GCC_3.5 _Unwind_Complete
>> > 00017184 g DF .text 00000012 GCC_3.0
>> _Unwind_GetLanguageSpecificData
>> > 000165dc g DF .text 00000036 GCC_3.5 _Unwind_VRS_Get
>> > 000164f0 g DF .text 00000004 GCC_3.3 _Unwind_GetCFA
>> > 00016d8c g DF .text 00000022 GCC_3.0 _Unwind_RaiseException
>> >
>> > So, older symbols are:
>> >
>> > 000165d0 g DF .text 0000000c GCC_3.0 _Unwind_DeleteException
>> > 0000d1f6 g DF .text 00000002 GCC_3.0 _Unwind_GetTextRelBase
>> > 00016df8 g DF .text 00000022 GCC_3.0 _Unwind_ForcedUnwind
>> > 0000d1f0 g DF .text 00000006 GCC_3.0 _Unwind_GetDataRelBase
>> > 00016db0 g DF .text 00000022 GCC_3.0 _Unwind_Resume
>> > 00017178 g DF .text 0000000a GCC_3.0 _Unwind_GetRegionStart
>> > 00017184 g DF .text 00000012 GCC_3.0
>> _Unwind_GetLanguageSpecificData
>> > 00016d8c g DF .text 00000022 GCC_3.0 _Unwind_RaiseException
>> >
>> > Moreover, comment says _Unwind_Find_DFE doesn't take arguments, but the
>> > signature I have in glibc is:
>> >
>> > fde *
>> > _Unwind_Find_FDE (void *pc, struct dwarf_eh_bases *bases)
>>
>> Ah I'm really angry because I tested on many platforms, *including* armhf,
>> but now I'm not seeing it, so either I failed on one test or it depends
>> on the compiler combination :-(
>>
>> The principle was just to force to load libgcc_s that tends to cause
>> aborts on reload for some users in chroots when threads exit, because
>> pthread_exit() tends to be the first one to require libgcc_s and it's
>> quite too late.
>>
>> In the mean time you can probably get away with this:
>>
>> diff --git a/src/thread.c b/src/thread.c
>> index 5eb68e33a..167e26e9d 100644
>> --- a/src/thread.c
>> +++ b/src/thread.c
>> @@ -201,7 +201,7 @@ static void __thread_init(void)
>> exit(1);
>> }
>>
>> -#if defined(__GNUC__) && (__GNUC__ >= 3) && defined(__GNU_LIBRARY__) &&
>> !defined(__clang__)
>> +#if defined(__GNUC__) && (__GNUC__ >= 3) && defined(__GNU_LIBRARY__) &&
>> !defined(__clang__) && !defined(__arm__)
>> /* make sure libgcc_s is already loaded, because pthread_exit() may
>> * may need it on exit after the chroot! _Unwind_Find_FDE() is
>> defined
>> * there since gcc 3.0, has no side effect, doesn't take any
>> argument
>>
>>
>> But I'd really like to find a *reliable* way to force libgcc_s to be loaded
>> if available and required (i.e. not if statically built). I thought about
>> causing a 64/64 bit divide that usually is done via divsi3 and friend but
>> on x86_64 (where the problem was encountered) it will not do it.
>>
>> I'm thinking about something: maybe I can have a look around
>> pthread_getspecific() and pthread_key_create(). I would be very surprised
>> if they didn't rely on some compiler-specific help from libgcc_s.
>>
>> I'll keep testing and will get back to you guys.
>>
>> Willy
>>
>>
