libglib2: remove $(DISABLE_NLS) from configure options

The configure option --disable-nls is not supported anymore in glib since version 2.0, see file ChangeLog.pre-2-0 line 544.

---
 package/libglib2/libglib2.mk |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

index 1a20666..fa33db0 100644
@@ -45,7 +45,7 @@ LIBGLIB2_CONF_ENV =	\
 		gt_cv_c_wchar_t=$(if $(BR2_USE_WCHAR),yes,no)
 
 LIBGLIB2_CONF_OPT = --enable-shared \
-		--enable-static $(DISABLE_NLS)
+		--enable-static
 
 LIBGLIB2_DEPENDENCIES = uclibc gettext libintl pkgconfig
 

1.5.6.4

Markus> The configure option --disable-nls is not supported anymore in glib Markus> since version 2.0, see file ChangeLog.pre-2-0 line 544.

Thanks, committed.

Does this mean that libglib2 should depend on BR2_ENABLE_LOCALE?

Bye, Peter Korsgaard

Peter Korsgaard, 26.10.2008:

I'm not sure. Looking at DISABLE_NLS in Makefile.in, then yes. I've also read a thread, saying that packages using glib don't have to ask for locale support but can just rely on having it. But I have no clue about the relationship between UCLIBC_HAS_LOCALE and --disable/enable-nls.

Markus

Hi,

Markus> I'm not sure. Looking at DISABLE_NLS in Makefile.in, then Markus> yes. I've also read a thread, saying that packages using glib Markus> don't have to ask for locale support but can just rely on Markus> having it. But I have no clue about the relationship between Markus> UCLIBC_HAS_LOCALE and --disable/enable-nls.

Probably it's handled with the libintl stuff when !BR2_ENABLE_LOCALE.

Bye, Peter Korsgaard

Le Mon, 27 Oct 2008 10:13:20 +0100,
Peter Korsgaard <[email protected]> a ?crit :

Concerning libglib2 and iconv, I have the following workaround/patch in my tree to disable pulling libiconv when !BR2_ENABLE_LOCALE. The problem is that I'm using an external toolchain (having too many troubles with buildroot-generated toolchains). Because the toolchain is external, BR2_ENABLE_LOCALE is not set. But the toolchain already contains libiconv, so I don't want to add it as a dependency. But the following patch is just a workaround, I haven't thought about a proper fix for now.

Bogus check if the toolchain is external.

---
 package/libglib2/Config.in   |    1 -
 package/libglib2/libglib2.mk |    4 ----
 2 files changed, 5 deletions(-)

Index: buildroot/package/libglib2/Config.in
===================================================================
@@ -2,7 +2,6 @@
 	bool "libglib2"
 	select BR2_PACKAGE_GETTEXT
 	select BR2_PACKAGE_LIBINTL
-	select BR2_PACKAGE_LIBICONV if !BR2_ENABLE_LOCALE
 	select BR2_PACKAGE_PKGCONFIG
 	help
 	  Low-level core library that forms the basis of GTK+ and GNOME.

Index: buildroot/package/libglib2/libglib2.mk
===================================================================
@@ -49,8 +49,4 @@
 
 LIBGLIB2_DEPENDENCIES = uclibc gettext libintl pkgconfig
 
-ifneq ($(BR2_ENABLE_LOCALE),y)
-LIBGLIB2_DEPENDENCIES+=libiconv
-endif
-
 $(eval $(call AUTOTARGETS,package,libglib2))

Thomas

Thomas Petazzoni, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com

Hi,

Thomas> Concerning libglib2 and iconv, I have the following workaround/patch in Thomas> my tree to disable pulling libiconv when !BR2_ENABLE_LOCALE. The Thomas> problem is that I'm using an external toolchain (having too many Thomas> troubles with buildroot-generated toolchains). Because the toolchain is Thomas> external, BR2_ENABLE_LOCALE is not set. But the toolchain already Thomas> contains libiconv, so I don't want to add it as a dependency. But the Thomas> following patch is just a workaround, I haven't thought about a proper Thomas> fix for now.

Yeah, we should probably figure out a proper way to set those uclibc settings when using an external toolchain.

What problems do you have with the buildroot toolchains?

Bye, Peter Korsgaard

Le Mon, 27 Oct 2008 10:48:26 +0100,
Peter Korsgaard <[email protected]> a ?crit :

Two problems, on ARM (the only architecture I'm using Buildroot for) :

* EABI kernel build failures. The kernel couldn't find some weird eabi function, which is implemented in libgcc, but the kernel is not supposed to be linked with libgcc. It's probably due to incorrect code being generated by the compiler. I can report the exact is required.

* A DirectFB+Gtk build with a sample Hello World application (not using Gtk, but linked against Gtk) crashes on start-up ("Segmentation fault"). Seems that the crash is occuring somewhere in uClibc, but I'm unsure.

Both of these problems go away when I use an external toolchain built with crosstool-ng.

Generally-speaking, it seems that the toolchain in Buildroot are not maintained as much as it would be necessary to keep properly working toolchains. It seems that Bernhard Fischer is doing some work on this front, but on his Git tree, and the changes don't get integrated back into Buildroot SVN (fragmentation is a shame, IMO).

And again, my opinion on this is that Buildroot should probably focus on one thing: building root filesystems. Building toolchains is another job, usually done separatly from building the root filesystem, so having two different projects makes sense. The crosstool-ng guys are doing a pretty good job, keeping their scripts up-to-date with the latest versions of gcc, binutils, uClibc and others, creating stable releases, getting quite some user testing and feedback, etc. They also provide an interesting feature: generate toolchain for glibc, uClibc, and eglibc. So, I'd say that instead of fragmenting the energies it would probably be nice if Buildroot focused on building root filesystems, leaving the work of building the toolchain to crosstool-ng. But that's just my opinion, of course.

Sincerly,

Thomas

Thomas Petazzoni, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com