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,268
Volker Tachin
  • 31
  • 2

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,268