Thanks for the bug report! Could you attach the Buildroot .config that exhibits the problem so that we can easily reproduce? Thanks!

Created attachment 5480 [details]
.config

I find it very odd that creating a link in the _target_ directory would modify the behavior of a host command (being localedef, which generates the error). 

Are you sure that the adding of the link is directly related to the solving of the error? Can you reproduce that flow?
If so, could you provide more details on where the connection is between the error scenario and the link?

I cannot reproduce this, but I looked at the source code of localedef, and the error is generated in a path like this (based on string matching):

  /* Create a temporary file in the correct directory.  */
  fd = mkstemp (fname);
  if (fd == -1)
    error (EXIT_FAILURE, errno, _("cannot create temporary file"));

where as far as I understand this temporary file would be created in output/target/usr/share/locale. The creation of this directory happens in the buildroot Makefile, and this code has been there for a while now.

So currently I don't understand what really happens. Any feedback you can give, possible with an 'strace -f' output would be very useful.

I installed Fedora 20 on a 64-bit VirtualBox machine, and built buildroot 2014.05 with the configuration you provided.
The build went successful, and thus I am not able to reproduce this issue:

>>> host-localedef 2.14.1-r17443-ptx1 Installing to host directory
/usr/bin/install -D -m 0755 /home/tdescham/buildroot-2014.05/output/build/host-localedef-2.14.1-r17443-ptx1/localedef /home/tdescham/buildroot-2014.05/output/host/usr/bin/localedef
Generating locale en_US.UTF-8
>>>   Finalizing target directory
rm -f /home/tdescham/buildroot-2014.05/output/build/locales.nopurge
for i in C en; do echo $i >> /home/tdescham/buildroot-2014.05/output/build/locales.nopurge; done


Moreover, as I mentioned in a previous comment, the relation between a lib64 symlink in output/target and the generation of locales failing due to a temporary file, sounds very odd to me.

For these reasons, I am closing this bug report. 
Do reopen this bug if you can prove that the problem is reproducible. In this case, please try to provide us with more detail regarding the problem, given that I was not able to reproduce with seemingly the same configuration. Do also verify with the latest buildroot in this case.

Created attachment 5558 [details]
strace log of localedef

I ThomasDS,

I have just give a try and I'm able to reproduce this issue with the latest buildroot master on a Federa 20 64bits.

It seems that localedef can't create "target/usr/lib64/locale/locale-archive.dRUlDK" file since the directory "target/usr/lib64" doesn't exist.

When the symbolic link is created in target/usr/lib64 to target/usr/lib/, the locale-archive.dRUlDK file is correctly created.

So yes, localedef fail to create a temporary file, not in target/usr/share/locale but in target/usr/lib64/locale.

Here is the strace log of localedef.

I hope it can help you.

(Reopen after more feedback from Romain)

Hi Romain, 

Thanks a lot for the strace!
It's odd though, as I don't see the same here. If I run the same strace in my 64-bit VirtualBox Fedora 20 installation, I see locale-archive is searched in output/target/usr/lib/locale/, not lib64.

Looking in the sources of localedef: (just some snippets)

glibc/locale/programs/locarchive.c:57:
#define ARCHIVE_NAME LOCALEDIR "/locale-archive"

  if (output_prefix)
    memcpy (archivefname, output_prefix, prefix_len);
  strcpy (archivefname + prefix_len, ARCHIVE_NAME);
  strcpy (stpcpy (fname, archivefname), ".XXXXXX");

Makefile:
-DLOCALEDIR='"$(localedir)"'
localedir       = $(libdir)/locale
prefix          = /usr
exec_prefix     = ${prefix}
libdir          = ${exec_prefix}/lib

In the building of localedef, I can see in the build commands that -DLOCALEDIR=/usr/lib/locale is passed.
Could you checked what is passed in your case? Is it lib64 or lib?

In locarchive.c, the filename that is used for the mktemp call is composed from the prefix we pass (TARGET_DIR --> output/target) followed by the ARCHIVE_NAME. This ARCHIVE_NAME starts with LOCALEDIR, which is thus supposed to be /usr/lib/locale.

The only way I can see this failing (currently) is when LOCALEDIR in the build commands of host-localedef is already using lib64, which would mean that either the configure command does something unexpected, or the 'libdir' variable in the localedef Makefile is overruled on the command-line.

Created attachment 5564 [details]
Fedora 20 config.site file

Hi Thomas,

I found the issue, see the patch:
http://patchwork.ozlabs.org/patch/379752/

At the top of configure script output I had:
"configure: loading site script /usr/share/config.site"
(see attached file)

Without that, target/usr/lib/locale/ is used as expected.

I think this bug can be closed now :)

Thanks for this further investigation and fix!

Using 'yum whatprovides /usr/share/config.site' I was able to determine that this file is installed by the 'autoconf' package. Since my Fedora installation does not have autoconf installed, I could not reproduce the bug. 
Copying your config.site file manually indeed causes the bug for me too.

I tested your patch successfully. I will provide this feedback on the mailing list. Once your patch is applied, we can close this bug.

Proposed patch was applied as commit http://git.buildroot.net/buildroot/commit/?id=85448febb3c9f21e6e4082fc344b3ef46261c782. Closing bug.