[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug-gettext] mingw-w64 build failure due to DLL variable e

From: lrn1986
Subject: Re: [bug-gettext] mingw-w64 build failure due to DLL variable exports
Date: Wed, 14 Mar 2018 23:53:50 +0300
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:59.0) Gecko/20100101 Thunderbird/59.0

On 14.03.2018 20:36, Bruno Haible wrote:

If you followed the build instructions [1]

I use MSYS instead of plain Cygwin, and i use i686 MinGW-w64 natively instead of cross-compiling, i don't adjust PATH (already set correctly to give MinGW tools a priority), don't supply -L and -I paths (MinGW already uses the directories from its prefix by default) and don't override CC and CXX (autotools just picks up gcc and g++ executables, which is correct).
Other than that, it's pretty much standard:

$ libtoolize --automake --copy --force
$ ./autogen.sh --skip-gnulib
$ cd bld && configure ../gettext- --prefix=/mingw \
    --enable-shared --enable-static --enable-silent-rules \
    --enable-threads=posix \
    --with-included-gettext --with-included-glib --with-included-libcroco \
    --with-included-unistring --with-included-libxml \
    --disable-rpath \
    --disable-openmp \
    --without-emacs --disable-native-java --disable-curses \
    --enable-relocatable \
    --build=i686-w64-mingw32 \
    CFLAGS="-g -O2" \
    CXXFLAGS="-g -O2"
$ make

, please register a bug at the tracker

Can't do that yet. Savannah deleted my account (again), and so far i haven't heard from the support about restoring it.

, and tell whether you are compiling with 32-bit or 64-bit mingw-w64.

i686, so 32-bit

I have no idea how this was supposed to work.

Consider the code and comments in

It is possible that the #if in gettext-tools/woe32dll/export.h needs to be

After noticing that 0.19.7 built just fine, i re-checked some things, and it turns out that the "checking whether C symbols are prefixed with underscore at the linker level" test results in "yes" in 0.19.7, but "no" in later versions. Looking at the diff between versions, the asm-underscore.m4 changed the grep expression. Looking at the configure script that was regenerated, i see this:

LC_ALL=C grep -E '(^|^a-zA-Z0-9_)_foo(^a-zA-Z0-9_|$)' conftest.$gl_asmext

whereas the .m4 file has this:

LC_ALL=C grep -E '(^|[^a-zA-Z0-9_])_foo([^a-zA-Z0-9_]|$)' conftest.$gl_asmext

So clearly some square brackets were lost, and this resulted in a failed grep and a failed test.

I replaced square brackets with appropriate quadrigraphs, and the build 

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]