RE: IRIX 6.5 and exporting symbols.

[Peter Ekberg]

Ralf Wildenhues wrote:
> Hi Peter,
> 
> * Peter Ekberg wrote on Wed, Mar 09, 2005 at 02:11:40PM CET:
>> On 2005-01-13, I wrote:
>>> 
>>> gcc -v -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
>>> -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
>>> 
>>> gets me:
>>> 
>>> Reading specs from
>>> /pkg/gcc/mips-irix65/3.2/lib/gcc-lib/mips-sgi-irix6.5/3.2/specs
>>> *snip*
>>> /pkg/gcc/mips-irix65/3.2/lib/gcc-lib/mips-sgi-irix6.5/3.2/crtend.o
>>> ld32: ERROR 4: Conflicting flag setting: -exports_file 
>>> ld32: ERROR 4: Conflicting flag setting: -exports_file
>>> collect2: ld returned 2 exit status
>>> 
>>> Which provides further evidence that the gcc ML message referred to
>>> in the original post was correct. I.e. the -hidden_symbol
>>> argument is what
>>> conflicts with -exports_file, since -exports_file automatically
>>> hides all symbols not mentioned and hiding a symbol twice is
>>> apparently treated as a conflict (which is a bit mysterious).
>> 
>> I thought I'd provide a patch against the 2.0 branch.
>> 
>> It simply disables the possibility to specify which symbols
>> you want to export, since this can't be done in a reliable
>> way.
> 
> Ouch.  And does so for all gcc versions and all irix[56] versions plus
> nonstoupx (whatever that is..).  This is definitely too broad for a
> workaround.  This must've worked at some time in the past (with some
> older gcc maybe?), it would not be nice to kill that for
> possible users.

At least I got some attention :-)

I know that it happens for gcc 2.8.1 and gcc 3.2.something.
The gcc bug report indicates that it also happens on
gcc 3.4.0.

All instances of the bug are on mips-sgi-irix6.5 and using
the lib32 ABI (or whatever it's called). I have no other
IRIX platform to check for how widespread the bug is.

>> This makes it work for me, the namespace is sadly polluted,
>> but there is nothing we can do about that, short of hacking
>> the gcc specs file or wait for gcc 3.5/4.0 to be released
>> as indicated by this bugzilla entry:
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15288
> 
> We should try to at least enable it for gcc >= 4.0, so Libtool won't
> need to change again then.  Plus, IRIX ld may have this fixed
> eventually; did anyone bother SGI folks about this?

I did a cursory search for gcc version tests in libtool.m4
in order to find some code to copy, but didn't find anything.
How would I go about testing the gcc version?

I don't know if SGI folks has been bothered.

> Just thinking out loud: this issue is not ABI-dependent, right?

Might be, but I don't know enough about IRIX to know how to
test though. If someone tells me how to do it, I can check.


>> 2005-03-09  Peter Ekberg  <spam.protected>
>> 
>>      * m4/libtool.m4 (_LT_LINKER_SHLIBS): Don't use the
>>      -exports_file linker option on irix with gcc, as
>>      the default gcc specs file includes a -hidden_symbol
>>      option that is clashing with the -exports_file option.
> 
> Thinking out loud again: adding the GCC bugzilla number to
> the ChangeLog
> entry would be beneficial.

Fair enough:

2005-03-09  Peter Ekberg  <spam.protected>

        * m4/libtool.m4 (_LT_LINKER_SHLIBS): Don't use the
        -exports_file linker option on irix with gcc, as
        the default gcc specs file includes a -hidden_symbol
        option that is clashing with the -exports_file option.
        See this gcc bugzilla entry for further details:
        http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15288

Cheers,
Peter