IRIX 6.5 and exporting symbols.

[Peter Ekberg]

Hello!

I tried to build a library on IRIX 6.5 using libtool branch-2.0 (fairly
up to date) and gcc 3.2, and it fails.

The failing command is this:

/bin/sh ../libtool --mode=link --tag=CC gcc  -g -O2 -Wall -pedantic
-D_REENTRANT -D_THREAD_SAFE -DDEBUG -g -std=gnu99 -Wpointer-arith
-Wsign-compare -Wstrict-prototypes -Wswitch -Wmissing-prototypes
-Wreturn-type -Wshadow -Wnested-externs -Wredundant-decls
-Werror-implicit-function-declaration   -o libgg.la -rpath
/home/peda/ggi/irix6.5/root/lib  -version-info 1:0:0 -no-undefined
-export-symbols ../gg/EXPSYMS cleanup.lo  cleanup_stubs.lo cpuid.lo
conf.lo debug.lo dl.lo init.lo misc.lo parse.lo string.lo time.lo
task.lo ptlock.lo ptsched.lo   -lpthread

and the output complains about -exports_file:

gcc -shared  .libs/cleanup.o .libs/cleanup_stubs.o .libs/cpuid.o
.libs/conf.o .libs/debug.o .libs/dl.o .libs/init.o .libs/misc.o
.libs/parse.o .libs/string.o .libs/time.o .libs/task.o .libs/ptlock.o
.libs/ptsched.o   -lpthread  -Wl,-soname -Wl,libgg.so.2 `test -n
"sgi2.0" && print -r -Wl,-set_version -Wl,sgi2.0` -Wl,-update_registry
-Wl,.libs/so_locations -Wl,-exports_file -Wl,../gg/EXPSYMS -o
.libs/libgg.so.2.0
func_mode_link[3073]: print: bad option(s)
ld32: ERROR 4: Conflicting flag setting: -exports_file
ld32: ERROR 4: Conflicting flag setting: -exports_file
collect2: ld returned 2 exit status

So I tried without -export-symbols, like this:

/bin/sh ../libtool --mode=link --tag=CC gcc  -g -O2 -Wall -pedantic
-D_REENTRANT -D_THREAD_SAFE -DDEBUG -g -std=gnu99 -Wpointer-arith
-Wsign-compare -Wstrict-prototypes -Wswitch -Wmissing-prototypes
-Wreturn-type -Wshadow -Wnested-externs -Wredundant-decls
-Werror-implicit-function-declaration   -o libgg.la -rpath
/home/peda/ggi/irix6.5/root/lib  -version-info 1:0:0 -no-undefined
cleanup.lo  cleanup_stubs.lo cpuid.lo     conf.lo debug.lo dl.lo init.lo
misc.lo parse.lo string.lo time.lo     task.lo ptlock.lo ptsched.lo
-lpthread

which rendered this output:

gcc -shared  .libs/cleanup.o .libs/cleanup_stubs.o .libs/cpuid.o
.libs/conf.o .libs/debug.o .libs/dl.o .libs/init.o .libs/misc.o
.libs/parse.o .libs/string.o .libs/time.o .libs/task.o .libs/ptlock.o
.libs/ptsched.o   -lpthread  -Wl,-soname -Wl,libgg.so.2 `test -n
"sgi2.0" && print -r -Wl,-set_version -Wl,sgi2.0` -Wl,-update_registry
-Wl,.libs/so_locations -o .libs/libgg.so.2.0
func_mode_link[3073]: print: bad option(s)
(cd .libs && rm -f libgg.so.2 && ln -s libgg.so.2.0 libgg.so.2)
(cd .libs && rm -f libgg.so && ln -s libgg.so.2.0 libgg.so)
(cd .libs && rm -f libgg.so && ln -s libgg.so.2.0 libgg.so)
libtool: link: creating libgg.la
(cd .libs && rm -f libgg.la && ln -s ../libgg.la libgg.la)

The resulting library is ok with this change. So I edited the
archive_expsym_cmds variable in the generated libtool script. This
worked like a charm. I have not provided a patch since I have absolutely
no clue if removing the -exports_file option is the proper thing to do
in the general case...

(some time passes)

I have now found this message while googling, which sort of suggests
that the correct thing to do is indeed to drop the exports_file option,
at least when gcc -shared is used as a front-end to the native linker:
http://gcc.gnu.org/ml/gcc-bugs/2004-05/msg00366.html

Cheers,
Peter