GNOME Bugzilla – Bug 81232
Solaris problem with missing symbols
Last modified: 2011-02-04 16:10:07 UTC
When compiling gtk+ 2.0.2 under Solaris 8: (Might be a duplicate of bug 75345) Although it doesn't seem to show its head till the test program 'testgtk' is compiled/linked. Simple gtk tests that don't reference symbols seem to work ok (eg 'simple'). Error output is as follows: /bin/sh ../libtool --mode=link gcc -I/var/tmp/.kon/garnome/include -g -O2 -Wall -L/var/tmp/.kon/garnome/lib -o testgtk prop-editor.o testgtk.o ../gdk-pixbuf/libgdk_pixbuf-2.0.la ../gdk/libgdk-x11-2.0.la ../gtk/libgtk-x11-2.0.la gcc -I/var/tmp/.kon/garnome/include -g -O2 -Wall -o .libs/testgtk prop-editor.o testgtk.o -L/var/tmp/.kon/garnome/lib ../gdk-pixbuf/.libs/libgdk_pixbuf-2.0.so ../gdk/.libs/libgdk-x11-2.0.so ../gtk/.libs/libgtk-x11-2.0.so /var/tmp/.kon/garnome-0.9.6/gnome/gtk+/work/gtk+-2.0.2/gdk/.libs/libgdk-x11-2.0.so /var/tmp/.kon/garnome-0.9.6/gnome/gtk+/work/gtk+-2.0.2/gdk-pixbuf/.libs/libgdk_pixbuf-2.0.so -lXext -lX11 -lsocket -lnsl /var/tmp/.kon/garnome/lib/libpangox-1.0.so /var/tmp/.kon/garnome/lib/libpango-1.0.so /var/tmp/.kon/garnome/lib/libatk-1.0.so /var/tmp/.kon/garnome/lib/libgobject-2.0.so /var/tmp/.kon/garnome/lib/libgmodule-2.0.so -ldl /var/tmp/.kon/garnome/lib/libglib-2.0.so -lm -R/var/tmp/.kon/garnome/lib ld: warning: file /var/tmp/.kon/garnome-0.9.6/gnome/gtk+/work/gtk+-2.0.2/gdk/.libs/libgdk-x11-2.0.so: linked to ../gdk/.libs/libgdk-x11-2.0.so: attempted multiple inclusion of file ld: warning: file /var/tmp/.kon/garnome-0.9.6/gnome/gtk+/work/gtk+-2.0.2/gdk-pixbuf/.libs/libgdk_pixbuf-2.0.so: linked to ../gdk-pixbuf/.libs/libgdk_pixbuf-2.0.so: attempted multiple inclusion of file Undefined first referenced symbol in file gtk_minor_version testgtk.o gtk_micro_version testgtk.o gtk_major_version testgtk.o ld: fatal: Symbol referencing errors. No output written to .libs/testgtk collect2: ld returned 1 exit status make[3]: *** [testgtk] Error 1 make[3]: Leaving directory `/var/tmp/.kon/garnome-0.9.6/gnome/gtk+/work/gtk+-2.0.2/tests'
No clue here. Doesn't really look the same as bug 75345 to me.
The version of gcc which is being used for Sun's internal builds is 2.95.3. Does this problem occur with that version?
In GCC3.1, the output is rather similar. Maybe this is a problem with 'ld' not gtk on solaris? $ gcc -v Reading specs from /opt/local/stow/gcc-3.1/lib/gcc-lib/sparc-sun-solaris2.8/3.1/specs Configured with: ../gcc-3.1/configure --prefix=/opt/local/stow/gcc-3.1 --with-local-prefix=/opt/local --enable-shared --enable-version-specific-runtime-libs --enable-languages=c,c++,java,objc,f77 Thread model: posix gcc version 3.1 -- creating testdnd gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../gdk -I../gdk -DG_ENABLE_DEBUG -D_REENTRANT -I/var/tmp/.kon/garnome/include/glib-2.0 -I/var/tmp/.kon/garnome/lib/glib-2.0/include -I/var/tmp/.kon/garnome/include/pango-1.0 -I/var/tmp/.kon/garnome/include/atk-1.0 -I/var/tmp/.kon/garnome/include -I/var/tmp/.kon/garnome/include -I/var/tmp/.kon/garnome/include -I/var/tmp/.kon/garnome/include -I/var/tmp/.kon/garnome/include -I/var/tmp/.kon/garnome/include -I/var/tmp/.kon/garnome/include -I/var/tmp/.kon/garnome/include -I/var/tmp/.kon/garnome/include -g -O2 -I/var/tmp/.kon/garnome/include -g -O2 -I/var/tmp/.kon/garnome/include -g -O2 -I/var/tmp/.kon/garnome/include -g -O2 -I/var/tmp/.kon/garnome/include -g -O2 -I/var/tmp/.kon/garnome/include -g -O2 -I/var/tmp/.kon/garnome/include -g -O2 -I/var/tmp/.kon/garnome/include -g -O2 -Wall -c prop-editor.c gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../gdk -I../gdk -DG_ENABLE_DEBUG -D_REENTRANT -I/var/tmp/.kon/garnome/include/glib-2.0 -I/var/tmp/.kon/garnome/lib/glib-2.0/include -I/var/tmp/.kon/garnome/include/pango-1.0 -I/var/tmp/.kon/garnome/include/atk-1.0 -I/var/tmp/.kon/garnome/include -I/var/tmp/.kon/garnome/include -I/var/tmp/.kon/garnome/include -I/var/tmp/.kon/garnome/include -I/var/tmp/.kon/garnome/include -I/var/tmp/.kon/garnome/include -I/var/tmp/.kon/garnome/include -I/var/tmp/.kon/garnome/include -I/var/tmp/.kon/garnome/include -g -O2 -I/var/tmp/.kon/garnome/include -g -O2 -I/var/tmp/.kon/garnome/include -g -O2 -I/var/tmp/.kon/garnome/include -g -O2 -I/var/tmp/.kon/garnome/include -g -O2 -I/var/tmp/.kon/garnome/include -g -O2 -I/var/tmp/.kon/garnome/include -g -O2 -I/var/tmp/.kon/garnome/include -g -O2 -Wall -c testgtk.c /bin/sh ../libtool --mode=link gcc -I/var/tmp/.kon/garnome/include -g -O2 -I/var/tmp/.kon/garnome/include -g -O2 -I/var/tmp/.kon/garnome/include -g -O2 -I/var/tmp/.kon/garnome/include -g -O2 -I/var/tmp/.kon/garnome/include -g -O2 -I/var/tmp/.kon/garnome/include -g -O2 -I/var/tmp/.kon/garnome/include -g -O2 -I/var/tmp/.kon/garnome/include -g -O2 -Wall -L/var/tmp/.kon/garnome/lib -L/var/tmp/.kon/garnome/lib -L/var/tmp/.kon/garnome/lib -L/var/tmp/.kon/garnome/lib -L/var/tmp/.kon/garnome/lib -L/var/tmp/.kon/garnome/lib -L/var/tmp/.kon/garnome/lib -L/var/tmp/.kon/garnome/lib -o testgtk prop-editor.o testgtk.o ../gdk-pixbuf/libgdk_pixbuf-2.0.la ../gdk/libgdk-x11-2.0.la ../gtk/libgtk-x11-2.0.la gcc -I/var/tmp/.kon/garnome/include -g -O2 -I/var/tmp/.kon/garnome/include -g -O2 -I/var/tmp/.kon/garnome/include -g -O2 -I/var/tmp/.kon/garnome/include -g -O2 -I/var/tmp/.kon/garnome/include -g -O2 -I/var/tmp/.kon/garnome/include -g -O2 -I/var/tmp/.kon/garnome/include -g -O2 -I/var/tmp/.kon/garnome/include -g -O2 -Wall -o .libs/testgtk prop-editor.o testgtk.o -L/var/tmp/.kon/garnome/lib ../gdk-pixbuf/.libs/libgdk_pixbuf-2.0.so ../gdk/.libs/libgdk-x11-2.0.so ../gtk/.libs/libgtk-x11-2.0.so /var/tmp/.kon/garnome-0.10.0/gnome/gtk+/work/gtk+-2.0.2/gdk/.libs/libgdk-x11-2.0.so /var/tmp/.kon/garnome-0.10.0/gnome/gtk+/work/gtk+-2.0.2/gdk-pixbuf/.libs/libgdk_pixbuf-2.0.so -lXext -lX11 -lsocket -lnsl /var/tmp/.kon/garnome/lib/libpangox-1.0.so /var/tmp/.kon/garnome/lib/libpango-1.0.so /var/tmp/.kon/garnome/lib/libatk-1.0.so /var/tmp/.kon/garnome/lib/libgobject-2.0.so /var/tmp/.kon/garnome/lib/libgmodule-2.0.so -ldl /var/tmp/.kon/garnome/lib/libglib-2.0.so -lm -R/var/tmp/.kon/garnome/lib ld: warning: file /var/tmp/.kon/garnome-0.10.0/gnome/gtk+/work/gtk+-2.0.2/gdk/.libs/libgdk-x11-2.0.so: linked to ../gdk/.libs/libgdk-x11-2.0.so: attempted multiple inclusion of file ld: warning: file /var/tmp/.kon/garnome-0.10.0/gnome/gtk+/work/gtk+-2.0.2/gdk-pixbuf/.libs/libgdk_pixbuf-2.0.so: linked to ../gdk-pixbuf/.libs/libgdk_pixbuf-2.0.so: attempted multiple inclusion of file Undefined first referenced symbol in file gtk_minor_version testgtk.o gtk_micro_version testgtk.o gtk_major_version testgtk.o ld: fatal: Symbol referencing errors. No output written to .libs/testgtk collect2: ld returned 1 exit status make[10]: *** [testgtk] Error 1 make[10]: Leaving directory `/var/tmp/.kon/garnome-0.10.0/gnome/gtk+/work/gtk+-2.0.2/tests'
Seems this is the cause of my troubles... (A Snippit from the Python FAQ - it at least causes the same effects.) 3.36. relocations remain against allocatable but non-writable sections * This linker error occurs on Solaris if you attempt to build an extension module which incorporates position-dependent (non-PIC) code. A common source of problems is that a static library (.a file), such as libreadline.a or libcrypto.a is linked with the extension module. The error specifically occurs when using gcc as the compiler, but /usr/ccs/bin/ld as the linker. The following solutions and work-arounds are known: 1. Rebuild the libraries (libreadline, libcrypto) with -fPIC (-KPIC if using the system compiler). This is recommended; all object files in a shared library should be position-independent. 2. Statically link the extension module and its libraries into the Python interpreter, by editing Modules/Setup. 3. Use GNU ld instead of /usr/ccs/bin/ld; GNU ld will accept non-PIC code in shared libraries (and mark the section writable) 4. Pass -mimpure-text to GCC when linking the module. This will force gcc to not pass -z text to ld; in turn, ld will make all text sections writable. Options 3 and 4 are not recommended, since the ability to share code across processes is lost.
Are you sure about this? It doesn't look related to the error messages you've pasted here. Do you have any idea about what .a file was involved?
You are probably right... the comments before didn't seem to help.. I saw that glib, seems to be able to use external 'variables' in the shared objects so I ran 'nm' on both the glib so and gtk so, and here are the results: $ nm libglib-2.0.so | grep version 00073ec8 R glib_major_version 00073ed0 R glib_micro_version 00073ecc R glib_minor_version $ nm libgtk-x11-2.0.so | grep version 000f2e9c T gtk_check_version 002565e8 r gtk_major_version 002565f0 r gtk_micro_version 002565ec r gtk_minor_version 'R' vs 'r' apparently means: R External read only. r Local read only. I guess 'local' explains why the test programs do not 'link' with the symbol. And there is probably some simple explanation on why my build is making variables in the .so 'local'... but I haven't figured out how to fix it myself.
I seemed to have fixed the problem at last.. however I don't know what specifically fixed it. I upgraded libtool from: ltmain.sh (GNU libtool) 1.3.5 (1.385.2.206 2000/05/27 11:12:27) to: ltmain.sh (GNU libtool) 1.4.2 (1.922.2.53 2001/09/11 03:18:52) Then I changed some lines in the produced Makefile: removed: -export-symbols-regex "^[^_].*" and added: -export-symbols $(gtk_def) where gtk_def = gtk.def The comment near this line seemed to suggest the requirement of a "newish" version of libtool - hence I am unsure how useful such a "fix" is. Without it though, the "stripping" process make all of the shared object variables local, and allowed functions to be exported.
*** Bug 89137 has been marked as a duplicate of this bug. ***
The -export-symbols-regex feature of libtool being broken on some combinations of GCC and Solaris versions seems a probable explanation.
I have exactly the same problem with Solaris 9 on Sun Ultra 10, gcc- 3.1, libtool-1.4. By following Konsanty's suggestion, I do the below steps: #cp gtk/gtk.def gtk/gtk.sym #vi gtk/Makefile to change -export-symbol gtk.sym line #make clean;make #nm gtk/.libs/libgtk-x11-2.0.so|grep version, the outputs are still 000f2e9c T gtk_check_version 002565e8 r gtk_major_version 002565f0 r gtk_micro_version 002565ec r gtk_minor_version So I'm in doubt is that real solution?
I got it compiled with gcc-2.95.3 without any problem, linker line in /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/specs is /usr/local/sparc-sun-solaris2.8/bin/ld, rather than /usr/ccs/bin/ld in gcc-3.1, (all I installed are binary packages from www.sunfreeware.com, I didn't try to compile gcc by myself). So I believe the 3rd solution (the 4 workarounds posted by Konsanty dated 2002-5-28) is working.
#vi gtk/Makefile to change -export-symbol gtk.sym line Many people seem to be changing the first occurance of export-symbols-regex ie: LIBTOOL_EXPORT_OPTIONS = -export-symbols-regex "^[^_].*" The Line of interest is in: LDFLAGS = $(strip $(STRIP_DUMMY) \ -version-info $(LT_CURRENT):$(LT_REVISION):$(LT_AGE)\ -export-dynamic\ -rpath $(libdir)\ $(no_undefined)\ -export-symbols-regex "^[^_].*" .... quite a fair way down...
yes, I changed the line in LDFLAGS = ..., it compiled sucessfully with gcc-3.1, overwrite /usr/ccs/bin/ld with /usr/local/bin/ld, which is gnu ld.
I haven't really followed all the libtool debate above, but presumably you're all aware that the undefined symbols are all marked as "const" in the source code and it's this that seems to be confusing gcc/ld about whether they should be global or local? This has been discussed many times on the mailing list (gtk-list), including 5th and 25th September and 21st and 24th October. For example, see: http://mail.gnome.org/archives/gtk-list/2002- September/msg00023.html The quick fix seems to be to remove the const from their definitions, both in the C and H files (gtkmain.c and gtkmain.h) but alternatively someone suggested making wrapper functions to return the values (and keeping the values private).
If const variables are not being exported that's a bug in the tools, and I'd rather not work around it. It's probably either: A) A compiler bug. But unlikely since GCC works fine elsewhere. B) A bug in the interaction beween GCC and the Solaris linker. A bit unlikely since someone else would probably have noticed the problem. C) A bug in the interaction between libtool -export-symbols-regex, the Solaris linker, and constant symbols. It should be possible to determine whether A) is the problem or not by examing the output of nm gtk/gtkmain.lo - it should contain a line like: 00000000 R gtk_major_version (Exact details may vary -- the above is on Linux) B) can be checked by writing a small test case with two source files. But most likely it is C), since people are reporting that removing -export-symbols-regex fixes the problem. It probably would be useful to create a simple standalone example with libtool + straight C that demonstrates the problem and give that to the libtool people.
Did some investigation of the libtool code with help from Alexandre Oliva; it turns out to be a problem in the determination of the list of symbols to export. (In aclocal.m4 or libtool.m4, change solaris* | sysv5*) symcode='[[BDT]]' ;; to: solaris* | sysv5*) symcode='[[BDRT]]' ;; and it should work.) I've mailed a bug report to bug-libtool@gnu.org: http://mail.gnu.org/pipermail/bug-libtool/2002-October/004272.html.
The libtool package I used for making the 2.0.7 distribution has this bug patched in it, so unless you rerun libtoolize it should work OK.