[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#63203: symbol lookup error: undefined symbol __libc_pthread_init (te
From: |
Maxime Devos |
Subject: |
bug#63203: symbol lookup error: undefined symbol __libc_pthread_init (texmacs) |
Date: |
Sat, 13 May 2023 16:17:37 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.2 |
(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
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature