xpra icon
Bug tracker and wiki

Opened 3 months ago

Last modified 5 weeks ago

#1405 assigned defect

rpath ignored when system libraries are matched first

Reported by: Antoine Martin Owned by: Antoine Martin
Priority: blocker Milestone: 2.1
Component: packaging Version: trunk
Keywords: Cc:

Description

Related to #1256 and #613.

On some platforms (ie: centos7, suse), the linker command will have -L/usr/lib64 ahead of -L/usr/lib64/xpra and so the cython modules will link against the system libraries and we won't use our private libraries.. leading to warnings and sub-optimal behaviour.

Change History (6)

comment:1 Changed 3 months ago by Antoine Martin

Status: newassigned

I already had a fix for this: r14750.
Applied to v1.0.x in r14751, also needed r14743 (+ r14744 fixup) to pass the rpath to the setup.py

But since the potential for regressions is high... I am keeping this ticket open, at least until 1.0.2 is released.

Last edited 3 months ago by Antoine Martin (previous) (diff)

comment:2 Changed 3 months ago by Antoine Martin

Found the first problem: the linker doesn't use our version of the libraries because /usr/lib64/xpra contains a libvpx.so.4 but /usr/lib64 has a libvpx.so symlink to libvpx.so.1 and that takes precedence because we link with -lvpx.
If I manually add a symlink so to libvpx.so.4 under /usr/lib64/xpra/libvpx.so then the module does get linked against the version of the library we want, but then it crashes during selftests..

comment:3 Changed 3 months ago by Antoine Martin

Priority: majorblocker

comment:2 was wrong: the problem on this particular system was that the development package libvpx-xpra-devel was not installed correctly (partially removed?) and it contains the required libvpx.so symlink and the correct library headers. With this properly installed, all the problems go away.
At least all the unit tests now run... except when they are ran from the rpmbuild command, then the codec self test crashes with memory corruption in vpx!

comment:4 Changed 8 weeks ago by Antoine Martin

This seemed too risky for the 1.0 stable branch, so r14907 partially reverts r14751, so the library order will be unchanged for now.
This does mean that we're not necessarily using the libraries we want to be using. But that's better than crashing.

comment:5 Changed 5 weeks ago by Antoine Martin

Milestone: 2.02.1

Likely to cause problems, too late for that. Re-scheduling.

comment:6 Changed 5 weeks ago by Antoine Martin

Also partially reverted in trunk as of r15137

Note: See TracTickets for help on using tickets.