Hello, On 10/01/2014 03:48 AM, Daiki Ueno wrote:
I've finally had a chance to build gettext on Solaris, and indeed encountered several portability errors. Could anyone try a snapshot including fixes of those? It is now available from here: http://alpha.gnu.org/gnu/gettext/gettext-0.19.2.1-rc1.tar.xz
Some testing results (all except GNU Hurd and Minix are amd64): FreeBSD 10: builds OK (with clang, some warning about signed/unsigned and "comparison always true"), check hangs at 'test-lock', seems related to this: http://lists.gnu.org/archive/html/bug-libunistring/2014-09/msg00005.html http://lists.gnu.org/archive/html/bug-gnulib/2014-09/msg00025.html OpenBSD 5.5: builds OK, checks: 145 PASS, 33 SKIP, 0 FAIL NetBSD 6.1.4: builds OK, checks: 158 PASS, 19 SKIP, 1 FAIL: test-sigprocmask (part of gnulib) GNU Hurd 0.5 (i386, with Debian image): builds OK, checks: 145 PASS, 33 SKIP, 0 FAIL DilOS 1.3.7 (Illumos/OpenSolaris-based OS): builds OK (after installing libiconv-dev), checks: 350 PASS, 40 SKIP, 1 FAIL: lang-c++ ==== FAIL: lang-c++ ============== In file included from /usr/include/sys/time.h:450:0, from /tmp/gettext-0.19.2.1-rc1/gettext-tools/gnulib-lib/sys/time.h:39, from /usr/include/sys/select.h:51, from /tmp/gettext-0.19.2.1-rc1/gettext-tools/gnulib-lib/sys/select.h:36, from /usr/include/sys/types.h:629, from /tmp/gettext-0.19.2.1-rc1/gettext-tools/gnulib-lib/sys/types.h:28, from /tmp/gettext-0.19.2.1-rc1/gettext-tools/gnulib-lib/stdio.h:58, from /tmp/gettext-0.19.2.1-rc1/gettext-tools/gnulib-lib/wchar.h:71, from /usr/gcc/4.8/include/c++/4.8.3/cwchar:44, from /usr/gcc/4.8/include/c++/4.8.3/bits/postypes.h:40, from /usr/gcc/4.8/include/c++/4.8.3/iosfwd:40, from /usr/gcc/4.8/include/c++/4.8.3/ios:38, from /usr/gcc/4.8/include/c++/4.8.3/ostream:38, from /usr/gcc/4.8/include/c++/4.8.3/iostream:39, from prog.cc:5: gets(char*)’ conflicts with previous using declaration ‘char* std::gets(char*)’ _GL_WARN_ON_USE (gets, "gets is a security hole - use fgets instead"); ==== (NOTE: This might be a problem with DilOS's packaging of gcc/libstrc++ , I had few other issues on this system). CentOS 6.5: builds OK, checks: 372 PASS, 18 SKIP, 1 FAIL: autopoint-3 (see below) ==== FAIL: autopoint-3 ================= configure.ac:1: error: m4_defn: undefined macro: _m4_divert_diversion configure.ac:1: the top level autom4te: /usr/bin/m4 failed with exit status: 1 aclocal: autom4te failed with exit status: 1 ==== CentOS 7.0: builds OK, checks: 159 PASS, 19 SKIP, 0 FAIL Ubuntu 14.04.1 LTS: builds Ok, checks: 145 PASS, 33 SKIP, 0 FAIL Debian 7.6: builds ok, checks: 145 PASS, 33 SKIP, 0 FAIL MINIX R3.3.0: build fails, gnulib-related: === libtool: compile: clang -DHAVE_CONFIG_H -DEXEEXT=\"\" -DEXEEXT=\"\" -DEXEEXT=\"\" -I. -I.. -I../intl -I../intl -I.. -I.. -DDEPENDS_ON_LIBICONV=1 -DDEPENDS_ON_LIBINTL=1 -DLIBXML_STATIC -I./libcroco -g -O2 -c spawn_faction_addclose.c -o spawn_faction_addclose.o spawn_faction_addclose.c:50:21: error: no member named '_used' in 'struct posix_spawn_file_actions' if (file_actions->_used == file_actions->_allocated ~~~~~~~~~~~~ ^ spawn_faction_addclose.c:50:44: error: no member named '_allocated' in 'struct posix_spawn_file_actions' if (file_actions->_used == file_actions->_allocated ~~~~~~~~~~~~ ^ spawn_faction_addclose.c:59:26: error: no member named '_actions' in 'struct posix_spawn_file_actions' rec = &file_actions->_actions[file_actions->_used]; ~~~~~~~~~~~~ ^ spawn_faction_addclose.c:59:49: error: no member named '_used' in 'struct posix_spawn_file_actions' rec = &file_actions->_actions[file_actions->_used]; ~~~~~~~~~~~~ ^ spawn_faction_addclose.c:64:21: error: no member named '_used' in 'struct posix_spawn_file_actions' ++file_actions->_used; ~~~~~~~~~~~~ ^ 5 errors generated. *** Error code 1 Stop. make[5]: stopped in /tmp/gettext-0.19.2.1-rc1/gettext-tools/gnulib-lib *** Error code 1 === ===== One thing I noticed (which could be intentional), is that building gettext requires a C++ compiler, but gettext does not check the existence of it during "configure". If the system has "g++" or "c++" available on $PATH, it will be used. If the system does not have "g++" or "c++" on $PATH, no error will be reported during "configure", and the Makefile will default to use "g++", and during "make" the build will fail. I encountered it in two cases: 1. On a system with "/usr/bin/cc" as symlink to "/usr/bin/clang", but without "gcc", "g++" or "c++", configure runs OK, but 'make' fails when it tries to run "g++". 2. Building with a cross-compiler: ./configure --host=arm-linux-gnueabi Where the system has "/usr/bin/arm-linux-gnueabi-gcc" but not "/usr/bin/arm-linux-gnueabi-g++", configure runs OK, but 'make' fails when it tries to run "g++". With another cross-compiler (x86_64-w64-mingw32) where both "/usr/bin/x86_64-w64-mingw32-gcc" and "/usr/bin/x86_64-w64-mingw32-g++" exist, the correct compiler is used. ==== Regards, - Assaf
