[Buildroot] [PATCH v10 1/6] binutils: install libiberty for host build
Arnout Vandecappelle
arnout at mind.be
Tue Mar 19 21:17:56 UTC 2019
On 19/03/2019 21:48, Yann E. MORIN wrote:
> Arnout, All,
>
> On 2019-03-19 19:08 +0100, Arnout Vandecappelle spake thusly:
>> On 18/03/2019 23:03, Yann E. MORIN wrote:
>>> First, with this very patch: it breaks hiost-gdb, which fails to build
>>> because there is an inconsistency with how ti tries to link with
>>> libiberty:
>>>
>>> http://autobuild.buildroot.org/results/109/1098d6380f12f5bbd6dbc69edb06bd953d1edc3d/build-end.log
>>>
>>> /usr/bin/ld: /home/buildroot/autobuild/instance-0/output/host/lib/libiberty.a(cplus-dem.o):
>>> relocation R_X86_64_PC32 against symbol `_sch_istable' can not be used when making a shared object; recompile with -fPIC
>>> /usr/bin/ld: final link failed: Bad value
>>
>> Maybe this is due to building host-binutils with --disable-shared
>> --enable-static? Maybe the solution is to just add --enable-shared, i.e. build
>> both shared and static?
>>
>> That does mean that ld etc. may now link dynamically with the various
>> libraries, but host tools should now be relocatable thinks to our rpath fixup,
>> so that shouldn't be a problem.
>
> Except wqe can't use binutils when we use an external toolchain, at
> least not in the current state anyway.
I was only replying to the build failure, not to all the other issues you
pointed out. But now you force me into it...
> So we have to find an anleternative.
>
> I was thinking of two solutions:
>
> - change the existing host-binutils package to only install libiberty
> (and maybe a few others?) when using an external toolchain, or
A slightly more verbose but more maintainable variant: introduce
BR2_PACKAGE_HOST_BINUTILS, BR2_PACKAGE_HOST_BINUTILS_FULL and
BR2_PACKAGE_HOST_BINUTILS_LIBIBERTY blind options. Select _FULL from
toolchain-buildroot and _LIBIBERTY from prelink-cross. Adapt the .mk file to do
installation according to these options (similar to the
BR2_PACKAGE_BINUTILS_TARGET option).
>
> - introduce a new virtual package, host-binutils-libs, which package
> would select when they need binutils libs; that virtual package
> would then depend on host-binutils for the internal toolchain, or
> would depend on host-bnutils-libs-for-real-this-time that just
> builds the libs.
Sounds complicated...
Third option: introduce "libiberty" package that downloads a specific version
of binutils-gdb and only builds the libiberty part.
That said, none of the options are really attractive...
> TBH, I'm more inclined to look at the first solution, but it may make
> the package less maintainable over time. The second solution is maybe
> cleaner, but as you can seee, finding good neams is still not trivial.
>
> Finally, maybe we can find a middles ground, with host-binutils-libs a
> real package for external toolchains, and an empty package that just
> depends on binutils for internal toolchains.
I definitely don't like linking it directly to whether it's an external
toolchain or not.
Regards,
Arnout
More information about the buildroot
mailing list