Change in osmo-gsm-tester[master]: util: adds the feature to force the rpath when patching files.

[alealcon]

alealcon has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-gsm-tester/+/24272 )

Change subject: util: adds the feature to force the rpath when patching files.
......................................................................


Patch Set 1:

Hi Pau, some comments for each question:

 - Should I remove the function and add that parameter to the normal patchelf function? This will help us (as I prefer to set an absolute path on deploy rather that on build), but if you don't approve to modify the rpath inside the srs-enb.py file it doesn't make sense this change and we can remove this commit.

- I agree with you that it makes sense to have different build scripts, each of them supporting different platforms (ppc, aarch64, armv7). What I don't like is that I must set an absolute path for the patchelf utility in those scripts, because if I have 2 different boards with the same platform (ppc for example) that path can change between boards due hardware specs. I would really love to avoid that. 
If you prefer that I add a jenkins-build-stslte-bbu.sh I'm thinking to add 2 variables to the jenkins-build-commmon.sh: PATCHELF_RPATH_ARGS='--set-rpath' and PATCHELF_RPATH_DIR='$ORIGIN/../lib/' by default. The jenkins-build-stslte-bbu.sh will overwrite those values to  PATCHELF_RPATH_ARGS='--force-rpath --set-rpath' and PATCHELF_RPATH_DIR='/mnt/nfs/bdlibs/'. The call within the *-common.sh would be:
	if [ -d bin/ ]; then
		find bin -depth -type f -exec patchelf $PATCHELF_RPATH_ARGS $PATCHELF_RPATH_DIR {} \;
	fi
	if [ -d sbin/ ]; then
		find sbin -depth -type f -exec patchelf $PATCHELF_RPATH_ARGS $PATCHELF_RPATH_DIR {} \;

Does it sound good to you?

One last question regarding the patchelf that is done in jenkins-build-common.sh. Why does that script sets the rpath? Is there a file where the "LD_LIBRARY_PATH" is not set before launching the binary?
I ask this, because I configure the rpath and the dynamic-linker in the toolchain, and I've tested that removing the call to "add_rpath" in the jenkins-build-common.sh makes the srsenb works without patching it or configuring the LD_LIBRARY_PATH in enb-srs.py.
 

- I did that test. I removed the rpath from a binary and run ldd

root at b4860qds:# LD_LIBRARY_PATH='/mnt/nfs/osmo-gsm-tester-srsenb/srslte/lib:/mnt/nfs/bdlibs' /mnt/nfs/ldd ../srslte/bin/srsenb srsenb.conf 
/bin/sh: /lib/ld.so.1: version `GLIBC_2.22' not found (required by /mnt/nfs/bdlibs/libc.so.6)

It uses the system's ld (/lib/ld.so.1) instead of the toolchain's ld (/mnt/nfs/bdlibs/ld.so.1). Perhaps is because we're using LD_LIBRARY_PATH. Here is the linker section of the srsenb (which points to the right ld):

root at b4860qds:# readelf -l srsenb

El tipo del fichero elf es EXEC (Fichero ejecutable)
Entry point 0x10020fb8
There are 10 program headers, starting at offset 52

Encabezados de Programa:
  Tipo           Desplaz  DirVirt    DirFísica  TamFich TamMem  Opt Alin
  PHDR           0x000034 0x10000034 0x10000034 0x00140 0x00140 R   0x4
  INTERP         0x000174 0x10000174 0x10000174 0x00018 0x00018 R   0x1
      [Requesting program interpreter: /mnt/nfs/bdlibs/ld.so.1]


-- 
To view, visit https://gerrit.osmocom.org/c/osmo-gsm-tester/+/24272
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings

Gerrit-Project: osmo-gsm-tester
Gerrit-Branch: master
Gerrit-Change-Id: I2d4a105d4843c0d31d6b5d8f8d4195247b290aec
Gerrit-Change-Number: 24272
Gerrit-PatchSet: 1
Gerrit-Owner: alealcon <alejandro.leal at srs.io>
Gerrit-Reviewer: Jenkins Builder
Gerrit-CC: pespin <pespin at sysmocom.de>
Gerrit-Comment-Date: Thu, 03 Jun 2021 14:49:44 +0000
Gerrit-HasComments: No
Gerrit-Has-Labels: No
Gerrit-MessageType: comment
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20210603/dee11f11/attachment.htm>