GNU bug report logs - #63203
symbol lookup error: undefined symbol __libc_pthread_init (texmacs)

Previous Next

Full log

View this message in rfc822 format

From: Maxime Devos <maximedevos <at> telenet.be>
To: 63203 <at> debbugs.gnu.org, Josselin Poiret <dev <at> jpoiret.xyz>, Jonathan Brielmaier <jonathan.brielmaier <at> web.de>
Subject: bug#63203: symbol lookup error: undefined symbol __libc_pthread_init (texmacs)
Date: Sat, 13 May 2023 16:17:37 +0200

[Message part 1 (text/plain, inline)]

(I did not receive the last reply in my e-mail client.)

Hi,

There are no relevant environment variables in the main profile -- it's 
quite spartan:

~/.guix-profile/etc/profile:

# Source this file to [...]

export 
PATH="${GUIX_PROFILE:-/gnu/store/04i0m9rwnbw14qjhp2hnmm6gzbyirxn5-profile}/bin:${GUIX_PROFILE:-/gnu/store/04i0m9rwnbw14qjhp2hnmm6gzbyirxn5-profile}/sbin${PATH:+:}$PATH"
export 
LIBRARY_PATH="${GUIX_PROFILE:-/gnu/store/04i0m9rwnbw14qjhp2hnmm6gzbyirxn5-profile}/lib${LIBRARY_PATH:+:}$LIBRARY_PATH"
export 
CPLUS_INCLUDE_PATH="${GUIX_PROFILE:-/gnu/store/04i0m9rwnbw14qjhp2hnmm6gzbyirxn5-profile}/include/c++:${GUIX_PROFILE:-/gnu/store/04i0m9rwnbw14qjhp2hnmm6gzbyirxn5-profile}/include${CPLUS_INCLUDE_PATH:+:}$CPLUS_INCLUDE_PATH"
export 
C_INCLUDE_PATH="${GUIX_PROFILE:-/gnu/store/04i0m9rwnbw14qjhp2hnmm6gzbyirxn5-profile}/include${C_INCLUDE_PATH:+:}$C_INCLUDE_PATH"


However, GIO_EXTRA_MODULES is defined anyways:

GIO_EXTRA_MODULES=/gnu/store/8k9s3z2315p494fj937jyvc9v7gpbjr8-dconf-0.40.0/lib/gio/modules:/gnu/store/knm6b1dxg2j3vji4wrgngv99pvb6f5ff-glib-networking-2.70.0/lib/gio/modules:/gnu/store/8k9s3z2315p494fj937jyvc9v7gpbjr8-dconf-0.40.0/lib/gio/modules:/gnu/store/8k9s3z2315p494fj937jyvc9v7gpbjr8-dconf-0.40.0/lib/gio/modules:/run/current-system/profile/lib/gio/modules:/gnu/store/8k9s3z2315p494fj937jyvc9v7gpbjr8-dconf-0.40.0/lib/gio/modules

and it appears 4 times.  Several new problems (unrelated to the 
__libc_pthread_init thing) seem to appear here:

  * the same directory appears four times, which is three times too many
  * it doesn't use /run/current-system/profile/... file names, so a reboot
    may be necessary after reconfiguration (sometimes this is
    unavoidable, but in this case it appears avoidable).

The second thing also happens for XDG_DATA_DIRS, GTK_PATH, 
GDM_CUSTOM_CONF, GDM_DBUS_DAEMON, NM_VPN_PLUGIN_DIR and SHELL:

XDG_DATA_DIRS=/gnu/store/wa5jwl26n7l1h5asmns093xqbpkhqvwx-shared-mime-info-1.15/share:/gnu/store/ginkhx2irsi4qwkpnnwg4r30h7jwhi62-glib-2.70.2/share:/gnu/store/cp438dbpiy06fnfq1lrbd5nrzvhzjy2f-mate-desktop-1.24.1/share:/gnu/store/kq72g9hjl1sj4c1qhw98m8rdw2ymmk7m-gtk+-3.24.30/share:/gnu/store/ycgdcy3zh7symyrvl0xqj8skggl48chp-mate-terminal-1.24.1/share:/gnu/store/wa5jwl26n7l1h5asmns093xqbpkhqvwx-shared-mime-info-1.15/share:/gnu/store/ginkhx2irsi4qwkpnnwg4r30h7jwhi62-glib-2.70.2/share:/gnu/store/cp438dbpiy06fnfq1lrbd5nrzvhzjy2f-mate-desktop-1.24.1/share:/gnu/store/rwm63xxik66cjydcalg5sg5p7c6621w5-libmateweather-1.24.1/share:/gnu/store/kq72g9hjl1sj4c1qhw98m8rdw2ymmk7m-gtk+-3.24.30/share:/gnu/store/6p86xwpq1y9n5in3vaan94hykyddjx86-mate-panel-1.24.1/share:/gnu/store/wa5jwl26n7l1h5asmns093xqbpkhqvwx-shared-mime-info-1.15/share:/gnu/store/ginkhx2irsi4qwkpnnwg4r30h7jwhi62-glib-2.70.2/share:/gnu/store/cp438dbpiy06fnfq1lrbd5nrzvhzjy2f-mate-desktop-1.24.1/share:/gnu/store/kq72g9hjl1sj4c1qhw98m8rdw2ymmk7m-gtk+-3.24.30/share:/gnu/store/gr5adf2vjrf39i9khlkq6p15hfhk2q0w-mate-session-manager-1.24.1/share:/run/current-system/profile/share:/home/pode/.guix-profile/share:/run/current-system/profile/share
GTK_PATH=/gnu/store/kq72g9hjl1sj4c1qhw98m8rdw2ymmk7m-gtk+-3.24.30/lib/gtk-3.0:/gnu/store/fkl4fg06f538ryhiw4bs2iwwfs56g2k3-libcanberra-0.30/lib/gtk-3.0:/gnu/store/kq72g9hjl1sj4c1qhw98m8rdw2ymmk7m-gtk+-3.24.30/lib/gtk-3.0:/gnu/store/kq72g9hjl1sj4c1qhw98m8rdw2ymmk7m-gtk+-3.24.30/lib/gtk-3.0:/gnu/store/fkl4fg06f538ryhiw4bs2iwwfs56g2k3-libcanberra-0.30/lib/gtk-3.0:/gnu/store/kq72g9hjl1sj4c1qhw98m8rdw2ymmk7m-gtk+-3.24.30/lib/gtk-3.0
GDM_X_SESSION=/gnu/store/j653i1azcgyahi71pip4rz4ai0529ip2-xinitrc
GDM_CUSTOM_CONF=/gnu/store/i6mfrlxqndq9vxzpmp2qhhrrhsqahnn5-gdm-custom.conf
GDM_DBUS_DAEMON=/gnu/store/d8rf9brix7dh19kxdc819v6amf7icn1s-gdm-dbus-wrapper
NM_VPN_PLUGIN_DIR=/gnu/store/s4j534jy2y6y4b5xff5adgwijxcrgjdl-network-manager-vpn-plugins/lib/NetworkManager/VPN

(This is on a not-up-to-date Guix System, but likely at least some of 
these are still the case)
(Maybe the terminal application or login manager or something else
has an inappropriate wrap-program, or maybe the login manager itself 
loads /etc/profile and afterwards logs in as the user and loads 
/etc/profile again, without clearing environment variables first?)

(This is with gdm-service-type, mate-desktop-service-type and 
%desktop-services.)

> The solution would be to upgrade the profile which
> contains them, I believe (or run in a container shell).

Running it in a container shell (or simpler, running with
guix shell --pure) is a work-around, not a solution.

I guess that the relevant profile is the system profile.

According to the second paragraph at guix.gnu.org:

> [...] Guix supports [...], __unprivileged__ package management.

Upgrading the system profile is a privileged operation,
so having to upgrade the system profile to run texmacs
is not a solution.

I think a proper solution would be to make plugin path environment 
variables ABI-dependent, or more precisely, store-output-name dependent 
(as ABIs are not very practical to keep track of accurately).

Take, for example, the glib package, which currently has the
GIO_EXTRA_MODULES path.  This could be replaced by 
HASH_GIO_EXTRA_MODULES, where HASH is the HASH in 
/gnu/store/XXX-glib-2.72.3.

Then if the system profile is on YYY-glib-..., it would only set
the YYY_GIO_EXTRA_MODULES and then XXX-glib-... used by (user) TeXmacs 
will only
consider XXX_GIO_EXTRA_MODULES instead of the potentially incompatible 
YYY_GIO_....

(Would also be convenient for multi-arch systems, where the user might 
be on a different arch than the system).

(Even better would be if the system profile could contain plugins
for multiple versions, could be convenient on multi-user systems, and 
also on single-user systems for more smooth upgrades.)

Instead of store-output-name-dependent environment variables, an 
alternative method would be to make the location of the plugins 
store-output-name-dependent.

More concretely, keep the current name GIO_EXTRA_MODULES and the current
value of $GIO_EXTRA_MODULES, but put libdconfsettings.so into
/gnu/store/[...]-dconf-0.40.0/lib/gio/modules/HASH/libdconfsettings.so
instead of
/gnu/store/[...]-dconf-0.40.0/lib/gio/modules/libdconfsettings.so
and adjust gio to look in this new location.

(Would require less substitute*.)

(Possible implementation: patch gio to _also_ look in .../HASH/...
add a post-install phase that moves things into the HASH/ directory.
The ‘also’ instead of ‘instead‘ is intentional, in case the plugin
package has tests that set GIO_EXTRA_MODULES for testing.)

Greetings,
Maxime

[OpenPGP_0x49E3EE22191725EE.asc (application/pgp-keys, attachment)]

[OpenPGP_signature (application/pgp-signature, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.