Re: LIBRARY_PATH and foreign binaries: error while loading shared libraries

[Pierre Neidhardt]

Ricardo Wurmus  writes:

> The best way is to build the software from source.  Short of that you
> can load individual libraries with LD_PRELOAD.  The most coarse-grain
> solution is to use LD_LIBRARY_PATH.

Where is LD_PRELOAD documented?
I could find it mentioned in (8)ld.so.

-- 
Pierre Neidhardt

Perilous to all of us are the devices of an art deeper than we ourselves
possess.
-- Gandalf the Grey [J.R.R. Tolkien, "Lord of the Rings"]


signature.asc
Description: PGP signature

Re: LIBRARY_PATH and foreign binaries: error while loading shared libraries

[Pierre Neidhardt]

Thank you Ricardo for those clarifications.

-- 
Pierre Neidhardt


signature.asc
Description: PGP signature

Re: Could not find bootstrap binary 'guile-2.0.9.tar.xz'

[Joshua Branson]

I guess I'm still a little confused. Suppose that I want to update all
packages, on my system.  The ones owned by root, and the ones owned by
all other users.  Then I'd do this?

$ guix pull && guix package -u

$ logout

$ login DifferentUser

$ guix pull && guix package -u

 ...repeat for all other users...

$ su

# guix pull && guix package -u && guix system reconfigure /etc/config.scm

Does that look right?

Mark H Weaver  writes:

> Hi Joshua,
>
> Joshua Branson  writes:
>> Maybe I'm being really silly, but don't you just do a guix pull as a
>> root user not as a normal user?
>
> No.  Guix is not like most distros where you have to be root to update
> the package list, and where root's package list is used by all other
> users.
>
> In the Guix model, each user has their own version of Guix and its
> package list.  When a user runs "guix pull", it only updates Guix for
> that particular user, by changing the symlink ~/.config/guix/latest.
>
> If root runs "guix pull", it only updates the package list for root, by
> changing the symlink ~root/.config/guix/latest.
>
> Regards,
>   Mark

Re: Could not find bootstrap binary 'guile-2.0.9.tar.xz'

[Clément Lassieur]

Mark H Weaver  writes:

> Hi Joshua,
>
> Joshua Branson  writes:
>> Maybe I'm being really silly, but don't you just do a guix pull as a
>> root user not as a normal user?
>
> No.  Guix is not like most distros where you have to be root to update
> the package list, and where root's package list is used by all other
> users.

Well, if guix-daemon points to root's profile (as it should if you
followed the documentation), you would need to do a guix pull as root in
order to update it.  I've no idea if it'll solve the problem though.

> In the Guix model, each user has their own version of Guix and its
> package list.  When a user runs "guix pull", it only updates Guix for
> that particular user, by changing the symlink ~/.config/guix/latest.
>
> If root runs "guix pull", it only updates the package list for root, by
> changing the symlink ~root/.config/guix/latest.
>
> Regards,
>   Mark

Re: LIBRARY_PATH and foreign binaries: error while loading shared libraries

[Ricardo Wurmus]

Hi Pierre,

>> /path/to/foreign/binary
> /path/to/foreign/binary: No such file or directory
>
> This is because the path to the linker is wrong:
>
>> file /path/to/foreign/binary
> /path/to/foreign/binary: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), 
> dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 
> 2.6.24, BuildID[sha1]=edf4cff78e6710ff4f7ac14cb99b38aefed2659e, stripped
>
> I can fix it with
>
>> patchelf --set-interpreter "$(realpath "$(which sh)")" 
>> /path/to/foreign/binary
>
> (Is this the commended way?)

It is one way that ensures that the correct linker is used.  Another way
is to install the glibc’s dynamic linker in the expected location at
/lib64/ld-linux-x86-64.so.2.

> The "missing" libraries are indeed in my ~/.guix-profile/lib.  This
> folder is properly referenced in the environment:
>
>> env | grep LIBRARY_PATH
> LIBRARY_PATH=/home/ambrevar/.guix-profile/lib

> My understanding is that the LIBRARY_PATH is only used for compiling,

Correct.  It is respected by the linker.

> not at runtime.  But then how come some libraries are found and not
> others?

That’s probably because the libraries it found end up there because of
patching the interpreter.

> If I export LD_LIBRARY_PATH to the value of LIBRARY_PATH, then it works:
>
>> export LD_LIBRARY_PATH=$LIBRARY_PATH
>> /path/to/foreign/binary
>
> Is there a better way?

The best way is to build the software from source.  Short of that you
can load individual libraries with LD_PRELOAD.  The most coarse-grain
solution is to use LD_LIBRARY_PATH.

--
Ricardo

Re: Could not find bootstrap binary 'guile-2.0.9.tar.xz'

[Mark H Weaver]

Hi Joshua,

Joshua Branson  writes:
> Maybe I'm being really silly, but don't you just do a guix pull as a
> root user not as a normal user?

No.  Guix is not like most distros where you have to be root to update
the package list, and where root's package list is used by all other
users.

In the Guix model, each user has their own version of Guix and its
package list.  When a user runs "guix pull", it only updates Guix for
that particular user, by changing the symlink ~/.config/guix/latest.

If root runs "guix pull", it only updates the package list for root, by
changing the symlink ~root/.config/guix/latest.

Regards,
  Mark

Re: Emacs in multiple profiles

[myglc2]

On 03/27/2018 at 18:38 Alex Kost writes:

> Konrad Hinsen (2018-03-26 10:24 +0200) wrote:
>
>> Alex Kost  writes:
>>
>>> But what your "current profile" is?  How can emacs know about it?  It
>>> "knows" only about the default (system and user) profiles.  So if you
>>
>> I'd say Emacs knows nothing at all about profiles. It's Guix that
>> manages profiles for everyone else, be it bash, Python, or Emacs. To get
>> the behavior that I expected, Guix would have to define and manage an
>> environment variable, let's call it EMACS_PATH, which would be used in
>> site-start.el.
>>
>> What I cannot judge is how much effort it would be to implement such a
>> feature, and if it could have undesirable side-effects.
>
> As for me, I think the current behaviour (looking for packages only in
> the user and the system profiles) is the right one.  If you want to
> auto-load emacs packages from some non-standard profiles, you can easily
> do this on your own (as I showed in the previous message).
>
> Anyway, if you think that some feature is missing, I would recommend to
> send a message to  about it.  Perhaps other people
> will agree with your point.

Hi Konrad & Alex,

I am revamping my emacs config approach and I came across your
discussion. Following Alex's suggestions I found 2 approaches that seem
to do what Konrad wanted ...

1) guix profile approach ...

guix package -m emacs.scm
emacs --no-init-file \
  --eval="\
(let ((guix-env (getenv \"GUIX_ENVIRONMENT\")))
  (when (and guix-env
 (require 'guix-emacs nil t))
(guix-emacs-autoload-packages guix-env)))" \
  --load=".emacs.d/init0.el"
guix package --roll-back

2) guix environment approach ...

guix environment --ad-hoc emacs magit -- \
emacs --no-init-file --no-site-file \
  --eval="\
(let ((guix-env (getenv \"GUIX_ENVIRONMENT\")))
  (when (and guix-env
 (require 'guix-emacs nil t))
(guix-emacs-autoload-packages guix-env)))" \
  --load=".emacs.d/init0.el"

For my purposes 2) is better -- It starts more quickly and doesn't
"infect" other login sessions. It also allows multiple, different,
isolated Emacs environments to run simultaneously. Sweet ;-)

- George



emacs.scm
Description: Binary data


init0.el
Description: application/emacs-lisp

Re: Missing glibc man pages?

[Pierre Neidhardt]

Alex Kost  writes:

>> I've installed the `glibc` package in my user profile, but I cannot find
>> the man pages of `ldd`, `ldconfig`, etc.  Is it an oversight?
>
> They are placed in 'man-pages' package.

Indeed, thanks for pointing that out!

-- 
Pierre Neidhardt

HUGH BEAUMONT died in 1982!!


signature.asc
Description: PGP signature

Re: pcspkr only loaded after waking up from sleep

[Pierre Neidhardt]

Alex Kost  writes:

>>   (kernel-arguments '("modprobe.blacklist=pcspkr"))
>
> Yes, it is.  I recall I also needed to blacklist "snd_pcsp" module to get
> rid of this annoying beep (so I have "modprobe.blacklist=pcspkr,snd_pcsp");
> although it was several years ago, maybe it is not necessary anymore.

Thanks!  Any idea why the module does not load properly at boot time?

-- 
Pierre Neidhardt

The world will end in 5 minutes.  Please log out.


signature.asc
Description: PGP signature

Re: pcspkr only loaded after waking up from sleep

[Alex Kost]

Pierre Neidhardt (2018-04-18 14:00 +0530) wrote:

> Anyways, I'd like to turn it off for good.  Is the following the right
> way to go?
>
>   (kernel-arguments '("modprobe.blacklist=pcspkr"))

Yes, it is.  I recall I also needed to blacklist "snd_pcsp" module to get
rid of this annoying beep (so I have "modprobe.blacklist=pcspkr,snd_pcsp");
although it was several years ago, maybe it is not necessary anymore.

-- 
Alex

Re: Missing glibc man pages?

[Alex Kost]

Pierre Neidhardt (2018-04-18 12:00 +0530) wrote:

> I've installed the `glibc` package in my user profile, but I cannot find
> the man pages of `ldd`, `ldconfig`, etc.  Is it an oversight?

They are placed in 'man-pages' package.

-- 
Alex

Re: LIBRARY_PATH and foreign binaries: error while loading shared libraries

[Pierre Neidhardt]

Pierre Neidhardt  writes:

> I can fix it with
>
>> patchelf --set-interpreter "$(realpath "$(which sh)")" 
>> /path/to/foreign/binary

Copy/paste mistake, the correct command is

> patchelf --set-interpreter "$(patchelf --print-interpreter "$(realpath 
> "$(which sh)")")" /path/to/foreign/binary

-- 
Pierre Neidhardt



signature.asc
Description: PGP signature

pcspkr only loaded after waking up from sleep

[Pierre Neidhardt]

My laptop only rings the error bell (the PC speaker) after waking up
from sleep.  It does not after a fresh boot.  Or maybe the issue happens
at random.

It seems that pcspkr fails to register properly on boot:

--8<---cut here---start->8---
> dmesg | grep pcspkr
[2.109740] input: PC Speaker as /devices/platform/pcspkr/input/input5
[2.127371] Error: Driver 'pcspkr' is already registered, aborting...
[2.281487] Error: Driver 'pcspkr' is already registered, aborting...
...
[19213.561915] Modules linked in: msr [...] pcspkr [...]
--8<---cut here---end--->8---

19213 is after waking up from sleep, the modules get re-linked I
suppose.  It works from then on.

Anyways, I'd like to turn it off for good.  Is the following the right
way to go?

  (kernel-arguments '("modprobe.blacklist=pcspkr"))

--
Pierre Neidhardt

Anti-trust laws should be approached with exactly that attitude.


signature.asc
Description: PGP signature

Missing glibc man pages?

[Pierre Neidhardt]

I've installed the `glibc` package in my user profile, but I cannot find
the man pages of `ldd`, `ldconfig`, etc.  Is it an oversight?

--
Pierre Neidhardt


signature.asc
Description: PGP signature

LIBRARY_PATH and foreign binaries: error while loading shared libraries

[Pierre Neidhardt]

I want to run some binaries which were not compiled on GuixSD
(e.g. games from Humble Bundle).

Two issues:

> /path/to/foreign/binary
/path/to/foreign/binary: No such file or directory

This is because the path to the linker is wrong:

> file /path/to/foreign/binary
/path/to/foreign/binary: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), 
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 
2.6.24, BuildID[sha1]=edf4cff78e6710ff4f7ac14cb99b38aefed2659e, stripped

I can fix it with

> patchelf --set-interpreter "$(realpath "$(which sh)")" /path/to/foreign/binary

(Is this the commended way?)

Now it starts up but the linker fails to find some libraries:

> /path/to/foreign/binary
/path/to/foreign/binary: error while loading shared libraries: libstdc++.so.6: 
cannot open shared object file: No such file or directory

> ldd /path/to/foreign/binary
linux-vdso.so.1 (0x7ffd71355000)
libdl.so.2 => 
/gnu/store/4sqaib7c2dfjv62ivrg9b8wa7bh226la-glibc-2.26.105-g0890d5379c/lib/libdl.so.2
 (0x7fa746ffd000)
libpthread.so.0 => 
/gnu/store/4sqaib7c2dfjv62ivrg9b8wa7bh226la-glibc-2.26.105-g0890d5379c/lib/libpthread.so.0
 (0x7fa746ddf000)
librt.so.1 => 
/gnu/store/4sqaib7c2dfjv62ivrg9b8wa7bh226la-glibc-2.26.105-g0890d5379c/lib/librt.so.1
 (0x7fa746bd7000)
libstdc++.so.6 => not found
libm.so.6 => 
/gnu/store/4sqaib7c2dfjv62ivrg9b8wa7bh226la-glibc-2.26.105-g0890d5379c/lib/libm.so.6
 (0x7fa74688b000)
libgcc_s.so.1 => not found
libc.so.6 => 
/gnu/store/4sqaib7c2dfjv62ivrg9b8wa7bh226la-glibc-2.26.105-g0890d5379c/lib/libc.so.6
 (0x7fa7464d9000)

/gnu/store/4sqaib7c2dfjv62ivrg9b8wa7bh226la-glibc-2.26.105-g0890d5379c/lib/ld-linux-x86-64.so.2
 (0x7fa747201000)

The "missing" libraries are indeed in my ~/.guix-profile/lib.  This
folder is properly referenced in the environment:

> env | grep LIBRARY_PATH
LIBRARY_PATH=/home/ambrevar/.guix-profile/lib

My understanding is that the LIBRARY_PATH is only used for compiling,
not at runtime.  But then how come some libraries are found and not others?
Or is it just true for the libs in the glibc package, because
ld-linux-x86-64.so.2 is part of it, so it searchs its own path?

If I export LD_LIBRARY_PATH to the value of LIBRARY_PATH, then it works:

> export LD_LIBRARY_PATH=$LIBRARY_PATH
> /path/to/foreign/binary

Is there a better way?

-- 
Pierre Neidhardt

Price does not include taxes.


signature.asc
Description: PGP signature