[Top][All Lists]

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

Re: [bug-gettext] make -q and maintainer-makefile issues?

From: Bruno Haible
Subject: Re: [bug-gettext] make -q and maintainer-makefile issues?
Date: Fri, 12 Aug 2011 19:00:25 +0200
User-agent: KMail/1.13.6 (Linux/; KDE/4.6.0; x86_64; ; )

[CCing bug-gettext and Charles Wilson]
Eric Blake wrote in [1]:
> At least cygwin still ships with 
> only gettext 0.17, because all versions of 0.18 are unbuildable on the 
> current cygwin.

This is a myth, and is factually wrong.

I just built gettext on a Cygwin 1.7.5 system, with gcc 4.3.4,
and it passed "make check" with only 1 failure in lang-tcl, and
"make install" succeeded as well. Likewise on Cygwin 1.7.9, with
gcc 4.3.4 as well. The build command was:

$ mkdir build3
$ cd build3
$ ../configure --prefix=/usr/local/cygwin \
               CPPFLAGS="-I/usr/local/cygwin/include -Wall" \
               LDFLAGS="-L/usr/local/cygwin/lib" \
               --with-included-libxml 2>&1 | tee log1
$ make 2>&1 | tee log2
$ make check 2>&1 | tee log3
$ make install 2>&1 | tee log4

Reviewing the history of these build reports:

* Eric Blake tried to build it on 2010-06-16 [2], got the error

  undefined reference to `_xmlFree'

  I recommended trying --without-libxml2-prefix [3]. This would have helped
  if libxml2 was installed in a nonstandard location. But it's installed in
  /usr/lib/, so the option that's needed is --with-included-libxml.

  He reports that he "ran into a bug with the cygwin linker claiming that
  libintl.dll.a had an invalid symbol relocation". Well, on Cygwin 1.7.5
  and 1.7.9 I don't run into this bug. So, install Cygwin 1.7.5 or 1.7.9,
  and you can build gettext binaries.

* Markus Moeller reported this error [4]

   collect2: ld terminated with signal 6 [Aborted]
/usr/lib/libintl.dll.a(d000050.o): illegal symbol index 1633970 478 in relocs
   make[4]: *** [msgcmp.exe] Error 1

  whereupon Corinna Vinschen put the blame on gettext [5].
  Then Markus Moeller gave it a try with the opposite flag than what
  what gettext uses and found that the same linker error still existed [6].
  So it was *not* a problem with gettext's use of --disable-auto-import.

* After which Eric Blake continued to report that gettext 0.18 does not
  build on Cygwin 1.7. [7]

Half of his diagnosis in [7] was correct:

  * The xmlFree link error is a consequence of --disable-auto-import.

    $ cat > foo.c <<EOF
    #include <libxml/xmlversion.h>
    #include <libxml/xmlmemory.h>
    int main ()
      xmlCheckVersion (0); xmlFree ((void *) 0);
      return 0;
    $ gcc -I/usr/include/libxml2 foo.c -lxml2
    [works fine]
    $ gcc -I/usr/include/libxml2 foo.c -lxml2 -Wl,--disable-auto-import
    /tmp/cc4EveXj.o:foo.c:(.text+0x23): undefined reference to `_xmlFree'
    collect2: ld returned 1 exit status

    But gettext's configure provides the right option to fix it. You
    only need to do "./configure --help | grep xml".

    Additionally, the next version of gettext will detect this situation

  * The Cygwin maintainer of gettext didn't put enough time into it.

The other half of the diagnosis was incorrect:

  * No, gettext is not unbuildable on Cygwin.

  * No, the collect2 linker crash has been demonstrated to also occur
    with --enable-auto-import.

I hope, with this mail, I've helped to separate truth from myth.

Please, next time, be more modest and don't say "gettext is unbuildable",
but rather "I have not succeeded in building gettext".


[1] http://lists.gnu.org/archive/html/bug-gnulib/2011-08/msg00099.html
[2] http://lists.gnu.org/archive/html/bug-gnu-utils/2010-06/msg00057.html
[3] http://lists.gnu.org/archive/html/bug-gnu-utils/2010-06/msg00061.html
[4] http://cygwin.com/ml/cygwin/2010-08/msg00082.html
[5] http://cygwin.com/ml/cygwin/2010-08/msg00154.html
[6] http://cygwin.com/ml/cygwin/2010-08/msg00157.html
[7] http://www.cygwin.com/ml/cygwin/2011-01/msg00400.html
In memoriam Itzik Feffer <http://en.wikipedia.org/wiki/Itzik_Feffer>

reply via email to

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