RE: IRIX 6.5 and exporting symbols.

[Peter Ekberg]

Albert Chin wrote:
> On Wed, Mar 09, 2005 at 02:51:31PM +0100, Ralf Wildenhues wrote:
>> * Peter Ekberg wrote on Wed, Mar 09, 2005 at 02:11:40PM CET:
>>> 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?
> 
> We have an SGI support contract. I'll bug them if you want but you
> need to tell me what to put in the bug report. ld(1) says:
>      -hidden_symbol symbol_list
>                Used in conjunction with the -shared or -call_shared
>                options.  Marks the specified symbols as hidden.  Use a
>                comma to separate the symbols.  This option is ignored
if
>                any symbols are specifically marked as exported using
the
>                -exported_symbol or -exports_file options.  If you
specify
>                -hidden_symbol, all unspecified symbols are
>                automatically exported, including those that were
implicitly 
>                hidden when loading archive libraries.
> 
>                It is an error if any of these symbols are also
specifically
>                marked as hidden using the -exported_symbol or
>                -exports_file options.
> 
>                See the NOTES section information regarding hiding and
>                exporting defined symbols.  (C, C++, F77, F90)
> 
> If any of this is wrong, let me know what I should tell SGI.

Hmm, my oldish ld(1) (marked 4-7-99) is not explicit in terms
of it being an error to specify both -hidden_symbol and at
the same time specify -exported_symbol or -exports_file for
some other symbol(s). But that is indeed the case. If SGI have
updated ld(1), I guess they are not going to change the
behaviour, so barking up their tree is probably fruitless.

Cheers,
Peter