Page MenuHomeSolus

Get the RPATH out of my face
Closed, ResolvedPublic

Description

RPATHing binaries and libraries for absolutely no reason is catastrophic to the system and leading to issues such as T6084 T6530 and T6584

Time to RPATH off. Note this is a tracking bug, so don't start throwing up patches without talking to me.

libtool is...

  • Fix libtool directly or workaround it via LT_SYS_LIBRARY_PATH in solbuild as automake also makes life difficult. https://github.com/solus-project/ypkg/pull/60 should deal with this and successfully removes RPATH in libglvnd

Spreading RPATH via pkgconfig!:

openmpi (uses -Wl, --enable-new-dtags for RUNPATH which is probably acceptable!) has --disable-wrapper-rpath but uncertain whether you want to change its behaviour as you very well might be running external libraries when compiling with this. Leaving this as is

Should be harmless mentions and gone after rebuilds:

  • curl (inherits from kerberos)
  • ffmpeg (inherits from sdl2)
  • guile-32bit (maybe libunistring-32bit?)
  • gnutls-32bit (maybe libunistring-32bit?)

Intended:

  • ogre: -Wl,-rpath,${libdir}/OGRE
  • swipl: -Wl,-rpath=/usr/lib64/swipl-7.4.2/lib/x86_64-linux

REBUILDS

  • Rebuild revdeps of libglvnd and ensure packages don't RPATH (then nvidia 304 and 340 drivers should work correctly). Only a few obscure packages haven't so we'll call it done

This should also eradicate much of the RPATHing in Solus

Event Timeline

sunnyflunk triaged this task as Unbreak Now! priority.

Working on kerberos at the moment since I need to sort it for a libsoup change anyways, so may as well kill two birds with one stone.

I'll make sure all the samba related bits are sorted post-sync when we're landing @ermo's patches, maybe he can be a kind soul and do those builds and update the patches. If not, no problemo.

JoshStrobl updated the task description. (Show Details)Jul 6 2018, 12:35 PM
sunnyflunk updated the task description. (Show Details)Jul 6 2018, 12:55 PM

There appears to be a secondary issue which accounts for the packages RPATHing that don't link via the pkgconfig flags...it's name is libtool and it's horrible. Some pretty odd methods of getting system paths such as /etc/ld.so.conf rather than ldconfig. The one method that actually seems to work is exporting LT_SYS_LIBRARY_PATH=%libdir% (to remove rpath of /usr/lib64). It would need to include the usual search paths /lib64 /lib /lib32 /usr/lib64 /usr/lib /usr/lib32

* When building on some GNU/Linux systems for multilib targets
  `libtool' sometimes guesses the wrong paths that the linker and
  dynamic linker search by default. If this occurs for the dynamic
  library path, you may use the `LT_SYS_LIBRARY_PATH' environment
  variable to adjust. Otherwise, at `configure' time you may
  override libtool's guesses by setting the `autoconf' cache
  variables `lt_cv_sys_lib_search_path_spec' and
  `lt_cv_sys_lib_dlsearch_path_spec' respectively.
sunnyflunk updated the task description. (Show Details)Jul 7 2018, 1:33 AM
sunnyflunk updated the task description. (Show Details)Jul 8 2018, 8:31 AM
Jacalz added a subscriber: Jacalz.Jul 8 2018, 6:17 PM
JoshStrobl updated the task description. (Show Details)Jul 12 2018, 10:36 AM
sunnyflunk updated the task description. (Show Details)Jul 16 2018, 4:47 AM

Is there any more advantages to this than the fact that things start working again?

I get my life back

Oh, I was hoping for something in the lines of speedier app startup or slightly better performance but I guess life is important too ??

It speeds up solving bugs so there's definitely efficiency gains

ermo awarded a token.Jul 18 2018, 2:40 PM
sunnyflunk closed this task as Resolved.Jul 31 2018, 6:10 AM
sunnyflunk updated the task description. (Show Details)

All that is to be done, is done now. It will be revisited in future and incidence will be severely reduced since first looked at this.