After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 707298 - libgobject should be linked with -Wl,-z,nodelete
libgobject should be linked with -Wl,-z,nodelete
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: gobject
2.37.x
Other Linux
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2013-09-02 18:13 UTC by Alexandre Rostovtsev
Modified: 2014-04-10 06:02 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
proposed patch (2.14 KB, patch)
2013-09-02 18:14 UTC, Alexandre Rostovtsev 		none Details | Review
proposed patch, v2 (2.70 KB, patch)
2013-10-01 15:27 UTC, Alexandre Rostovtsev 		accepted-commit_now Details | Review

Description Alexandre Rostovtsev 2013-09-02 18:13:06 UTC 
See https://bugzilla.gnome.org/show_bug.cgi?id=705535#c4 :

> we haven't supported unloading libgobject for a *long* while. the type system
> itself does not support reloading its data, and code assumes that types  will
> survive for the entire duration of the process life time.

Since some non-Gnome-ecosystem applications like vlc do currently attempt to unload libgobject (because the main executable doesn't link to libgobject, but some of its plugins do indirectly link to it) and therefore segfault when using glib-2.36 or newer, we should try building libgobject with the -z,nodelete flag if available, indicating that the library, once loaded, should not be unloaded at runtime.
Comment 1 Alexandre Rostovtsev 2013-09-02 18:14:18 UTC 
Created attachment 253875 [details] [review]
proposed patch
Comment 2 Allison Karlitskaya (desrt) 2013-10-01 08:43:10 UTC 
The config check for this option is less than awesome.  I modified it, introducing a typo, to test if it is working properly, and it's not.

The log says this:

/usr/bin/ld: warning: -z nodelet ignored.

but the check comes back positive...


I guess in a sense, that's sort of successful -- the build didn't fail.  Would be nice if we could find a better check, though.
Comment 3 Alexandre Rostovtsev 2013-10-01 14:00:35 UTC 
I copied the same check that glib's configure already uses to check for -Wl,-Bsymbolic-functions when setting GLIB_LINK_FLAGS.

If it doesn't work, it ought to be fixed there too.
Comment 4 Allison Karlitskaya (desrt) 2013-10-01 14:36:31 UTC 
The difference between the two checks is that ld ignores unknown -z flags, but doesn't ignore completely unknown flags (like if -Bsymbolic-functions) did not exist.

compare:

[desrt@moonpix src]$ ld -z nodele
ld: warning: -z nodele ignored.

[desrt@moonpix src]$ ld -Bsymbolic-foo
ld: unrecognized option '-Bsymbolic-foo'
ld: use the --help option for usage information


This is maybe slightly academic because we're testing the behaviour of a version of ld that already accepts -z nodelete (and others that don't know this flag very well may error out entirely), but I'd still feel better if we had a check that actually failed on unknown flags instead of proceeding as if they were supported.
Comment 5 Alexandre Rostovtsev 2013-10-01 15:27:43 UTC 
Created attachment 256196 [details] [review]
proposed patch, v2

OK, second try: check for -Wl,-z,nodelete using -Wl,--fatal-warnings.

Of course, there is no way to know whether random non-gnu linkers will have the --fatal-warnings option, but at least this should detect any gnu ld.bfd releases that for whatever reason do not support -z nodelete.
Comment 6 Allison Karlitskaya (desrt) 2014-04-09 14:21:48 UTC 
Review of attachment 256196 [details] [review]:

Thanks for the patch.  Please commit.