Bug 5396

Created attachment 4442 [details]
Proposed fix

I haven't looked in details, but I think the fix will probably have to have some special casing depending on whether the toolchain uses uClibc or (e)glibc. Those C libraries already have iconv support, but maybe the iconv implementation of uClibc isn't capable enough. But in the case of (e)glibc, I don't think the separate libiconv is needed.

So clearly, a proper fix will need investigation and testing for both uClibc and glibc toolchains.

(In reply to comment #2)
> I haven't looked in details, but I think the fix will probably have to have
> some special casing depending on whether the toolchain uses uClibc or (e)glibc.
> Those C libraries already have iconv support, but maybe the iconv
> implementation of uClibc isn't capable enough. But in the case of (e)glibc, I
> don't think the separate libiconv is needed.
> 
> So clearly, a proper fix will need investigation and testing for both uClibc
> and glibc toolchains.

How about we use --with-libiconv= if BR2_TOOLCHAIN_BUILDROOT=y since we know it is not working in that case?

(In reply to comment #3)

> How about we use --with-libiconv= if BR2_TOOLCHAIN_BUILDROOT=y since we know it
> is not working in that case?

Sorry, but this is also a hack: we support uClibc in external toolchains and ct-ng generated toolchains as well.

We have four cases:

 (1) Config without libiconv, uClibc
 (2) Config with libiconv, uClibC
 (3) Config without libiconv, glibc
 (4) Config with libiconv, glibc

We need to find out how to handle each case properly.

Case (4) should be prevented I think, since glibc as an internal implementation of iconv that should just work.

Case (3) should probably be implemented by adding the support to copy of gconv .so files to the target, see http://lists.busybox.net/pipermail/buildroot/2011-September/045333.html. This needs to be tested.

Case (2) needs to be verified. Last time I looked at this topic, uClibc with locale + libiconv was causing lots of build issues, because uClibc was providing its own version of the iconv functions, even if not as capable as the separate libiconv library.

So as you can see, a proper fix will not be a one-liner. It needs to be a correct investigation of how the iconv implementation works in uClibc and glibc, how it relates to the separate libiconv, and finally how to handle that in Buildroot.

I tried reproducing this problem using qemu in two cases:
- external glibc toolchain
- internal uclibc toolchain (locale enabled)

on current git (based on 2014.02, soon to become 2014.05).

In both cases, the system booted correctly (including samba). Manually starting 'smbd -FS' also gives no problems. 

Note that in the case of !BR2_ENABLE_LOCALE, a config option was added in Buildroot:

config BR2_PACKAGE_SAMBA_LIBICONV
        bool "extended encodings (libiconv)"
        depends on !BR2_ENABLE_LOCALE
        select BR2_PACKAGE_LIBICONV
        help
          Include libiconv support for extended conversion of filename
          enconding. Samba has built-in support for UTF-8, ISO-8859-1
          and ASCII, so this is only required if you want to support
          other encodings.

In this case, the .mk file does:
ifeq ($(BR2_PACKAGE_SAMBA_LIBICONV),y)
SAMBA_DEPENDENCIES += libiconv
SAMBA_CONF_OPT += --with-libiconv=$(STAGING_DIR)
else
SAMBA_CONF_OPT += --with-libiconv=""
endif

but this bug report is about the case when locale is enabled.

Jonathan Liu: could you retest this scenario on a recent buildroot version and let us know the result? If you still experience a problem, please share your .config file.

Jonathan: any feedback? Could you retest this bug with the latest buildroot?

Problem not reproducible in current Buildroot and no feedback from submitter, so I'm closing this bug.
Don't hesitate to reopen if the problem persists.