Patchwork toolchain: add support for glibc

login
register
mail settings
Submitter Thomas Petazzoni
Date Aug. 18, 2013, 5:36 p.m.
Message ID <1376847393-12397-1-git-send-email-thomas.petazzoni@free-electrons.com>
Download mbox | patch
Permalink /patch/268043/
State Changes Requested
Headers show

Comments

Thomas Petazzoni - Aug. 18, 2013, 5:36 p.m.
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
Arnout Vandecappelle - Aug. 21, 2013, 9:45 p.m.
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
Arnout Vandecappelle - Aug. 21, 2013, 9:52 p.m.
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
Arnout Vandecappelle - Aug. 22, 2013, 7:42 p.m.
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
Thomas Petazzoni - Aug. 22, 2013, 9:26 p.m.
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
Arnout Vandecappelle - Aug. 22, 2013, 11:26 p.m.
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
Thomas Petazzoni - Aug. 23, 2013, 4:48 a.m.
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
Arnout Vandecappelle - Aug. 28, 2013, 8:16 p.m.
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
>
Thomas Petazzoni - Aug. 29, 2013, 7:38 a.m.
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
Arnout Vandecappelle - Aug. 29, 2013, 3:54 p.m.
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
>
Thomas Petazzoni - Aug. 30, 2013, 7:46 a.m.
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

Patch

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"