3

I have a C program to plot a simple Gaussian distribution. However, whenever I call the program I get this error:

gnuplot: symbol lookup error: /snap/core20/current/lib/x86_64-linux-gnu/libpthread.so.0: undefined symbol: __libc_pthread_init, version GLIBC_PRIVATE

kos
  • 41,378
Volker Tachin
  • 31
  • Sounds like something you should ask the people that made this app. – David DE Apr 05 '23 at 16:25
  • Are you using Ubuntu Core, or a regular Ubuntu with a snap version of gnuplot? Are you calling the gnuplot executable from your code, or using the C/C++ API? The error message suggests that the versions of libpthread and libc are incompatible. – steeldriver Apr 05 '23 at 21:35
  • @steeldriver I am using a regular ubuntu (22.04). The executable is run from my code. On its own, gnuplot works fine – Volker Tachin Apr 06 '23 at 17:27
  • 1
    I get this error when plotting from gnuplot from a vscode terminal (Ubuntu 24.04). This happens to me at the point of plotting (e.g., plot x) with gnuplot-qt and with gnuplot-x11. I bet there is a problem with Snap. – alfC Oct 09 '24 at 15:08
  • I found a possible solution here: https://github.com/ros2/ros2/issues/1406 $ unset GTK_PATH (I don't know why it works or why the variable is set in the first place). – alfC Oct 09 '24 at 15:15
  • 1
    @alfC I laid the answer down a bit better (hopefully) and added a few more details to it as well if you're interested – kos Oct 12 '24 at 05:29
  • @kos. Yes, my answer was converted to a comment (not by me). I awarded the bounty, thanks. I can’t accept the answer, the OP can. – alfC Oct 12 '24 at 05:35
  • 1
    @alfC Ah no I know, don't worry, and thanks for the bounty, but I thought since you were looking for a detailed explanation maybe you wanted to read it again because of the additions, that's why I pinged you (I also worded it better, I was wrongfully implying there's no other way to go about it other than changing the environment, which is not true) – kos Oct 12 '24 at 05:39
  • @alfC By the way if you want to expand your answer a little bit and post it again (even borrowing from my answer) let me know and I'll upvote it. A shorter answer is needed here since I don't expect people that are getting this issue (and that just want the thing fixed) to go through my rambling about the thing, a straightforward unset GTK_PATH is needed here I think. If you do that let me know and I'll upvote your answer – kos Oct 12 '24 at 05:54

1 Answers1

1

In short: as long as the application running gnuplot is setting GTK_PATH in its environment, since gnuplot will try and hook into GTK libraries (due to wtx, which relies on wxGTK - the first call as reported by strace being to libwx_gtk3u_core-3.2.so.0 - which relies on GTK), the most straightforward way to go about preventing this from happening is to set the environment in which gnuplot is running in such a way that the misbehaving library is not hooked into.

Changing the environment in which gnuplot is running can be done in may ways, for example:

  1. By having the application running gnuplot export a different GTK_PATH, or not export a GTK_PATH at all;
  2. If gnuplot is run in a shell-like environment, by explicitly setting the environement for gnuplot (for example by unsetting GTK_PATH or by setting LD_PRELOAD to a path to a version of the library that won't misbehave)

See the solutions proposed at the end.

Quoting the definition of GTK_PATH in Running GTK Applications, from the GTK documentation (emphasys mine):

Specifies a list of directories to search when GTK is looking for dynamically loaded objects such as the modules specified by GTK_MODULES, theme engines, input method modules, file system backends and print backends.

If the path to the dynamically loaded object is given as an absolute path name, then GTK loads it directly. Otherwise, GTK goes in turn through the directories in GTK_PATH, followed by the directory .gtk-3.0 in the user’s home directory, followed by the system default directory, which is libdir/gtk-3.0/modules.

When GTK_PATH is set, any dynamically loaded object contained in a directory listed in GTK_PATH will take precedence over the same dynamically loaded object contained in ~/.gtk-3.0 and /lib/x86_64-linux-gnu/gtk-3.0.

Which in turn means: if the version of the library found while traversing GTK_PATH is misbehaving, the issue will show up; If GTK_PATH is unset and the first found version of the library in ~/.gtk-3.0 or /lib/x86_64-linux-gnu/gtk-3.0 is not misbehaving, the issue won't show up.

Which explains why unset GTK_PATH works; it's basically making the application dodge the misbehaving version of the library.

In your case, the misbehaving version of the library is the one found in /snap/core20/current/lib/x86_64-linux-gnu.

Many people seem to experience this kind of issue with applications running in VSCode's integrated terminal.

If you're using VSCode (but in principle this applies to any application), you have the following solutions:

  1. Updating the application; in case of VSCode: sudo snap refresh code
  2. If you're in a channel other than stable (edge / beta / candidate), switching to the stable channel; in case of VSCode sudo snap refresh code --channel=stable

If that doesn't work, if gnuplot is running in a shell environment (such as in the case of VSCode's integrated terminal), another way would be to unset GTK_PATH in the shell environment:

unset GTK_PATH

Or to unset GTK_PATH just for the execution of gnuplot:

GTK_PATH= gnuplot [...]

Or to set LD_PRELOAD to a path to a version of the library that won't misbehave:

LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libpthread.so.0 gnuplot [...]

In the case of VSCode's integrated terminal specifically, you could also unset GTK_PATH for the integrated terminal by adding this to settings.json:

"terminal.integrated.env.linux": {
    "GTK_PATH": null,
},
kos
  • 41,378