| Message ID | 1376847393-12397-1-git-send-email-thomas.petazzoni@free-electrons.com |
|---|---|
| State | Changes Requested |
| Headers | show |
On 18/08/13 19:36, Thomas Petazzoni wrote: > The support for eglibc 2.17 was added to the internal toolchain > backend for 2013.08. This commit now adds glibc 2.18 support to the > internal toolchain backend. The building procedure is very similar to > the one of eglibc, with a few differences, but the two are kept > separate for now. I'm not sure if that's a good idea... Will merging them later be easier? [snip] > +define GLIBC_CONFIGURE_CMDS > + mkdir -p $(@D)/build > + # Do the configuration > + (cd $(@D)/build; \ > + $(TARGET_CONFIGURE_OPTS) \ > + CFLAGS="-O2 $(GLIBC_EXTRA_CFLAGS)" CPPFLAGS="" \ The -O2 was required for eglibc. Why do we have it here as well? [snip] > +ifeq ($(BR2_PACKAGE_GDB_SERVER),y) > +GLIBC_LIBS_LIB += libthread_db.so > +endif Shouldn't this lib be installed as well for a gdb without gdbserver? I.e., shouldn't the condition be ifeq ($(BR2_PACKAGE_GDB),y)? [snip] Regards, Arnout
On 18/08/13 19:36, Thomas Petazzoni wrote: > +config BR2_TOOLCHAIN_BUILDROOT_GLIBC > + bool "glibc (experimental)" > + depends on BR2_arm || BR2_armeb || BR2_aarch64 || \ > + BR2_i386 || BR2_mips || BR2_mipsel || \ > + BR2_mips64 || BR2_mips64el || BR2_powerpc || \ > + BR2_sh || BR2_sh64 || BR2_sparc || \ > + BR2_x86_64 I though, let's try this patch with some exotic architecture, and guess what: >>> glibc 2.18 Configuring ... checking sysdep dirs... configure: error: The sh64 is not supported. Continuing with sparc... Regards, Arnout
On 21/08/13 23:52, Arnout Vandecappelle wrote: > On 18/08/13 19:36, Thomas Petazzoni wrote: >> +config BR2_TOOLCHAIN_BUILDROOT_GLIBC >> + bool "glibc (experimental)" >> + depends on BR2_arm || BR2_armeb || BR2_aarch64 || \ >> + BR2_i386 || BR2_mips || BR2_mipsel || \ >> + BR2_mips64 || BR2_mips64el || BR2_powerpc || \ >> + BR2_sh || BR2_sh64 || BR2_sparc || \ >> + BR2_x86_64 > > I though, let's try this patch with some exotic architecture, and guess > what: > > >>> glibc 2.18 Configuring > ... > checking sysdep dirs... configure: error: The sh64 is not supported. > > > Continuing with sparc... sparc wouldn't even build gcc-initial, so I continued with powerpc and that at least worked :-) Given that the two comments I had were minor, you can add my Tested-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Regards, Arnout
Dear Arnout Vandecappelle, On Wed, 21 Aug 2013 23:45:06 +0200, Arnout Vandecappelle wrote: > On 18/08/13 19:36, Thomas Petazzoni wrote: > > The support for eglibc 2.17 was added to the internal toolchain > > backend for 2013.08. This commit now adds glibc 2.18 support to the > > internal toolchain backend. The building procedure is very similar to > > the one of eglibc, with a few differences, but the two are kept > > separate for now. > > I'm not sure if that's a good idea... Will merging them later be easier? I don't know for sure, but the package aren't that complex, so I don't think merging would be very difficult. If I had to merge them, where should I put the common code? > [snip] > > +define GLIBC_CONFIGURE_CMDS > > + mkdir -p $(@D)/build > > + # Do the configuration > > + (cd $(@D)/build; \ > > + $(TARGET_CONFIGURE_OPTS) \ > > + CFLAGS="-O2 $(GLIBC_EXTRA_CFLAGS)" CPPFLAGS="" \ > > The -O2 was required for eglibc. Why do we have it here as well? I believe yes. At least, Crosstool-NG does it, AFAIK. The glibc and eglibc code base are very very similar, so it wouldn't surprise me that the same 'constraint' applies on both. > [snip] > > +ifeq ($(BR2_PACKAGE_GDB_SERVER),y) > > +GLIBC_LIBS_LIB += libthread_db.so > > +endif > > Shouldn't this lib be installed as well for a gdb without gdbserver? > I.e., shouldn't the condition be ifeq ($(BR2_PACKAGE_GDB),y)? That's a good question, I don't know. At the moment, the ct-ng backend, the external backend and the eglibc .mk file all copy libthread_db.so when gdbserver is enabled. Thomas
On 22/08/13 23:26, Thomas Petazzoni wrote: > Dear Arnout Vandecappelle, > > On Wed, 21 Aug 2013 23:45:06 +0200, Arnout Vandecappelle wrote: >> On 18/08/13 19:36, Thomas Petazzoni wrote: >>> The support for eglibc 2.17 was added to the internal toolchain >>> backend for 2013.08. This commit now adds glibc 2.18 support to the >>> internal toolchain backend. The building procedure is very similar to >>> the one of eglibc, with a few differences, but the two are kept >>> separate for now. >> >> I'm not sure if that's a good idea... Will merging them later be easier? > > I don't know for sure, but the package aren't that complex, so I don't > think merging would be very difficult. > > If I had to merge them, where should I put the common code? I was thinking to have just one glibc package, with a choice to select eglibc or glibc. > >> [snip] >>> +define GLIBC_CONFIGURE_CMDS >>> + mkdir -p $(@D)/build >>> + # Do the configuration >>> + (cd $(@D)/build; \ >>> + $(TARGET_CONFIGURE_OPTS) \ >>> + CFLAGS="-O2 $(GLIBC_EXTRA_CFLAGS)" CPPFLAGS="" \ >> >> The -O2 was required for eglibc. Why do we have it here as well? > > I believe yes. At least, Crosstool-NG does it, AFAIK. The glibc and > eglibc code base are very very similar, so it wouldn't surprise me that > the same 'constraint' applies on both. > >> [snip] >>> +ifeq ($(BR2_PACKAGE_GDB_SERVER),y) >>> +GLIBC_LIBS_LIB += libthread_db.so >>> +endif >> >> Shouldn't this lib be installed as well for a gdb without gdbserver? >> I.e., shouldn't the condition be ifeq ($(BR2_PACKAGE_GDB),y)? > > That's a good question, I don't know. At the moment, the ct-ng backend, > the external backend and the eglibc .mk file all copy libthread_db.so > when gdbserver is enabled. To be tested but it'd surprise me if gdb didn't need it. Regards, Arnout
Dear Arnout Vandecappelle, On Fri, 23 Aug 2013 01:26:58 +0200, Arnout Vandecappelle wrote: > > I don't know for sure, but the package aren't that complex, so I don't > > think merging would be very difficult. > > > > If I had to merge them, where should I put the common code? > > I was thinking to have just one glibc package, with a choice to select > eglibc or glibc. Well, I still would like the libc selection to be uClibc/glibc/eglibc in the choice in toolchain/toolchain-buildroot/Config.in. But I guess I can probably make BR2_TOOLCHAIN_BUILDROOT_LIBC be equal to "glibc" in both the glibc and eglibc case, which would be sufficient to make the toolchain building logic use the "glibc" and "glibc-configure" targets for both the eglibc and glibc selections. Want me to rework the patch in this direction? Note that later on, if we support several versions of glibc and eglibc, then package/glibc/Config.in would look like: if BR2_TOOLCHAIN_BUILDROOT_EGLIBC ... versions of eglibc ... endif if BR2_TOOLCHAIN_BUILDROOT_GLIBC ... versions of glibc ... endif > >> Shouldn't this lib be installed as well for a gdb without gdbserver? > >> I.e., shouldn't the condition be ifeq ($(BR2_PACKAGE_GDB),y)? > > > > That's a good question, I don't know. At the moment, the ct-ng backend, > > the external backend and the eglibc .mk file all copy libthread_db.so > > when gdbserver is enabled. > > To be tested but it'd surprise me if gdb didn't need it. I agree, it would have to be tested. Thanks for your feedback, Thomas
Hi Thomas, While testing your patch again, I discovered that "make source" doesn't fetch the glibc source (same for eglibc) because BR2_PACKAGE_EGLIBC is not y. This would be nice to fix still in 2013.08. On 08/23/13 06:48, Thomas Petazzoni wrote: > Dear Arnout Vandecappelle, > > On Fri, 23 Aug 2013 01:26:58 +0200, Arnout Vandecappelle wrote: > >>> I don't know for sure, but the package aren't that complex, so I don't >>> think merging would be very difficult. >>> >>> If I had to merge them, where should I put the common code? >> >> I was thinking to have just one glibc package, with a choice to select >> eglibc or glibc. > > Well, I still would like the libc selection to be uClibc/glibc/eglibc > in the choice in toolchain/toolchain-buildroot/Config.in. Good point. > But I guess I > can probably make BR2_TOOLCHAIN_BUILDROOT_LIBC be equal to "glibc" in > both the glibc and eglibc case, which would be sufficient to make the > toolchain building logic use the "glibc" and "glibc-configure" targets > for both the eglibc and glibc selections. You could also choose to keep eglibc.mk and make glibc the derivative. Or would that be strange? > > Want me to rework the patch in this direction? Would be nice, but as you say, merging later wouldn't be so difficult. Except of course that by that time they may have diverged more. > Note that later on, if we support several versions of glibc and eglibc, > then package/glibc/Config.in would look like: > > if BR2_TOOLCHAIN_BUILDROOT_EGLIBC > > ... versions of eglibc ... > > endif > > if BR2_TOOLCHAIN_BUILDROOT_GLIBC > > ... versions of glibc ... > > endif Nothing wrong with that, right? Regards, Arnout >>>> Shouldn't this lib be installed as well for a gdb without gdbserver? >>>> I.e., shouldn't the condition be ifeq ($(BR2_PACKAGE_GDB),y)? >>> >>> That's a good question, I don't know. At the moment, the ct-ng backend, >>> the external backend and the eglibc .mk file all copy libthread_db.so >>> when gdbserver is enabled. >> >> To be tested but it'd surprise me if gdb didn't need it. > > I agree, it would have to be tested. > > Thanks for your feedback, > > Thomas >
Dear Arnout Vandecappelle, On Wed, 28 Aug 2013 22:16:55 +0200, Arnout Vandecappelle wrote: > While testing your patch again, I discovered that "make source" doesn't > fetch the glibc source (same for eglibc) because BR2_PACKAGE_EGLIBC is > not y. This would be nice to fix still in 2013.08. Generally, 'make source' is unfortunately a bit broken with the new internal toolchain backend based on packages. One of the reason is that the 'make source' thing only works for one recursion level of dependencies on host packages. I've started working on fixing that, but it was more complex than I thought (or alternatively I was too stupid to see that there was a simple solution). > > But I guess I > > can probably make BR2_TOOLCHAIN_BUILDROOT_LIBC be equal to "glibc" in > > both the glibc and eglibc case, which would be sufficient to make the > > toolchain building logic use the "glibc" and "glibc-configure" targets > > for both the eglibc and glibc selections. > > You could also choose to keep eglibc.mk and make glibc the derivative. > Or would that be strange? Have you seen my new patch set: Subject: [Buildroot] [PATCH 00/12] Toolchain updates Date: Wed, 28 Aug 2013 08:35:19 +0200 It already incorporates a single 'glibc' package that handles both glibc and eglibc, as per your suggestion. See PATCH 07/12 of this series. I renamed the package to 'glibc' because with the new activity in glibc, it is expected that eglibc will more or less disappear in the coming months/years. People are talking on how to merge back into glibc the changes that were kept separate in eglibc, etc. > > Want me to rework the patch in this direction? > > Would be nice, but as you say, merging later wouldn't be so difficult. > Except of course that by that time they may have diverged more. It's already done, see above. > > Note that later on, if we support several versions of glibc and eglibc, > > then package/glibc/Config.in would look like: > > > > if BR2_TOOLCHAIN_BUILDROOT_EGLIBC > > > > ... versions of eglibc ... > > > > endif > > > > if BR2_TOOLCHAIN_BUILDROOT_GLIBC > > > > ... versions of glibc ... > > > > endif > > Nothing wrong with that, right? No, nothing wrong at all :) Thanks! Thomas
On 08/29/13 09:38, Thomas Petazzoni wrote: > Dear Arnout Vandecappelle, > > On Wed, 28 Aug 2013 22:16:55 +0200, Arnout Vandecappelle wrote: > >> While testing your patch again, I discovered that "make source" doesn't >> fetch the glibc source (same for eglibc) because BR2_PACKAGE_EGLIBC is >> not y. This would be nice to fix still in 2013.08. > > Generally, 'make source' is unfortunately a bit broken with the new > internal toolchain backend based on packages. One of the reason is that > the 'make source' thing only works for one recursion level of > dependencies on host packages. I've started working on fixing that, but > it was more complex than I thought (or alternatively I was too stupid > to see that there was a simple solution). Probably requires an pkg-generic change, like: $(2)-all-source: $(2)-source $(suffix -source,$($(2)_DEPENDENCIES)) >>> But I guess I >>> can probably make BR2_TOOLCHAIN_BUILDROOT_LIBC be equal to "glibc" in >>> both the glibc and eglibc case, which would be sufficient to make the >>> toolchain building logic use the "glibc" and "glibc-configure" targets >>> for both the eglibc and glibc selections. >> >> You could also choose to keep eglibc.mk and make glibc the derivative. >> Or would that be strange? > > Have you seen my new patch set: Sorry, I thought I had checked before sending but obviously my search wasn't good enough. > > Subject: [Buildroot] [PATCH 00/12] Toolchain updates > Date: Wed, 28 Aug 2013 08:35:19 +0200 > > It already incorporates a single 'glibc' package that handles both > glibc and eglibc, as per your suggestion. See PATCH 07/12 of this > series. > > I renamed the package to 'glibc' because with the new activity in > glibc, it is expected that eglibc will more or less disappear in the > coming months/years. People are talking on how to merge back into glibc > the changes that were kept separate in eglibc, etc. Oh, I didn't know that. Regards, Arnout > >>> Want me to rework the patch in this direction? >> >> Would be nice, but as you say, merging later wouldn't be so difficult. >> Except of course that by that time they may have diverged more. > > It's already done, see above. > >>> Note that later on, if we support several versions of glibc and eglibc, >>> then package/glibc/Config.in would look like: >>> >>> if BR2_TOOLCHAIN_BUILDROOT_EGLIBC >>> >>> ... versions of eglibc ... >>> >>> endif >>> >>> if BR2_TOOLCHAIN_BUILDROOT_GLIBC >>> >>> ... versions of glibc ... >>> >>> endif >> >> Nothing wrong with that, right? > > No, nothing wrong at all :) > > Thanks! > > Thomas >
Dear Arnout Vandecappelle, On Thu, 29 Aug 2013 17:54:04 +0200, Arnout Vandecappelle wrote: > > Generally, 'make source' is unfortunately a bit broken with the new > > internal toolchain backend based on packages. One of the reason is that > > the 'make source' thing only works for one recursion level of > > dependencies on host packages. I've started working on fixing that, but > > it was more complex than I thought (or alternatively I was too stupid > > to see that there was a simple solution). > > Probably requires an pkg-generic change, like: > > $(2)-all-source: $(2)-source $(suffix -source,$($(2)_DEPENDENCIES)) Hum, right. I'll try to find some time to investigate that. > >>> But I guess I > >>> can probably make BR2_TOOLCHAIN_BUILDROOT_LIBC be equal to "glibc" in > >>> both the glibc and eglibc case, which would be sufficient to make the > >>> toolchain building logic use the "glibc" and "glibc-configure" targets > >>> for both the eglibc and glibc selections. > >> > >> You could also choose to keep eglibc.mk and make glibc the derivative. > >> Or would that be strange? > > > > Have you seen my new patch set: > > Sorry, I thought I had checked before sending but obviously my search > wasn't good enough. No problem. I guess you'll continue the review over here :) Thanks! Thomas
diff --git a/package/gcc/Config.in.host b/package/gcc/Config.in.host index a6acaa2..0b04b90 100644 --- a/package/gcc/Config.in.host +++ b/package/gcc/Config.in.host @@ -119,7 +119,7 @@ config BR2_INSTALL_FORTRAN config BR2_GCC_ENABLE_TLS bool "Enable compiler tls support" if BR2_TOOLCHAIN_BUILDROOT_UCLIBC default y - depends on BR2_PTHREADS_NATIVE || BR2_TOOLCHAIN_BUILDROOT_EGLIBC + depends on BR2_PTHREADS_NATIVE || BR2_TOOLCHAIN_BUILDROOT_EGLIBC || BR2_TOOLCHAIN_BUILDROOT_GLIBC help Enable the compiler to generate code for accessing thread local storage variables diff --git a/package/glibc/glibc.mk b/package/glibc/glibc.mk new file mode 100644 index 0000000..11fa985 --- /dev/null +++ b/package/glibc/glibc.mk @@ -0,0 +1,105 @@ +################################################################################ +# +# glibc +# +################################################################################ + +GLIBC_VERSION = 2.18 +GLIBC_SITE = $(BR2_GNU_MIRROR)/libc +GLIBC_SOURCE = glibc-$(GLIBC_VERSION).tar.xz +GLIBC_LICENSE = GPLv2+ (programs), LGPLv2.1+, BSD-3c, MIT (library) +GLIBC_LICENSE_FILES = COPYING COPYING.LIB LICENSES + +# Before glibc is configured, we must have the first stage +# cross-compiler and the kernel headers +GLIBC_DEPENDENCIES = host-gcc-initial linux-headers + +# Before glibc is built, we must have the second stage cross-compiler +glibc-build: host-gcc-intermediate + +GLIBC_SUBDIR = build + +GLIBC_INSTALL_STAGING = YES + +GLIBC_INSTALL_STAGING_OPT = install_root=$(STAGING_DIR) install + +# Thumb build is broken, build in ARM mode +ifeq ($(BR2_ARM_INSTRUCTIONS_THUMB),y) +GLIBC_EXTRA_CFLAGS += -marm +endif + +# Even though we use the autotools-package infrastructure, we have to +# override the default configure commands for several reasons: +# +# 1. We have to build out-of-tree, but we can't use the same +# 'symbolic link to configure' used with the gcc packages. +# +# 2. We have to execute the configure script with bash and not sh. +# +define GLIBC_CONFIGURE_CMDS + mkdir -p $(@D)/build + # Do the configuration + (cd $(@D)/build; \ + $(TARGET_CONFIGURE_OPTS) \ + CFLAGS="-O2 $(GLIBC_EXTRA_CFLAGS)" CPPFLAGS="" \ + CXXFLAGS="-O2 $(GLIBC_EXTRA_CFLAGS)" \ + $(SHELL) $(@D)/configure \ + ac_cv_path_BASH_SHELL=/bin/bash \ + libc_cv_forced_unwind=yes \ + --target=$(GNU_TARGET_NAME) \ + --host=$(GNU_TARGET_NAME) \ + --build=$(GNU_HOST_NAME) \ + --prefix=/usr \ + --enable-shared \ + $(if $(BR2_SOFT_FLOAT),--without-fp,--with-fp) \ + --with-pkgversion="Buildroot" \ + --without-cvs \ + --disable-profile \ + --without-gd \ + --enable-obsolete-rpc \ + --with-headers=$(STAGING_DIR)/usr/include) + # Install headers and start files + $(TARGET_MAKE_ENV) $(MAKE) -C $(@D)/build \ + install_root=$(STAGING_DIR) \ + install-bootstrap-headers=yes \ + install-headers + $(TARGET_MAKE_ENV) $(MAKE) -C $(@D)/build csu/subdir_lib + cp $(@D)/build/csu/crt1.o $(STAGING_DIR)/usr/lib/ + cp $(@D)/build/csu/crti.o $(STAGING_DIR)/usr/lib/ + cp $(@D)/build/csu/crtn.o $(STAGING_DIR)/usr/lib/ + $(TARGET_CROSS)gcc -nostdlib \ + -nostartfiles -shared -x c /dev/null -o $(STAGING_DIR)/usr/lib/libc.so + # stubs.h isn't installed by install-headers, so do it by + # hand. We can tolerate an empty stubs.h for the moment. See + # e.g. http://gcc.gnu.org/ml/gcc/2002-01/msg00900.html + touch $(STAGING_DIR)/usr/include/gnu/stubs.h +endef + +# +# We also override the install to target commands since we only want +# to install the libraries, and nothing more. +# + +GLIBC_LIBS_LIB = \ + ld*.so libc.so libcrypt.so libdl.so libgcc_s.so libm.so \ + libnsl.so libpthread.so libresolv.so librt.so libutil.so \ + libnss_files.so libnss_dns.so + +ifeq ($(BR2_PACKAGE_GDB_SERVER),y) +GLIBC_LIBS_LIB += libthread_db.so +endif + +ifeq ($(BR2_INSTALL_LIBSTDCPP),y) +GLIBC_LIBS_USR_LIB += libstdc++.so +endif + +define GLIBC_INSTALL_TARGET_CMDS + for libs in $(GLIBC_LIBS_LIB); do \ + $(call copy_toolchain_lib_root,$(STAGING_DIR)/,,lib,$$libs,/lib) ; \ + done + for libs in $(GLIBC_LIBS_USR_LIB); do \ + $(call copy_toolchain_lib_root,$(STAGING_DIR)/,,lib,$$libs,/usr/lib) ; \ + done +endef + +$(eval $(autotools-package)) diff --git a/toolchain/toolchain-buildroot/Config.in b/toolchain/toolchain-buildroot/Config.in index 396a434..02efdbf 100644 --- a/toolchain/toolchain-buildroot/Config.in +++ b/toolchain/toolchain-buildroot/Config.in @@ -34,12 +34,32 @@ config BR2_TOOLCHAIN_BUILDROOT_EGLIBC http://eglibc.org +config BR2_TOOLCHAIN_BUILDROOT_GLIBC + bool "glibc (experimental)" + depends on BR2_arm || BR2_armeb || BR2_aarch64 || \ + BR2_i386 || BR2_mips || BR2_mipsel || \ + BR2_mips64 || BR2_mips64el || BR2_powerpc || \ + BR2_sh || BR2_sh64 || BR2_sparc || \ + BR2_x86_64 + select BR2_TOOLCHAIN_USES_GLIBC + # our glibc.mk enables RPC support + select BR2_TOOLCHAIN_HAS_NATIVE_RPC + help + This option selects glibc as the C library for the + cross-compilation toolchain. + + The glibc support in the Buildroot toolchain backend is + very recent, and therefore marked experimental. + + http://www.gnu.org/software/libc/ + endchoice config BR2_TOOLCHAIN_BUILDROOT_LIBC string default "uclibc" if BR2_TOOLCHAIN_BUILDROOT_UCLIBC default "eglibc" if BR2_TOOLCHAIN_BUILDROOT_EGLIBC + default "glibc" if BR2_TOOLCHAIN_BUILDROOT_GLIBC source "package/uclibc/Config.in"
The support for eglibc 2.17 was added to the internal toolchain backend for 2013.08. This commit now adds glibc 2.18 support to the internal toolchain backend. The building procedure is very similar to the one of eglibc, with a few differences, but the two are kept separate for now. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> --- package/gcc/Config.in.host | 2 +- package/glibc/glibc.mk | 105 ++++++++++++++++++++++++++++++++ toolchain/toolchain-buildroot/Config.in | 20 ++++++ 3 files changed, 126 insertions(+), 1 deletion(-) create mode 100644 package/glibc/glibc.mk