| Message ID | 20190206091531.104591-1-aduskett@gmail.com |
|---|---|
| State | Accepted |
| Headers | show |
| Series | [v10,1/6] binutils: install libiberty for host build | expand |
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
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
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
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
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.
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
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) \