[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: possible bug in libtool w/ MinGW on Chinese locale
From: |
Ralf Wildenhues |
Subject: |
Re: possible bug in libtool w/ MinGW on Chinese locale |
Date: |
Sat, 13 Mar 2010 11:31:36 +0100 |
User-agent: |
Mutt/1.5.20 (2009-10-28) |
[ Tim, there is a question for you below ]
Hello Pete, Xiaofan,
thanks both of you for the fine and detailed bug report.
* Pete Batard wrote on Mon, Mar 08, 2010 at 06:36:23PM CET:
> When running libtool with the attached files to produce a DLL, on
> Windows Vista 32 bit Chinese (PRC) with MinGW/MSYS and with no
> locale set in the shell (i.e. LANG, LC_ALL, LC_TYPE, etc.
> undefined), the attached files fail with the following:
[...]
> *** Warning: linker path does not have real file for library -lole32.
[...]
> As soon as you set the locale in the shell, the problem disappears:
>
> $ export LANG=en_US
> $ ./runme.sh
[...]
> libtool: link: rm -fr .libs/libtest.a .libs/libtest.la .libs/libtest.lai
> libtool: link: gcc -shared .libs/test.o -lole32 -o
> .libs/libtest.dll -Wl,-
> -enable-auto-image-base -Xlinker --out-implib -Xlinker .libs/libtest.dll.a
> Creating library file: .libs/libtest.dll.a
> libtool: link: ar cru .libs/libtest.a test.o
> libtool: link: ranlib .libs/libtest.a
> libtool: link: ( cd ".libs" && rm -f "libtest.la" && cp -p
> "../libtest.la" "libtest.la" )
> The problem also does not seem to occur with cygwin, as locale
> environment variable seem to be defined by default there.
>
> Note that it might not be possible to reproduce the issue on non
> Chinese versions of Windows, by trying to change the default locale
> (or at least, I haven't managed to do so).
>
> Our current workaround then is to force the "# NLS nuisances" test
> of libtool to set the locale variables always, even if none are
> currently defined.
>
> For background information on the issue, you can consult the libusb
> mailing list archive at:
> http://old.nabble.com/Problem-compiling-with-MingW-td27762662i80.html
A couple of questions:
1) Would it also be sufficient to just
LC_ALL=C; LANGUAGE=C; export LANGUAGE LC_ALL
or do you actually need LANG to be set? Autoconf-generated configure
scripts set these two unconditionally, so I don't expect any problems
there.
2) If LANG needs to be set, then we may run into
# Only set LANG and LC_ALL to C if already set.
# These must not be set unconditionally because not all systems understand
# e.g. LANG=C (notably SCO).
Tim, this code was from some initial revision in '97. Do I gather
correctly that it has no relevance today, and that we should just
remove this?
Thanks,
Ralf