> There's a thread on gcrypt-devel that is directly
> relevant to POPT library "compatibility" and symbol handling:
> (You will get a "403 Forbidden" for the gcrypt-devel archives,
> go find a mirror)
> And for reference, there's Drepper's deep dark chocolate DSO
> guidance here:
> And gcrypt-devel is unrelated to generating 64bit RSA keypairs using a
> RPN calculator in POPT. ;-)
> There are (at least) two approaches to adding symbol versioning
> and visibility to a DSO library.
> 1) use a loader map
> already implemented in POPT, just "opt-in" and so
> never used.
> 2) use GCC __attribute__(("visibility")) voo-doo
> Using __attribute__ can be used to do "opt-out" symbol hiding
> without the modest overhead of loader maps.
> The other (and different) issue is symbol versioning. The connection
> to "visibility" is largely because a loader map can also be used
> to add symbol versions quite easily.
> There's also the distantly related/coupled issue (if I choose to
> add ELF symbols to the RPN calculator) of using
> dlsym() # in POSIX and should be "portable"
> dlvsym() # GNU extensions necessary with
> versioned symbol lookup
> I can/will chase down a "straw-man" implementation using loader maps
> and versioned symbols for "compatibility" over the next month
> because I _REALLY_ think renaming to "popt2" is just wussiness.
fwiw, I've found more than one instance of projects getting symbol
versioning religion, just adding it, and creating considerable confusion.
if libfoo 1.14 is unversioned and 1.15 suddenly is versioned then you
may get surprises. it's not an utter disaster to do both: bump to
2.0 and use all the versioning tricks from there.
disclaimer: I haven't looked at what issues you may be facing,
going to 2.0 may indeed be as you characterize it :)
Received on Sun Jun 20 15:19:34 2010