I was wondering if people were interested in getting ELF visibility support into libdvdnav. The idea of using ELF visibility is that internal non-static functions can be hidden from the ELF, not exporting them anymore to the users of the library. It's an ABI change (so the soname should be changed), but then it allows you to change the ABI of the internal functions without being concerned if that might break frontends using internal symbols. Hidden visibility also makes the library load faster and work faster too (as the symbols don't need to be resolved at runtime), and avoids interposing (symbols' collision). And as an extra, you won't get symbol collisions between libdvdnav and libdvdread when libdvdnav is built with the internal copy of libdvdread (because the libdvdread-provided symbols wouldn't be exported). If you want, I can prepare a patch to add tests and headers for hidden visibility. -- Diego "Flameeyes" Pettenò http://farragut.flameeyes.is-a-geek.org/
Il Tuesday 08 January 2008 12:55:13 Diego 'Flameeyes' Pettenò ha scritto:
I was wondering if people were interested in getting ELF visibility support into libdvdnav. The idea of using ELF visibility is that internal non-static functions can be hidden from the ELF, not exporting them anymore to the users of the library. It's an ABI change (so the soname should be changed), but then it allows you to change the ABI of the internal functions without being concerned if that might break frontends using internal symbols.
Hidden visibility also makes the library load faster and work faster too (as the symbols don't need to be resolved at runtime), and avoids interposing (symbols' collision).
And as an extra, you won't get symbol collisions between libdvdnav and libdvdread when libdvdnav is built with the internal copy of libdvdread (because the libdvdread-provided symbols wouldn't be exported).
If you want, I can prepare a patch to add tests and headers for hidden visibility.
post a patch, please
participants (2)
-
flameeyes@gmail.com -
Nico Sabbi