Re: [Buildroot] [PATCH 0/2] Add support for FDPIC binaries on ARM

From: Arnout Vandecappelle <arnout@mind.be>
To: Ben Wolsieffer <ben.wolsieffer@hefring.com>,
	Vladimir Murzin <vladimir.murzin@arm.com>
Cc: "Yann E. MORIN" <yann.morin.1998@free.fr>,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
	buildroot@buildroot.org
Subject: Re: [Buildroot] [PATCH 0/2] Add support for FDPIC binaries on ARM
Date: Sun, 14 Aug 2022 23:55:37 +0200	[thread overview]
Message-ID: <7d0fcbf1-144e-b6d3-7b38-6caa3348703d@mind.be> (raw)
In-Reply-To: <YvV2kelJpRw6erhZ@hefring>

On 11/08/2022 23:37, Ben Wolsieffer wrote:
> On Tue, Aug 09, 2022 at 12:26:14PM +0100, Vladimir Murzin wrote:
>>
>> You might also want to allow uClibc to use NPTL thread library instead
>> of old(-sh) LinuxThreads with something like
>>
>> diff --git a/package/uclibc/Config.in b/package/uclibc/Config.in
>> index ba8b5885ec..30a154531a 100644
>> --- a/package/uclibc/Config.in
>> +++ b/package/uclibc/Config.in
>> @@ -76,7 +76,7 @@ choice
>>   
>>   config BR2_PTHREADS_NATIVE
>>          bool "Native POSIX Threading (NPTL)"
>> -       depends on BR2_USE_MMU
>> +       depends on BR2_USE_MMU || BR2_BINFMT_FDPIC
>>          select BR2_TOOLCHAIN_HAS_THREADS
>>          select BR2_TOOLCHAIN_HAS_THREADS_NPTL
>>   
> 
> You mean I could have just used NPTL and not wasted hours fighting
> LinuxThreads...
> 
> I'm not sure how I missed this before, since I immediately found the
> relevant patches when I searched for them now.
> 
> I've been playing around with NPTL and FDPIC and it doesn't quite work
> perfectly out of the box. Static libraries (linked into a dynamic
> executable) crash when attempting to use TLS. In addition, the reason
> static libraries are even being used is because libtool doesn't recognize
> the target name and therefore thinks it can't build shared libaries.
> 
> There was a patch [1] submitted a few years ago to add the target to
> libtool, but it looks like it was ignored. Unfortunately, we can't just
> apply it in Buildroot, unless we want to run autoreconf on every
> package. I'm working around this locally with a hacky hook to patch
> configure scripts, but I'm not sure it is appropriate to upstream.

  This problem exists for a number of architectures. For that reason, we have a 
workaround: the LIBTOOL_PATCH_HOOK [1]. For any autotools package, we search for 
ltmain.sh files in the source, parse out the libtool version from it, and apply 
the appropriate patch from support/libtool/

  In other words, the solution is to extend the patches in support/libtool/ with 
the missing architecture.

  Regards,
  Arnout

[1] 
https://gitlab.com/buildroot.org/buildroot/-/blob/master/package/pkg-autotools.mk#L60

> 
> Although the situation is not ideal, things basically work with
> LinuxThreads and the libtool issue, so I'd prefer to get this patch set
> finished without expanding the scope.
> 
> Thanks, Ben
> 
> [1] https://lists.gnu.org/archive/html/libtool-patches/2018-05/msg00000.html
> _______________________________________________
> buildroot mailing list
> buildroot@buildroot.org
> https://lists.buildroot.org/mailman/listinfo/buildroot
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot