[v10,1/6] binutils: install libiberty for host build
diff mbox series

Message ID 20190206091531.104591-1-aduskett@gmail.com
State Accepted
Headers show
Series
  • [v10,1/6] binutils: install libiberty for host build
Related show

Commit Message

Adam Duskett Feb. 6, 2019, 9:15 a.m. UTC
From: Adam Duskett <Aduskett@gmail.com>

Add --enable-install-libiberty to HOST_BINUTILS_CONF_OPTS to allow
prelink-cross to build properly.

Signed-off-by: Adam Duskett <Aduskett@gmail.com>
---
Changes v1 -> v7:
  - Add patch to series.

Changes v7 -> v10:
  - None

 package/binutils/binutils.mk | 1 +
 1 file changed, 1 insertion(+)

Comments

Thomas Petazzoni March 17, 2019, 9:42 a.m. UTC | #1
On Wed,  6 Feb 2019 04:15:26 -0500
aduskett@gmail.com wrote:

> From: Adam Duskett <Aduskett@gmail.com>
> 
> Add --enable-install-libiberty to HOST_BINUTILS_CONF_OPTS to allow
> prelink-cross to build properly.
> 
> Signed-off-by: Adam Duskett <Aduskett@gmail.com>
> ---
> Changes v1 -> v7:
>   - Add patch to series.

Applied to master, thanks.

Thomas
James Hilliard March 18, 2019, 4:50 a.m. UTC | #2
On Wed, Feb 6, 2019 at 2:15 AM <aduskett@gmail.com> wrote:
>
> From: Adam Duskett <Aduskett@gmail.com>
>
> Add --enable-install-libiberty to HOST_BINUTILS_CONF_OPTS to allow
> prelink-cross to build properly.
>
> Signed-off-by: Adam Duskett <Aduskett@gmail.com>
> ---
> Changes v1 -> v7:
>   - Add patch to series.
>
> Changes v7 -> v10:
>   - None
>
>  package/binutils/binutils.mk | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/package/binutils/binutils.mk b/package/binutils/binutils.mk
> index 4531b8d9c8..388e2192b4 100644
> --- a/package/binutils/binutils.mk
> +++ b/package/binutils/binutils.mk
> @@ -84,6 +84,7 @@ HOST_BINUTILS_CONF_OPTS = \
>         --target=$(GNU_TARGET_NAME) \
>         --disable-shared \
>         --enable-static \
> +       --enable-install-libiberty \
This appears to break host-gdb due to this incompatible non-pic
libiberty.a being in the library search path before the correct pic
version:
 -L/home/buildroot/buildroot/output/host/lib
-L/home/buildroot/buildroot/output/build/host-gdb-8.2.1/bfd/../libiberty/pic

build error for host-gdb:
/usr/bin/ld: /home/buildroot/buildroot/output/host/lib/libiberty.a(cp-demangle.o):
relocation R_X86_64_PC32 against symbol `cplus_demangle_builtin_types'
can not be used when making a shared object; recompile with -fPIC

Deleting the incompatible
/home/buildroot/buildroot/output/host/lib/libiberty.a allows host-gdb
to build successfully.
>         --with-sysroot=$(STAGING_DIR) \
>         --enable-poison-system-directories \
>         $(BINUTILS_DISABLE_GDB_CONF_OPTS) \
> --
> 2.20.1
>
> _______________________________________________
> buildroot mailing list
> buildroot@busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
Yann E. MORIN March 18, 2019, 10:03 p.m. UTC | #3
Adam, All,

On 2019-02-06 04:15 -0500, aduskett@gmail.com spake thusly:
> From: Adam Duskett <Aduskett@gmail.com>
> 
> Add --enable-install-libiberty to HOST_BINUTILS_CONF_OPTS to allow
> prelink-cross to build properly.
> 
> Signed-off-by: Adam Duskett <Aduskett@gmail.com>

So we've had to revert this and the prelink-cross patches, because there
are problems we did not forsee.

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

To be noted, however, is that the target gdb does build nicely, even
though we do build the target binutils with libiberty too.

In any case, this is a regeression that must be addressed.

Second, and more problematic: prelink-crosss depends on host-binutils,
but host-binutils is not supposed to be built when using an external
toolchain, otherwise our host-binutls' built ar, ld, etc... would
collide and conflict with those of the toolchain.

Therefore, we must find a better solution to get that libiberty.

Third, about the qemu version check removal, Thomas and I believe this
should be replaced by a 'comment' in the Kconfig, like:

    if BR2_PACKAGE_HOST_QEMU_LINUX_USER_MODE
    comment "WARNING! If the kernel headers of your toolchain are"
    comment "more recent than the kernel on your build machine,"
    comment "qemu-user may work unreliably. or even not at all."
    endif

Fourth, the FOO_GIR_EXTRA_LIBS_PATH is useless: packages can set it in
their FOO_MAKE_ENV (and possibly, FOO_CONF_ENV) instead, as those
variables *are* made for packages to pass extra environment variables.

Fifth, the gst1-plugins-base patch touches a Makefile.am so it should
require an autoreconf. However, it does not autoreconf nicely, and
requires macros from external packages, which is a pain to add. So
we could accept a patch that also touches Makefile.in as well.
Otherwise, on some systems, the build would try to run automake, and
would fail.

So yes, it took that long to eventually have a look, but here we are.

The qemu version check removal and the GIR_EXTRA_LIBS_PATH ar pretty
trivial. The gst1-plugins-base patch can be easily fixed.

The libiberty and gdb issue is probably not entirely trivial, but at
least he target gdb is in the same situation but builds.

The biggest problem is to get libiberty from host-binutils when using an
external toolchain.

Regards,
Yann E. MORIN.

> ---
> Changes v1 -> v7:
>   - Add patch to series.
> 
> Changes v7 -> v10:
>   - None
> 
>  package/binutils/binutils.mk | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/package/binutils/binutils.mk b/package/binutils/binutils.mk
> index 4531b8d9c8..388e2192b4 100644
> --- a/package/binutils/binutils.mk
> +++ b/package/binutils/binutils.mk
> @@ -84,6 +84,7 @@ HOST_BINUTILS_CONF_OPTS = \
>  	--target=$(GNU_TARGET_NAME) \
>  	--disable-shared \
>  	--enable-static \
> +	--enable-install-libiberty \
>  	--with-sysroot=$(STAGING_DIR) \
>  	--enable-poison-system-directories \
>  	$(BINUTILS_DISABLE_GDB_CONF_OPTS) \
> -- 
> 2.20.1
> 
> _______________________________________________
> buildroot mailing list
> buildroot@busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
Arnout Vandecappelle March 19, 2019, 6:08 p.m. UTC | #4
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.

 Regards,
 Arnout
Yann E. MORIN March 19, 2019, 8:48 p.m. UTC | #5
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.

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

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

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.

Regards,
Yann E. MORIN.
Arnout Vandecappelle March 19, 2019, 9:17 p.m. UTC | #6
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

Patch
diff mbox series

diff --git a/package/binutils/binutils.mk b/package/binutils/binutils.mk
index 4531b8d9c8..388e2192b4 100644
--- a/package/binutils/binutils.mk
+++ b/package/binutils/binutils.mk
@@ -84,6 +84,7 @@  HOST_BINUTILS_CONF_OPTS = \
 	--target=$(GNU_TARGET_NAME) \
 	--disable-shared \
 	--enable-static \
+	--enable-install-libiberty \
 	--with-sysroot=$(STAGING_DIR) \
 	--enable-poison-system-directories \
 	$(BINUTILS_DISABLE_GDB_CONF_OPTS) \