Scintilla requires C++ threads which at least on GCC 8 Linux requires explicitly linking to libpthread.
This fixes building with `-Wl,-z,defs` linker flags on GCC 8.
---
This was under Debian Buster (10, fairly old I agree), it seems to work fine without on my usual machine on Bookworm (12). Is there a downside of linking pthreads? You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/3888
-- Commit Summary --
* Explicitly link to libpthread if available
-- File Changes --
M m4/geany-lib.m4 (4)
-- Patch Links --
https://github.com/geany/geany/pull/3888.patch https://github.com/geany/geany/pull/3888.diff
BTW: I can't really test Meson on that setup because Buster comes with a too old Meson and I didn't bother finding a way to get a new enough one there.
Possibly the olde libstdcxx does not properly support C++ threads? So even if you force it maybe it will crash and burn?
Well, at least with our use case (which might not actually use threads in Scintilla) it doesn't seem to cause any glaring issue.
Also note that the web seems riddled with old threads of people having similar issues.
Hmm, yes, Scintilla in Geany probably doesn't actually use threads, we don't `SCI_SETLAYOUTTHREADS` and we don't use the multithreaded loaders, so its probably safe if it just builds, even if it doesn't work :-)
So how does GTK/GIO/Glib do threads if pthreads isn't linked properly?
Maybe this should be limited to the dodgy versions of compiler/libstdc++ since most compilers seem to work as is.
Note that this (probably?) isn't needed without `-Wl,-z,defs`, as indeed GLib and others probably do link it anyway.
As for doing this only when needed, OK, but I have *no* idea what the conditions actually are.
Or you could just not use `-Wl,-z,defs` as part of `--b4n_pedantic` of course, so long as the final library works who cares if the object files have undefined symbols?
One thought, are you _sure_ its not an olde autotools linking stuff in the wrong order?
@elextr Scintilla in Geany probably doesn't actually use threads
It will still be declaring and possibly using mutexes which may require libpthread. Check that wrapping with short lines and higher caching levels (`SCI_SETLAYOUTCACHE` except for `SC_CACHE_NONE`) doesn't fail as the wrapping code locks without checking for threading.
@nyamatongwe Geany doesn't set `SCI_SETLAYOUTCACHE` so that makes it `SC_CACHE_CARET` IIUC so it is likely Scintilla would have used `libpthread`.
But then Scintilla doesn't use pthreads directly itself, it uses C++ `<mutex>`, although I suppose that might consist of macros over pthread calls making the linker think it does.
I doubt that `libpthread` isn't linked, either via G* or the C++ library, but the `-Wl,-z,defs` makes the linker complain about individual objects having undefined symbols not just the final product IIUC, the docs are brief. Its also not clear to me if that option makes `ld` complain when an object is linked, making it link order dependent. Also GCC docs specifies the use of `-pthread` on both compiler and linker, not explicitly linking `libpthread`, which is why I am concerned about forcing explicitly linking it for systems which work, how do we know it will not conflict with what `-pthread` does.
If Geany doesn't crash under the conditions above where it (via Scintilla) will probably successfully use libpthread then it seems to me that the issue is a false positive from a pedantic warning option that isn't an issue in real life, and as noted the warning doesn't happen on newer systems. As such doing something contrary to GCC docs advice to all builds seems overreach and risky to me.
I did more testing, and I still don't really understand what's happening. The closest info I have on this is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25460, but the `g++`call made by libtool still seem pretty much the same:
<details><summary><strong>Failing</strong> one on Buster:</summary>
`g++ -fPIC -DPIC -shared -nostdlib /usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/8/crtbeginS.o .libs/libgeany_la-about.o .libs/libgeany_la-build.o .libs/libgeany_la-callbacks.o .libs/libgeany_la-dialogs.o .libs/libgeany_la-document.o .libs/libgeany_la-editor.o .libs/libgeany_la-encodings.o .libs/libgeany_la-filetypes.o .libs/libgeany_la-geanyentryaction.o .libs/libgeany_la-geanymenubuttonaction.o .libs/libgeany_la-geanyobject.o .libs/libgeany_la-geanywraplabel.o .libs/libgeany_la-highlighting.o .libs/libgeany_la-keybindings.o .libs/libgeany_la-keyfile.o .libs/libgeany_la-log.o .libs/libgeany_la-libmain.o .libs/libgeany_la-msgwindow.o .libs/libgeany_la-navqueue.o .libs/libgeany_la-notebook.o .libs/libgeany_la-plugins.o .libs/libgeany_la-pluginutils.o .libs/libgeany_la-prefs.o .libs/libgeany_la-printing.o .libs/libgeany_la-project.o .libs/libgeany_la-sciwrappers.o .libs/libgeany_la-search.o .libs/libgeany_la-socket.o .libs/libgeany_la-spawn.o .libs/libgeany_la-stash.o .libs/libgeany_la-symbols.o .libs/libgeany_la-templates.o .libs/libgeany_la-toolbar.o .libs/libgeany_la-tools.o .libs/libgeany_la-sidebar.o .libs/libgeany_la-ui_utils.o .libs/libgeany_la-utils.o .libs/libgeany_la-vte.o -Wl,--whole-archive ../scintilla/.libs/liblexilla.a ../scintilla/.libs/libscintilla.a ./tagmanager/.libs/libtagmanager.a -Wl,--no-whole-archive -lgtk-3 -lgdk-3 -lpangocairo-1.0 -lpango-1.0 -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lglib-2.0 -L/usr/lib/gcc/x86_64-linux-gnu/8 -L/usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/8/../../../../lib -L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/8/../../.. -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/x86_64-linux-gnu/8/crtendS.o /usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu/crtn.o -O2 -Wl,--as-needed -Wl,-z -Wl,defs -pthread -pthread -pthread -Wl,-soname -Wl,libgeany.so.0 -o .libs/libgeany.so.0.0.0` </details>
<details><summary><strong>Working</strong> one Bullseye:</summary>
`g++ -fPIC -DPIC -shared -nostdlib /usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/12/crtbeginS.o .libs/libgeany_la-about.o .libs/libgeany_la-build.o .libs/libgeany_la-callbacks.o .libs/libgeany_la-dialogs.o .libs/libgeany_la-document.o .libs/libgeany_la-editor.o .libs/libgeany_la-encodings.o .libs/libgeany_la-filetypes.o .libs/libgeany_la-geanyentryaction.o .libs/libgeany_la-geanymenubuttonaction.o .libs/libgeany_la-geanyobject.o .libs/libgeany_la-geanywraplabel.o .libs/libgeany_la-highlighting.o .libs/libgeany_la-keybindings.o .libs/libgeany_la-keyfile.o .libs/libgeany_la-log.o .libs/libgeany_la-libmain.o .libs/libgeany_la-msgwindow.o .libs/libgeany_la-navqueue.o .libs/libgeany_la-notebook.o .libs/libgeany_la-plugins.o .libs/libgeany_la-pluginutils.o .libs/libgeany_la-prefs.o .libs/libgeany_la-printing.o .libs/libgeany_la-project.o .libs/libgeany_la-sciwrappers.o .libs/libgeany_la-search.o .libs/libgeany_la-socket.o .libs/libgeany_la-spawn.o .libs/libgeany_la-stash.o .libs/libgeany_la-symbols.o .libs/libgeany_la-templates.o .libs/libgeany_la-toolbar.o .libs/libgeany_la-tools.o .libs/libgeany_la-sidebar.o .libs/libgeany_la-ui_utils.o .libs/libgeany_la-utils.o .libs/libgeany_la-vte.o -Wl,--whole-archive ../scintilla/.libs/liblexilla.a ../scintilla/.libs/libscintilla.a ./tagmanager/.libs/libtagmanager.a -Wl,--no-whole-archive -lgtk-3 -lgdk-3 -lz -lpangocairo-1.0 -lpango-1.0 -lharfbuzz -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lglib-2.0 -L/usr/lib/gcc/x86_64-linux-gnu/12 -L/usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/12/../../../../lib -L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/12/../../.. -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/x86_64-linux-gnu/12/crtendS.o /usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/crtn.o -O2 -Wl,--as-needed -Wl,-z -Wl,defs -pthread -Wl,-soname -Wl,libgeany.so.0 -o .libs/libgeany.so.0.0.0` </details>
To reproduce a test program, you need to build a shared library using C++ threads with libtool. In this case, you'll get the `-nostdlib` and friends, and get a link failure unless you pass in `-lpthread` on my GCC8. This is regardless of the Libtool version it seems (well, 2.4.6 and 2.4.7). I made such a sample test program: https://github.com/b4n/ltcxxthread
---
Insight I'm taking from this: * this only happens with shared libraries (otherwise libtool doesn't play with `-nostdlib` and it seems to work) * because of this, it's tricky to test at configure time whether a workaround is needed or not * seems to either be a libtool or gcc bug (but it *seems* like it's fixed by a newer GCC, not a newer libtool -- or it could be a change in the used threading or stdlib implementations?)
In the end, I don't know if this here is OK or not. FWIW, the sample program does *not* seem to link to libpthread, yet it works. If I add `-lpthread` it then does link to it -- obviously. However, Geany links to libpthread anyway through GLib -- at least on GNU/Linux.
If Geany doesn't crash under the conditions above where it (via Scintilla) will probably successfully use libpthread
As said above, it doesn't even seem to be required (according to `ldd`)… so either gcc comes with a copy in libgcc or something, or it's implicit at some stage.
then it seems to me that the issue is a false positive from a pedantic warning option
`-Wl,-z,defs` isn't really a waning option, but rather a utility to verify you don't end up with unresolved symbols when actually loading the library. Here though, it seems to be some kind of a false positive indeed.
false positive […] that isn't an issue in real life
Yeah, it doesn't seem to have any adverse effect. Yet again, we *do* implicitly link to libpthread, and even so the dependency doesn't actually seem to be needed.
Hmm, trying to compare your two link commands the only real difference is that `harfbuzz` is explicitly listed instead (presumably) of being included by pango, and an additional `-lz`, whatever that is.
Yet again, we do implicitly link to libpthread
Well, not so implicitly since the command has `-pthread` on it. The GCC docs for that starts "Link with the POSIX threads library." so I would say it is explicitly linked.
github-comments@lists.geany.org