New: Boot hangs when starting samba if BR2_ENABLE_LOCALE is enabled

https://bugs.busybox.net/show_bug.cgi?id=5396

Summary: Boot hangs when starting samba if BR2_ENABLE_LOCALE is
enabled
Product: buildroot
Version: 2012.02
Platform: PC
OS/Version: Windows
Status: NEW
Severity: major
Priority: P5
Component: Other
AssignedTo: unassigned at buildroot.uclibc.org
ReportedBy: net147 at gmail.com
CC: buildroot at uclibc.org
Estimated Hours: 0.0

Booting hangs when starting samba if BR2_ENABLE_LOCALE is enabled. Disabling the samba startup script and running smbd -FS shows the following endless scrolling messages:

init_iconv: Attempting to replace with conversion from UTF-16LE to ASCII
init_iconv: Conversion from UTF-8 to CP850 not supported
init_iconv: Attempting to replace with conversion from ASCII to ASCII
init_iconv: Conversion from ASCII to CP850 not supported
init_iconv: Attempting to replace with conversion from ASCII to ASCII
init_iconv: Conversion from CP850 to UTF-16LE not supported
init_iconv: Attempting to replace with conversion from ASCII to UTF-16LE
init_iconv: Conversion from CP850 to UTF-8 not supported
init_iconv: Attempting to replace with conversion from ASCII to ASCII
init_iconv: Conversion from CP850 to ASCII not supported
init_iconv: Attempting to replace with conversion from ASCII to ASCII
init_iconv: Conversion from CP850 to UTF8 not supported
init_iconv: Attempting to replace with conversion from ASCII to ASCII
init_iconv: Conversion from CP850 to UTF-16BE not supported
init_iconv: Attempting to replace with conversion from ASCII to UTF-16BE

The samba configure script enables native iconv support by default when cross compiling. To resolve this, we pass --with-libiconv= to configure when the libiconv package is not enabled to disable iconv support.

Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

https://bugs.busybox.net/show_bug.cgi?id=5396

--- Comment #1 from Jonathan Liu <[email protected]> 2012-07-24 11:12:25 UTC --- Created attachment 4442
--> https://bugs.busybox.net/attachment.cgi?id=4442
Proposed fix

Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

https://bugs.busybox.net/show_bug.cgi?id=5396

--- Comment #2 from Thomas Petazzoni <[email protected]> 2012-07-24 11:45:06 UTC --- 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.

Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

https://bugs.busybox.net/show_bug.cgi?id=5396

--- Comment #3 from Jonathan Liu <[email protected]> 2012-07-24 12:46:37 UTC --- (In reply to comment #2)

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

Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

https://bugs.busybox.net/show_bug.cgi?id=5396

--- Comment #4 from Thomas Petazzoni <[email protected]> 2012-07-24 12:55:54 UTC --- (In reply to comment #3)

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.

Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

https://bugs.busybox.net/show_bug.cgi?id=5396

--- Comment #5 from Thomas De Schampheleire <[email protected]> 2014-05-07 11:00:29 UTC --- 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.

Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

https://bugs.busybox.net/show_bug.cgi?id=5396

Thomas De Schampheleire <[email protected]> changed:

What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |2014.05

Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

https://bugs.busybox.net/show_bug.cgi?id=5396

--- Comment #6 from Thomas De Schampheleire <[email protected]> 2014-05-14 08:15:09 UTC ---
Jonathan: any feedback? Could you retest this bug with the latest buildroot?

Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

https://bugs.busybox.net/show_bug.cgi?id=5396

Thomas De Schampheleire <[email protected]> changed:

What |Removed |Added
----------------------------------------------------------------------------

             Status|NEW                         |RESOLVED
         Resolution|                            |WORKSFORME

--- Comment #7 from Thomas De Schampheleire <[email protected]> 2014-05-18 19:19:45 UTC --- 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.

Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.