GNOME Bugzilla – Bug 314540
linker fails: libparser.a needs ranlib
Last modified: 2005-08-26 14:14:56 UTC
Please describe the problem: libparser.a is created by 'ar' but then 'ranlib' is never called on it. Without the ranlib call, the linker cannot link against the .a. Steps to reproduce: 1. unpack gcalctool-5.6.28 on OS X 10.3.9 (darwin7.9.0/ppc) with XCode1.5 (gcc3.3) 2. ./configure 3. make Actual results: ar r libparser.a lex.ce.o lex.lr.o ce_parser.tab.o lr_parser.tab.o ce_parser.o lr_parser.o ar: creating archive libparser.a /bin/sh ../libtool --mode=link gcc -O3 -funroll-loops -fstrict-aliasing -Wall -L/sw/lib -o gcalctool calctool.o display.o dsfuns.o get.o functions.o graphics.o mp.o mpmath.o parser.o gtk.o ce_parser.o lr_parser.o syntax_translation.o -L/sw/lib -L/usr/X11R6/lib -lgtk-x11-2.0 -lgdk-x11-2.0 -lXrandr -lXinerama -lXext -lXcursor -lpangoxft-1.0 -lXft -lXrender -lpangox-1.0 -lX11 -lpangoft2-1.0 -lfontconfig -lfreetype -lpango-1.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lintl -liconv -L/sw/lib -L/usr/X11R6/lib -lgnomeui-2 -lSM -lICE -lbonoboui-2 -lxml2 -lpthread -lz -lgnomecanvas-2 -lgnome-2 -lpopt -lart_lgpl_2 -lgtk-x11-2.0 -lgdk-x11-2.0 -lXrandr -lXinerama -lXext -lXcursor -latk-1.0 -lgdk_pixbuf-2.0 -lpangoxft-1.0 -lXft -lXrender -lpangox-1.0 -lX11 -lpangoft2-1.0 -lfontconfig -lfreetype -lpango-1.0 -lgobject-2.0 -lgnomevfs-2 -lbonobo-2 -lgconf-2 -lbonobo-activation -lORBit-2 -lm -lgmodule-2.0 -lgthread-2.0 -lglib-2.0 -lintl -liconv -L/sw/lib -lgconf-2 -lORBit-2 -lm -lgmodule-2.0 -lgthread-2.0 -lglib-2.0 -lintl -liconv libparser.a mkdir .libs gcc -O3 -funroll-loops -fstrict-aliasing -Wall -o gcalctool calctool.o display.o dsfuns.o get.o functions.o graphics.o mp.o mpmath.o parser.o gtk.o ce_parser.o lr_parser.o syntax_translation.o -L/sw/lib -L/usr/X11R6/lib /sw/lib/libgnomeui-2.dylib /sw/lib/libgnome-keyring.dylib /sw/lib/libjpeg.dylib /sw/lib/libbonoboui-2.dylib -lSM -lICE /sw/lib/libgnomecanvas-2.dylib /sw/lib/libgnome-2.dylib /sw/lib/libesd.dylib /sw/lib/libaudiofile.dylib /sw/lib/libart_lgpl_2.dylib /sw/lib/libgtk-x11-2.0.dylib /sw/lib/libgdk-x11-2.0.dylib -lXrandr -lXinerama -lXext -lXcursor /sw/lib/libatk-1.0.dylib /sw/lib/libgdk_pixbuf-2.0.dylib /sw/lib/libpangoxft-1.0.dylib -lXft -lXrender /sw/lib/libpangox-1.0.dylib -lX11 /sw/lib/libpangoft2-1.0.dylib -lfontconfig -lfreetype /sw/lib/libpango-1.0.dylib /sw/lib/libgnomevfs-2.dylib /sw/lib/libxml2.dylib -ldl -lpthread -lz /sw/lib/libbonobo-2.dylib /sw/lib/libbonobo-activation.dylib /sw/lib/libORBitCosNaming-2.dylib /sw/lib/libgconf-2.dylib /sw/lib/libORBit-2.dylib /sw/lib/libpopt.dylib /sw/lib/libgobject-2.0.dylib -lresolv -lm /sw/lib/libgmodule-2.0.dylib /sw/lib/libgthread-2.0.dylib /sw/lib/libglib-2.0.dylib /sw/lib/libintl.dylib -lc /sw/lib/libiconv.dylib libparser.a ld: archive: libparser.a has no table of contents, add one with ranlib(1) (can't load from it) ld: warning multiple definitions of symbol _locale_charset /sw/lib/libiconv.dylib(localcharset.o) definition of _locale_charset /sw/lib/libintl.dylib(localcharset.o) definition of _locale_charset ld: warning suggest use of -bind_at_load, as lazy binding may result in errors or different symbols being used symbol _locale_charset used from dynamic library /sw/lib/libiconv.dylib(localcharset.o) not from earlier dynamic library /sw/lib/libintl.3.dylib(localcharset.o) make[2]: *** [gcalctool] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 ### execution of make failed, exit code 2 Expected results: The compiler should not crash. Does this happen every time? Yes. Other information: The problem is that gcalctool/Makefile.am defines the exact (and not compeltely portable) command to build the libparser.a archive. As a quick fix, I made the following patch (still applicable to CVS HEAD): - ar r libparser.a $^ + $(AR) r libparser.a $^ + $(RANLIB) libparser.a Note also the use of utilities as determined by configure instead of presuming to know the specific unix command call. The package now compiles successfully and runs fine. A more general solution might be to use the standard libtool/Makefile.am approach to construct this convenience library instead of writing out the archiving commands explicitly.
An even better solution is not to even bother with a .a library. I need to go back and fixup this stuff that Sami introduced with the arithmetic operator precedence mode. You fix works nicely on my Solaris box too (though why it and Linux don't need to run ranlib is beyond me). Must be a BSD thing. Fix checked into CVS HEAD. I've bumped the version number to 5.6.30. I'll spin a new tarball on Monday. Thanks.