Zeuthen: Writing a C library, part 2

Posted Jun 28, 2011 22:14 UTC (Tue) by cmccabe (guest, #60281)
In reply to: Zeuthen: Writing a C library, part 2 by elanthis
Parent article: Zeuthen: Writing a C library, part 1

I guess I see your point.

I was about to write something here about symbol versioning being the solution to this problem, but... the more I read about it, the less helpful it seems.

Zeuthen: Writing a C library, part 2

Posted Jun 29, 2011 13:43 UTC (Wed) by mjthayer (guest, #39183) [Link] (6 responses)

> I was about to write something here about symbol versioning being the solution to this problem, but... the more I read about it, the less helpful it seems.

Does that include the simple form of versioning, as in prefixing every public symbol with a prefix like "mylib1_" or "mylib2_" for version 2? In that system new symbols can be added to a given version, but breaking the API/ABI contract on any given symbol is a bug which should be fixed with a minor release.

Zeuthen: Writing a C library, part 2

Posted Jun 29, 2011 16:31 UTC (Wed) by cmccabe (guest, #60281) [Link] (5 responses)

Manually versioning symbols is portable and should work fine. I was commenting that gcc's built-in symbol versioning seems complex and might not be the best solution.

Zeuthen: Writing a C library, part 2

Posted Jun 29, 2011 21:10 UTC (Wed) by hmh (subscriber, #3838) [Link] (4 responses)

Hmm, actually there is a rather simple rule: if your library could ever be used by something other than an application (i.e. by another library, by plugins, or worse, by glibc plugins or libraries that a libc plugin might use), version the symbols.

You don't need to go to the lengths that glibc does (which is to actually keep compatibility to earlier ABIs by providing differently versioned versions of the same symbol :p). What you have to do is really track ABI changes properly, change your SONAME every time the ABI changes in an incompatible way, and version every linker-visible symbol with the library name and soname. You could do better than that (like glibc does), but it is not strictly necessary in most cases.

The reason is the usual app A uses lib B and lib C, and lib B also uses lib C. App A was built against lib C ABI 1, lib B ABI 2. lib C got upgraded to abi 2, lib B got rebuilt against it, and now App A needs both lib C abi 1 and lib C abi 2 to be able to run -- instant meltdown.

This happens all the time, and it makes life HELL for distros. An extremely good example of a library that breaks the world rather easily when its symbols are not versioned is libdb.

And you will want to use the linker symbol versioning instead of static versioning, otherwise, you'd break the API all the time. BTW, it is not a gcc thing, it is an ELF thing, and Solaris has been doing it since forever.

I just wish it was easier to do symbol versioning.

Zeuthen: Writing a C library, part 2

Posted Jul 3, 2011 6:30 UTC (Sun) by cmccabe (guest, #60281) [Link] (3 responses)

> And you will want to use the linker symbol versioning instead of static
> versioning, otherwise, you'd break the API all the time. BTW, it is not a
> gcc thing, it is an ELF thing, and Solaris has been doing it since forever.

from http://www.airs.com/blog/archives/220

> Ulrich Drepper and Eric Youngdale introduced a much more sophisticated
> symbol versioning scheme, which is used by the glibc, the GNU linker, and
> gold. The key differences are that versions may be specified in object
> files and that shared libraries may contain multiple independent versions
> of the same symbol

In other words, this is a gcc-specific ELF extension. I wonder if LLVM supports it yet? I found a page from 2008 that said that LLVM didn't have support for this yet, but then I got tired of using the Google.

Zeuthen: Writing a C library, part 2

Posted Jul 3, 2011 9:39 UTC (Sun) by nix (subscriber, #2304) [Link]

Yes, its a Linuxism (and very much more useful than Solaris symbol versions), but a lot of the syntax of the file, and the underlying idea, was a Solarisism first.

Zeuthen: Writing a C library, part 2

Posted Jul 3, 2011 17:07 UTC (Sun) by paulj (subscriber, #341) [Link]

Symbol map files are supported by several proprietary Unix toolchains, including Suns' and (iirc) HPs'. The syntax is nearly identical twixt Solaris and GNU (there's certainly a useful common subset iirc). The ELF symbol stuff is at least very very similar in concept. It might even be standardised, and/or tools may know the differing formats. Binary compatibility across different OSes tends not to be the most important of issues though..

Zeuthen: Writing a C library, part 2

Posted Jul 6, 2011 15:54 UTC (Wed) by jwakely (subscriber, #60262) [Link]

> In other words, this is a gcc-specific ELF extension.

It's not gcc-specific, it's done by GNU binutils not gcc

http://sourceware.org/binutils/docs-2.21/as/Symver.html
http://sourceware.org/binutils/docs-2.21/ld/VERSION.html