|
Description |
package/libglib2/libglib2.mk and package/libglib2/Config.in both test BR2_ENABLE_LOCALE to know whether libiconv shoud be compiled (when BR2_ENABLE_LOCALE is not set, the toolchain doesn't have support for locales, so an external iconv library is needed, while when BR2_ENABLE_LOCALE is set, we can use the internal iconv implementation of the C library).
The problem is that these checks are completely bogus when using an external toolchain, which is a common use case with Buildroot. BR2_ENABLE_LOCALE is not set, but the toolchain might have iconv support. So, because of libglib2's dependency, Buildroot compiles GNU libiconv and installs it to the staging_dir. The configure script of libglib then detects that an internal iconv implementation is available and decides to use. But the compilation of libglib2 fails later due to the following test in glib/gconvert.c:
#if !defined(USE_LIBICONV_GNU) && defined (_LIBICONV_H)
#error GNU libiconv not in use but included iconv.h is from libiconv
#endif
USE_LIBICONV_GNU is not defined because the ./configure script has found that the internal implementation of iconv by the C library was present. _LIBICONV_H is defined because GNU libiconv has been installed in the staging_dir, including its header file.
I don't know how such a problem should be handled. What's the Buildroot policy for that kind of internal vs. external toolchain configuration issues ? |
Relationships 
