This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/gerrit-log@lists.osmocom.org/.
pespin gerrit-no-reply at lists.osmocom.orgpespin 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:
> 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]
* [jenkins-build-stslte-bbu.sh]
Fine with it. Regarding, PATCHELF_RPATH_DIR='/mnt/nfs/bdlibs/', it may be interesting to plan that variable as being a list of ":" separated paths and look at how to use that into patchelf. Because in that case you'd probably need to add both PATCHELF_RPATH_DIR='/mnt/nfs/bdlibs/:$ORIGIN/../lib/' ?
BTW, I forgot to talk about it, but patchelf MUST be >= 0.11, older versions are really not supported since they contain several bugs. See https://osmocom.org/issues/4389 for more info.
* [jenkins-build-common.sh. Why does that script sets the rpath]
That's indeed a good question, and it's probably historical. I started by using LD_LIBRARY_PATH at runtime, which is the easiest/quickest to use. However, for binaries requiring ADMIN capabilities, it works similar to suid bit, which means for security reasons the dynamic loader will disable use of LD_LIBRARY_PATH, so we can't use that. We must first hence patch the binary with patchelf before running it (could it be that in this case relative RPATH is not allowed too? I don't remember TBH).
The patchelf stuff in jenkins-build-common.sh was added a long time ago by Holger why adding some OGT parts which never ended up fully merged with the rest of the code (see 9cf1c8afde842febc02ce5fe6f931fe797236a84 and src/osmo_ms_driver/). Specially important may be the "lib" part of those lines, were all libs are also patched to conform recursively to that RPATH.
In the end, I would say it's up to the "user/dev" adding new trials/classes to decide the best way, either by getting rid of the issue at compile time (jenkins-build-common.sh), or having to do it at runtime (inside resource object class). So following you question: I think we could get rid of setting LD_LIBRARY_PATH at runtime in lots of places since we nowadays patch the binaries at buildtime, but anyway it really doesn't hurt since it's not really making tests take longer or whatever.
* [/bin/sh: /lib/ld.so.1: version `GLIBC_2.22' not found (required by /mnt/nfs/bdlibs/libc.so.6)]
Yeah, applying a different libc version from system's one doesn't look like a great/desirable idea to me, I wonder who you ended up in the situation of needing to use a different libc than the one installed in the system :)
--
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 15:40:26 +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/dd92c498/attachment.htm>