GNOME Bugzilla – Bug 595176
Private symbols are exported in the shared libraries
Last modified: 2012-11-06 14:00:00 UTC
Hi, I've noticed that symbols that are not meant to be public (e.g. soup_connection_*) are exported in the shared libraries: emilio@saturno:~$ nm -D /usr/lib/libsoup-2.4.so.1.3.0 | grep soup_connection 0001a480 T soup_connection_connect_async 0001a2b0 T soup_connection_connect_sync 00019e40 T soup_connection_disconnect 00019d20 T soup_connection_get_proxy_uri 00019db0 T soup_connection_get_socket 00019c40 T soup_connection_get_state 0001a220 T soup_connection_get_tunnel_addr 00019950 T soup_connection_get_type 0001a6d0 T soup_connection_new 00019a00 T soup_connection_send_request 0001a0b0 T soup_connection_set_state 0001a170 T soup_connection_start_ssl Since these are not meant to be part of the public API (and they get changed/removed as needed without changing the SONAME), I think they shouldn't be exported in the shared library. I'm not sure what's the best option to fix this, but if someone has a suggestion I'm happy to cook a patch.
you can write a file to tell libtool what symbols to export, but i've never felt like bothering; if apps are going to go out of their way to depend on symbols that aren't mentioned in header files, then they're pretty much trying to lose. i'd take a patch if you provided one though. (though not for 2.28; i don't want to accidentally miss a symbol and break some app at the last minute)
Created attachment 147664 [details] [review] Use libtools' -export-symbols-regex to filter the exported symbols I've given this a try using -export-symbols-regex as we talked on IRC some time ago. This patch makes libsoup not export _* symbols (except for _SOUP* that are already meant to be public), so we can use _soup_* as the private namespace (like gtk and glib do).
Created attachment 147665 [details] [review] Make SoupConnection's symbols private This makes SoupConnection's symbols private by moving them to the _soup_* namespace. If this looks fine I'll proceed with the rest of the private symbols. I've given this a little testing with Liferea and seems to work fine.
meh. looking at the second patch, i really don't like having to explicitly rename all the non-exported functions. so if we were going to do this, I'd rather have a libsoup.symbols file and use --export-symbols, and leave everything named the way it is now
(In reply to comment #4) > meh. looking at the second patch, i really don't like having to explicitly > rename all the non-exported functions. > > so if we were going to do this, I'd rather have a libsoup.symbols file and use > --export-symbols, and leave everything named the way it is now That's easiest in the short term but it would be a burden to maintain in the long term, wouldn't it?
I'd recommend Emilio's patch. This is the method that's commonly used in other libraries and works well.
Finally fixed in git (via an explicit symbols file). I was going to do the -export-symbols-regex thing, but I realized this would be annoying because there are several classes in libsoup that are currently private but which we're expecting to make public later, and I don't want to have to rename everything when that happens. So I went with the explicit symbols file.
The gvfs build was broken by this commit. http://git.gnome.org/browse/gvfs/tree/daemon/soup-input-stream.c?id=9ebfe661e864d8d0dda41926dc57dcebb9634184#n838
See https://bugzilla.gnome.org/show_bug.cgi?id=687757 for the gvfs fallout.