bug-coreutils
[Top][All Lists]
Advanced

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

The make-check phase in 8.1 fails to BUILD test-xalloc-die on MacOSX.


From: SciFi
Subject: The make-check phase in 8.1 fails to BUILD test-xalloc-die on MacOSX.
Date: Sat, 5 Dec 2009 18:18:11 +0000 (UTC)
User-agent: Pan/0.133 (House of Butterflies; SVNr370+549655+403797+541676+424083+351196+527313+579753+465763; i386-apple-darwin9.8.0)

Hi,

[I have reasons to stay anonymous, please, and am posting this thru gmane]

I hop onto this project from time to time as a hobbyist; I am not considered
any kind of expert, at least not anymore… but I think I need to report a
problem not mentioned on this nor on gnulib maillists for quite a while.

I am running MacOSX 10.5.8 “Leopard” with all of Apple’s official updates and
latest XCode-3.1.4 (actually the one that comes with iPhoneSDK-3.1.2).

The make-all & make-install for coreutils-8.1 seemed to go fine.

It was the make-check that failed during building its tools:

>>>>
depbase=`echo test-xalloc-die.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
        gcc-4.2 -std=gnu99  -I. -I../lib  -I. -I. -I.. -I./.. -I../lib 
-I./../lib -I/usr/X11/include -I/usr/local/include 
-I/Developer/Headers/FlatCarbon -I/usr/include    -fast      -mtune=core2 
-march=core2 -force_cpusubtype_ALL  -arch i386  -MT test-xalloc-die.o -MD -MP 
-MF $depbase.Tpo -c -o test-xalloc-die.o test-xalloc-die.c &&\
        mv -f $depbase.Tpo $depbase.Po
gcc-4.2 -std=gnu99   -fast      -mtune=core2 -march=core2 -force_cpusubtype_ALL 
 -arch i386   -fast      -mtune=core2 -march=core2 -force_cpusubtype_ALL  -arch 
i386  -o test-xalloc-die test-xalloc-die.o libtests.a ../lib/libcoreutils.a 
libtests.a  
Undefined symbols:
  "_libintl_gettext", referenced from:
      _xalloc_die in libcoreutils.a(xalloc-die.o)
      _error_tail in libcoreutils.a(error.o)
ld: symbol(s) not found
collect2: ld returned 1 exit status
make[5]: *** [test-xalloc-die] Error 1
<<<<

My configure cmd was:
./configure     \
--prefix=/usr/local     \
--with-libiconv-prefix=/usr/local       \
--with-libintl-prefix=/usr/local        \
--enable-dependency-tracking    \
--disable-silent-rules  \


Obviously something somewhere did not pick-up the -L/-l strings needed to
build the test-xalloc-die component properly.  I believe the actual problem
is/was in the original gnulib tree somewhere.

I have not seen any patches in the gnulib maillist [thru gmane] dealing with
this particular problem, either.

For me, I “repaired” this by somehow forcing coureutils-8.1/gnulib-tests to
bring-in some different dependencies for @LIBINTL@ that were totally missing:

>>>>
--- ../../coreutils-8.1(prev)/gnulib-tests/gnulib.mk    2009-11-18 09:03:22 
-0600
+++ ./gnulib.mk 2009-11-22 05:43:10 -0600
@@ -1633,6 +1633,7 @@
 TESTS += test-xalloc-die.sh
 TESTS_ENVIRONMENT += EXEEXT='@EXEEXT@'
 check_PROGRAMS += test-xalloc-die
+test_xalloc_die_LDADD = $(LDADD) @LIBINTL@
 EXTRA_DIST += test-xalloc-die.c test-xalloc-die.sh
 
 ## end   gnulib module xalloc-die-tests
<<<<

and:

>>>>
--- ../../coreutils-8.1(prev)/gnulib-tests/Makefile.in  2009-11-18 09:04:31 
-0600
+++ ./Makefile.in       2009-11-22 05:43:58 -0600
@@ -1185,9 +1185,8 @@
        libtests.a $(am__DEPENDENCIES_1)
 test_xalloc_die_SOURCES = test-xalloc-die.c
 test_xalloc_die_OBJECTS = test-xalloc-die.$(OBJEXT)
-test_xalloc_die_LDADD = $(LDADD)
-test_xalloc_die_DEPENDENCIES = libtests.a ../lib/libcoreutils.a \
-       libtests.a $(am__DEPENDENCIES_1)
+test_xalloc_die_LDADD = $(LDADD) @LIBINTL@
+test_xalloc_die_DEPENDENCIES = $(am__DEPENDENCIES_2)
 test_xfprintf_posix_SOURCES = test-xfprintf-posix.c
 test_xfprintf_posix_OBJECTS = test-xfprintf-posix.$(OBJEXT)
 test_xfprintf_posix_DEPENDENCIES = $(am__DEPENDENCIES_2)
<<<<

Of course be sure to re-make everything (needs distclean etc.).

Now finally I can run make-check completely, and we are still seeing the
same–old low–core crashes in some ‘conftest’s and the FAILs I had reported
here often in times past (during the 7.x series and with MacOSX-10.4 “Tiger”
even) which as I recall Jim Meyering does not want to spend time on, and I
wish I had the expertise to help.  It is rather glaring that Apple certainly
has not changed anything to help despite my sending them some detailed
crashreports over all this time.

I hope these patches will point to wherever the “real” fix(es) need to be
applied, and again I wish I had the expertise to help.

If there _is_ something I can do, please feel free to hollar
(misspelt on purpose, lol).

Thanks.






reply via email to

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