After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 81232 - Solaris problem with missing symbols
Solaris problem with missing symbols
Status: RESOLVED NOTGNOME
Product: gtk+
Classification: Platform
Component: .General
2.0.x
Other other
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
: 89137 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2002-05-09 11:46 UTC by Konsanty
Modified: 2011-02-04 16:10 UTC
See Also:
GNOME target: ---
GNOME version: 2.0



Description Konsanty 2002-05-09 11:46:20 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'
Comment 1 Owen Taylor 2002-05-14 19:25:46 UTC
No clue here. Doesn't really look the same as bug 75345 to me.
Comment 2 padraig.obriain 2002-05-15 07:53:49 UTC
The version of gcc which is being used for Sun's internal builds is
2.95.3.

Does this problem occur with that version?
Comment 3 Konsanty 2002-05-21 01:23:52 UTC
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'
Comment 4 Konsanty 2002-05-29 02:50:27 UTC
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. 
Comment 5 Owen Taylor 2002-05-29 19:01:52 UTC
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?
Comment 6 Konsanty 2002-06-18 01:35:43 UTC
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.

Comment 7 Konsanty 2002-06-24 12:02:17 UTC
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.
Comment 8 Owen Taylor 2002-07-28 12:46:16 UTC
*** Bug 89137 has been marked as a duplicate of this bug. ***
Comment 9 Owen Taylor 2002-07-30 20:48:48 UTC
The -export-symbols-regex feature of libtool being broken on some 
combinations of GCC and Solaris versions seems a probable
explanation.
Comment 10 yaleyu 2002-08-30 09:31:07 UTC
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?
Comment 11 yaleyu 2002-09-02 06:23:04 UTC
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.
Comment 12 Konsanty 2002-09-02 06:36:47 UTC
#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...
Comment 13 yaleyu 2002-09-03 09:23:33 UTC
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.

Comment 14 Richard Warren 2002-10-24 08:04:26 UTC
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).
Comment 15 Owen Taylor 2002-10-24 19:39:25 UTC
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.
Comment 16 Owen Taylor 2002-10-24 22:49:00 UTC
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.


Comment 17 Owen Taylor 2002-11-05 17:58:59 UTC
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.