https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102426
--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot
Uni-Bielefeld.DE> ---
> --- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> (In reply to r...@cebitec.uni-bielefeld.de from comment #8)
>> > --- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
>> > So, shouldn't we instead of the -export-symbols-regex use a version script?
>>
>> We certainly could, but IIUC this would lose the functionality on
>> non-ELF targets that do support -export-symbols-regex in a different
>> way. No idea if this is deemed acceptable...
>
> The world doesn't end if other symbols are exported, it worked that way for
> years.
True ;-)
> Perhaps we could test in configure whether -export-symbols-regex works and
> only
> use a fallback if it doesn't? Or decide it based on target triplet,
> do those GNU and SUN version script checks and if neither of them works, fall
> back to -export-symbols-regex ?
I wouldn't check triplets, but instead do the symbol versioning check
and, if that fails, use -export-symbols-regex.
> gld supports version scripts like:
> { global: onload; local: *; };
> which makes onload a non-versioned GLOBAL symbol while everything else LOCAL,
> does Sun ld support that too or similar?
That's exactly the Sun ld syntax. After all, they came up with that
before gld adopted it...
