runpath validation

runpath validation

[Catonano]

[-- Attachment #1: Type: text/plain, Size: 1905 bytes --]

trying to build Granite
https://launchpad.net/granite

I get this error

validating RUNPATH of 1 binaries in
"/gnu/store/c7zrvx10p41g26q0l8jray6xc0lv4qn3-granite-0.4.0.1/bin"...
/gnu/store/c7zrvx10p41g26q0l8jray6xc0lv4qn3-granite-0.4.0.1/bin/granite-demo:

error: depends on 'libgranite.so.3', which cannot be found in RUNPATH
(
"/gnu/store/c7zrvx10p41g26q0l8jray6xc0lv4qn3-granite-0.4.0.1/lib"
"/gnu/store/rmjlycdgiq8pfy5hfi42qhw3k7p6kdav-glibc-2.25/lib"
"/gnu/store/dhc2iy059hi91fk55dcv79z09kp6500y-gcc-5.4.0-lib/lib"
"/gnu/store/33wnpkc00awp59nsr8anmm5d265gcg85-gtk+-3.22.6/lib"
"/gnu/store/r1zsyinrpcpfbcym5qrx6zbk6hwzxwnm-pango-1.40.3/lib"
"/gnu/store/jkx9mkw8j34jfnv0dqdbbzxdcx3mlfdg-atk-2.22.0/lib"
"/gnu/store/i0bjwdqvn0wixcwfpw254w0az17iysga-cairo-1.14.8/lib"
"/gnu/store/di54h9fw72m3y31vpkpgk71clccrpwy8-gdk-pixbuf+svg-2.36.3/lib"
"/gnu/store/0wps368gx0cn3ynrkbhzq5pxf75rng7y-glib-2.50.3/lib"
"/gnu/store/5bx1wrvp15sr8jvwhaxf1x69chmh4w0j-libgee-0.18.1/lib"
"/gnu/store/dhc2iy059hi91fk55dcv79z09kp6500y-gcc-5.4.0-lib/lib/gcc/x86_64-unknown-linux-gnu/5.4.0/../../..")

I kept the build older (with build -K) and lib/libgranite.so.3 does exist

$ /tmp/guix-build-granite-0.4.0.1.drv-0/build$ ls lib/
Application.c        Drawing/             granite.vapi
libgranite.so.3.0.1  Widgets/
CMakeFiles/          granite.h            GtkPatch/        Makefile
cmake_install.cmake  granite.pc           libgranite.so    Services/
config.h             granite_valac.stamp  libgranite.so.3  style-classes.c

So I though: if I disable runpath check, lib/libgranite.so.3 will be there,
at runtime

So:

#:validate-runpath? #f

in this case the build succeeds but inspecting the built thing in the store
I see

~$ ls /gnu/store/zv2c9mbs4q7f75p9xlgxs62fb5wmp3ac-granite-0.4.0.1/
bin/  include/  lib64/  share/

So now the folder is not lib anymore, it's lib64

Will lib/libgranite.so.3 be found ?

Thanks !
Ciao

[-- Attachment #2: Type: text/html, Size: 2444 bytes --]

Re: runpath validation

[Catonano]

[-- Attachment #1: Type: text/plain, Size: 97 bytes --]

this is the package I'm using. For reference

http://paste.lisp.org/display/344598

Thanks again

[-- Attachment #2: Type: text/html, Size: 204 bytes --]

Re: runpath validation

[Catonano]

[-- Attachment #1: Type: text/plain, Size: 1121 bytes --]

Thanks to Snape I could find objdump and attempt what is suggested here
https://en.wikipedia.org/wiki/Rpath

me@my-machine /gnu/store/zv2c9mbs4q7f75p9xlgxs62fb5wmp3ac-granite-0.4.0.1$
objdump -a -x bin/granite-demo | grep NEEDED
  NEEDED               libgranite.so.3  <--- here it is
  NEEDED               libgtk-3.so.0
  NEEDED               libgdk-3.so.0
  NEEDED               libpangocairo-1.0.so.0
  NEEDED               libpango-1.0.so.0
  NEEDED               libatk-1.0.so.0
  NEEDED               libcairo-gobject.so.2
  NEEDED               libcairo.so.2
  NEEDED               libgdk_pixbuf-2.0.so.0
  NEEDED               libgio-2.0.so.0
  NEEDED               libgthread-2.0.so.0
  NEEDED               libgee-0.8.so.2
  NEEDED               libgobject-2.0.so.0
  NEEDED               libglib-2.0.so.0
  NEEDED               libm.so.6
  NEEDED               libgcc_s.so.1
  NEEDED               libc.so.6


and

me@my-machine /gnu/store/zv2c9mbs4q7f75p9xlgxs62fb5wmp3ac-granite-0.4.0.1$
objdump -a -x bin/granite-demo | grep RPATH
me@my-machine /gnu/store/zv2c9mbs4q7f75p9xlgxs62fb5wmp3ac-granite-0.4.0.1$

[-- Attachment #2: Type: text/html, Size: 1550 bytes --]

Re: runpath validation

[Ludovic Courtès]

Hello!

Catonano <catonano@gmail.com> skribis:

> Thanks to Snape I could find objdump and attempt what is suggested here
> https://en.wikipedia.org/wiki/Rpath
>
> me@my-machine /gnu/store/zv2c9mbs4q7f75p9xlgxs62fb5wmp3ac-granite-0.4.0.1$
> objdump -a -x bin/granite-demo | grep NEEDED
>   NEEDED               libgranite.so.3  <--- here it is
>   NEEDED               libgtk-3.so.0
>   NEEDED               libgdk-3.so.0
>   NEEDED               libpangocairo-1.0.so.0
>   NEEDED               libpango-1.0.so.0
>   NEEDED               libatk-1.0.so.0
>   NEEDED               libcairo-gobject.so.2
>   NEEDED               libcairo.so.2
>   NEEDED               libgdk_pixbuf-2.0.so.0
>   NEEDED               libgio-2.0.so.0
>   NEEDED               libgthread-2.0.so.0
>   NEEDED               libgee-0.8.so.2
>   NEEDED               libgobject-2.0.so.0
>   NEEDED               libglib-2.0.so.0
>   NEEDED               libm.so.6
>   NEEDED               libgcc_s.so.1
>   NEEDED               libc.so.6
>
>
> and
>
> me@my-machine /gnu/store/zv2c9mbs4q7f75p9xlgxs62fb5wmp3ac-granite-0.4.0.1$
> objdump -a -x bin/granite-demo | grep RPATH

You should grep for RUNPATH, and I guess that will show that
/gnu/store/zv2c9mbs4q7f75p9xlgxs62fb5wmp3ac-granite-0.4.0.1/lib is *not*
in there, even though it should (if it’s not in RUNPATH, then launching
‘granite-demo’ will result in a “library not found” error, which is what
this validation phase wants to avoid.)

To fix this, you need to make sure the link command for ‘granite-demo’
has an explicit -lgranite or similar; ld-wrapper will take care of
adding the corresponding -rpath switch.

HTH!  If needed, we can discuss it further on IRC.

Ludo’.

Re: runpath validation

[Catonano]

[-- Attachment #1: Type: text/plain, Size: 1809 bytes --]

2017-04-20 10:10 GMT+02:00 Ludovic Courtès <ludo@gnu.org>:

>
> You should grep for RUNPATH, and I guess that will show that
> /gnu/store/zv2c9mbs4q7f75p9xlgxs62fb5wmp3ac-granite-0.4.0.1/lib is *not*
> in there, even though it should (if it’s not in RUNPATH, then launching
> ‘granite-demo’ will result in a “library not found” error, which is what
> this validation phase wants to avoid.)
>

and instead what I found is that ...granite/lib *is* there

>
> HTH!  If needed, we can discuss it further on IRC.
>

Thanks !
If I find you on line I'll ping you about this

For now, let me report my last findings

The build fails in the validate-runpath phase

With "#:validate-runpath? #f" iit succeeds

AND this is what I find on the resulting built artifact

me@my-machine /gnu/store/wzbjl4mjqdq38jyllb4ny2mn1kkqqikv-granite-0.4.0.1$
objdump -a -x bin/granite-demo | grep RUNPATH
  RUNPATH
/gnu/store/wzbjl4mjqdq38jyllb4ny2mn1kkqqikv-granite-0.4.0.1/lib
:/gnu/store/rmjlycdgiq8pfy5hfi42qhw3k7p6kdav-glibc-2.25/lib
...

I installed granite with

./pre-inst-env guix package -i granite

I got this advice

The following environment variable definitions may be needed:
   export
LIBRARY_PATH="/home/catonano/.guix-profile/lib:/home/catonano/.guix-profile/lib64${LIBRARY_PATH:+:}$LIBRARY_PATH"

I don't know why, I don't touch search paths in the granite package recipe

Anyway I followed the suggestion

~$ echo $LIBRARY_PATH
/home/me.guix-profile/lib
:/home/me/.guix-profile/lib64
:/home/me/.guix-profile/lib


and this is what I get

~$ granite-demo
granite-demo: error while loading shared libraries: libgranite.so.3: cannot
open shared object file: No such file or directory

This is the state of the art, for now

See you around ! ;-)

[-- Attachment #2: Type: text/html, Size: 2595 bytes --]

Re: runpath validation

[Ricardo Wurmus]

Catonano <catonano@gmail.com> writes:

> 2017-04-20 10:10 GMT+02:00 Ludovic Courtès <ludo@gnu.org>:
>
>>
>> You should grep for RUNPATH, and I guess that will show that
>> /gnu/store/zv2c9mbs4q7f75p9xlgxs62fb5wmp3ac-granite-0.4.0.1/lib is *not*
>> in there, even though it should (if it’s not in RUNPATH, then launching
>> ‘granite-demo’ will result in a “library not found” error, which is what
>> this validation phase wants to avoid.)
>>
>
> and instead what I found is that ...granite/lib *is* there

Cmake is a bit weird sometimes.  Look at the definition for “bamtools”
to see how you may be able to explicitly add the lib directory to the
RUNPATH.

Other examples are “powertabeditor” and “lmms” in music.scm.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

RUNPATH validation

[Ludovic Courtès]

In ‘core-updates’ there’s a new ‘validate-runpath’ phase that checks all
the ELF binaries produced and fails if one of them has a dependency
(DT_NEEDED) that cannot be found in its RUNPATH.  It uses (guix elf) and
the new (guix build gremlin).

So now the “dangling .so references” bugs really need to be fixed.  ;-)
A few RUNPATH problems were fixed in ‘core-updates’, mostly related to
cross-compilation where binaries never had a valid RUNPATH due to the
lack of a cross ‘ld-wrapper’ to add ‘-rpath’ flags as we do natively.

Feedback welcome!

Ludo’.