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...