[Buildroot] [PATCH] libglib2: remove $(DISABLE_NLS) from configure options

[Buildroot] [PATCH] libglib2: remove $(DISABLE_NLS) from configure options

[Markus Heidelberg]

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(-)

diff --git a/package/libglib2/libglib2.mk b/package/libglib2/libglib2.mk
index 1a20666..fa33db0 100644
--- a/package/libglib2/libglib2.mk
+++ b/package/libglib2/libglib2.mk
@@ -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

[Buildroot] [PATCH] libglib2: remove $(DISABLE_NLS) from configure options

[Peter Korsgaard]

>>>>> "Markus" == Markus Heidelberg <markus.heidelberg@web.de> writes:

 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

[Buildroot] [PATCH] libglib2: remove $(DISABLE_NLS) from configure options

[Markus Heidelberg]

Peter Korsgaard, 26.10.2008:
> >>>>> "Markus" == Markus Heidelberg <markus.heidelberg@web.de> writes:
> 
>  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?

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

[Buildroot] [PATCH] libglib2: remove $(DISABLE_NLS) from configure options

[Peter Korsgaard]

>>>>> "Markus" == Markus Heidelberg <markus.heidelberg@web.de> writes:

Hi,

 >> Does this mean that libglib2 should depend on BR2_ENABLE_LOCALE?

 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

[Buildroot] [PATCH] libglib2: remove $(DISABLE_NLS) from configure options

[Thomas Petazzoni]

Le Mon, 27 Oct 2008 10:13:20 +0100,
Peter Korsgaard <jacmet@uclibc.org> a ?crit :

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

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
===================================================================
--- buildroot.orig/package/libglib2/Config.in
+++ 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
===================================================================
--- buildroot.orig/package/libglib2/libglib2.mk
+++ 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

[Buildroot] [PATCH] libglib2: remove $(DISABLE_NLS) from configure options

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

Hi,

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

 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

[Buildroot] Toolchain problems. About toolchains in Buildroot ?

[Thomas Petazzoni]

Le Mon, 27 Oct 2008 10:48:26 +0100,
Peter Korsgaard <jacmet@uclibc.org> a ?crit :

> What problems do you have with the buildroot toolchains?

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