[Theora-dev] linking, exported symbols

Michael Smith mlrsmith at gmail.com
Wed Aug 3 06:45:47 PDT 2005

> I reckon we should:
> 1) namespace all exported symbols. There are platforms where
> fiddling with the linker is not possible. So, for example,
> rename the internal function quantize() to theora_quantize()
> throughout. Don't mess around with linker maps, just rename
> the symbols.

Well, my point (or one of them) was that quantize() really shouldn't
be an exported symbol AT ALL. But I don't know enough about the
details of ELF linking to know what to call what we actually want
(i.e. visible internally to the rest of the library, but not

> 2) explicitly export API symbols. On Linux and Solaris, this can
> be done with a version script file which lists only the symbols to
> be exported, which for libtheora is fairly small. For an example
> see in liboggz how SHLIB_VERSION_ARG is handled in configure.ac,
> using src/liboggz/Version_script{.in}. On win32 it's normally done
> with a .def file, as in vorbis/win32/*.def (Mike, I expect you know
> this already, I'm just writing it out for completeness :-).

Thomas tells me we can use some regexp-based linker switch for at
least Linux - Thomas, what were the details? I'm not sure exactly what
that does.

The liboggz-style approach looks ok too - want to implement for
libtheora? I'm going to guess we have a similar problem with
libvorbis, though I haven't checked - I don't think we have any linker
magic there.

> Although there is a slight maintenance overhead in maintaining
> these files, this is only a problem if people are adding API calls
> willy-nilly, which of course isn't happening here anyway. An extra
> advantage of explicitly naming which symbols to export is that it
> disallows use of internal functions by applications. And with
> coverage testing, the code wouldn't even pass make check if the
> export files were incorrect ...

That's true. If we wanted to be tricky, we could auto-generate them by
parsing the public API headers, because anything in there we want to
export, and anything not we don't...


More information about the Theora-dev mailing list