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

alealcon gerrit-no-reply at lists.osmocom.org
Tue Jun 1 14:50:26 UTC 2021


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:

We decided to patch the binary in OGT following the example of other binaries (amarisoft-epc or amarisoft-ms) and because we want to avoid setting those values at compile time, as we think this information is required when running the binary.

For the possibility 1: I can give it a try, but these two things worry me:
  - You must identify the build within the script (by checking the arch, toolchain, trial builder or some other information ) to execute the "patchelf --force-rpath --set-rpath /mnt/nfs/bdlibs/"  specific instruction. As it is now, the script is generic and doesn't check variables to execute specific instructions and I think it's a great idea to keep it simple and generic.
  - AFAIK the built binaries can be used for other devices too. For instance, if we have 2 devices with the ppc arch, we can use the same built binary for both of them, but the problem is that the required libraries can be placed in other paths due hardware requirements(sd-cards, nfs, etc). For me, it makes more sense to add this information to the resources.conf that describes the devices available for OGT and theirs characteristics and give us a lot of flexibility.

For the possibility 2: I think it a clean solution, but I'm not sure if it works. Gonna give it a try. With this solution I don't have to patch the binary? 
The problem here can be the linker. When we build the binary, we set the rpath and dynamic-linker, but the rpath information is removed when executing the "make install" step. We would like to remove that information from the toolchain, as this information depends on the device where it will run the binary and it is not needed for building it. So the problem is that I fear a "patchelf --set-interpreter" will be required in order to work. But we can face that problem in the future.

Summarizing, I'm gonna do a fast test with the second option, and later test the first option, but I would like to give a second thought to extract this kind of information to the resources.conf.

Thanks Pau for your suggestions!


-- 
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: Tue, 01 Jun 2021 14:50: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/20210601/bfa547df/attachment.htm>


More information about the gerrit-log mailing list