Don't write redundant RPATH entries #39

Open
opened 2021-04-09 10:30:52 +00:00 by rossburton · 3 comments

Libtool can be told what the library search paths are, so it knows not to write RPATHs for those directories. This can be done via setting the lt_cv_sys_lib_dlsearch_path_spec environment variable to a space-separated list of directories. Real example from OpenEmbedded:

export lt_cv_sys_lib_dlsearch_path_spec = "${libdir} ${base_libdir}"

This ensures that no matter what libdir is set to, only the important RPATHs are set.

Libtool can be told what the library search paths are, so it knows not to write RPATHs for those directories. This can be done via setting the `lt_cv_sys_lib_dlsearch_path_spec` environment variable to a space-separated list of directories. Real example from OpenEmbedded: ``` export lt_cv_sys_lib_dlsearch_path_spec = "${libdir} ${base_libdir}" ``` This ensures that no matter what `libdir` is set to, only the important RPATHs are set.
Owner

Not opposed to supporting that, but first we need to sort out a few minor issues:

  1. is space indeed the path separator? that's a bit surprising, I would have expected a colon between the two variables.

  2. as a policy, slibtool does not rely on environment variables, but here are a few alternatives that come to mind, and which could be used alongside one another:

  • --system-dlsearch-path=... if provided from the command line, use that argument value.
  • --sysroot-relative configuration: which should work nicely for both native builds and cross-compilation. Given --sysroot=/path/to/sysroot, and with --host being either detected or provided, look for /path/to/sysroot/etc/slibtool/[$HOST].conf and get the default library search path from there.
  • --hostcfg=... <== similar to the above, but overriding the default path for the configuration file.

Now that we have a working slibtool.m4, it would probably be beneficial to include some LTFLAGS of sorts in its logic. This will result in Makefile having something like LIBTOOL = dlibtool $(LTFLAGS)

Not opposed to supporting that, but first we need to sort out a few minor issues: 1. is space indeed the path separator? that's a bit surprising, I would have expected a colon between the two variables. 2. as a policy, slibtool does not rely on environment variables, but here are a few alternatives that come to mind, and which could be used alongside one another: * `--system-dlsearch-path=...` if provided from the command line, use that argument value. * `--sysroot`-relative configuration: which should work nicely for both native builds and cross-compilation. Given `--sysroot=/path/to/sysroot`, and with `--host` being either detected or provided, look for `/path/to/sysroot/etc/slibtool/[$HOST].conf` and get the default library search path from there. * `--hostcfg=...` <== similar to the above, but overriding the default path for the configuration file. Now that we have a working *slibtool.m4*, it would probably be beneficial to include some `LTFLAGS` of sorts in its logic. This will result in *Makefile* having something like `LIBTOOL = dlibtool $(LTFLAGS)`
Author
  1. Yes
  2. --system-dlsearch-path= seems like the solution with the least amount of magic to go wrong. Colon-separated list?
1) Yes 2) `--system-dlsearch-path=` seems like the solution with the least amount of magic to go wrong. Colon-separated list?
Owner
  1. --system-dlsearch-path= seems like the solution with the least amount of magic to go wrong. Colon-separated list?

--system-dlsearch-path= is certainly going to be the first to be implemented; and yes, just colon-separated lists please, that's how PATH and related environment variables work, and arguably the only safe way to go about things.

> 2) `--system-dlsearch-path=` seems like the solution with the least amount of magic to go wrong. Colon-separated list? `--system-dlsearch-path=` is certainly going to be the first to be implemented; and yes, just colon-separated lists please, that's how PATH and related environment variables work, and arguably the only safe way to go about things.
Sign in to join this conversation.
No labels
No milestone
No project
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
cross/slibtool#39
No description provided.