Ticket #1421 (closed enhancement: fixed)

Opened 2 years ago

Last modified 20 months ago

Patch premake to not generate rpath

Reported by: pcpa Owned by:
Priority: Nice to Have Milestone: Alpha 11
Component: Build & Packages Keywords:
Cc: Yves

Description

I am working on a 0ad package for Fedora, and to follow Fedora policies, rpath is not acceptable. The patch I made can be be used in this case, but I believe it should be done by library, and require extra features in premake.

Attachments

0ad-r11339-rpath.patch (1.1 KB) - added by pcpa 2 years ago.
0ad-r11339-rpath.patch

Change History

Changed 2 years ago by pcpa

0ad-r11339-rpath.patch

comment:1 Changed 2 years ago by historic_bruno

http://fedoraproject.org/wiki/Packaging:Guidelines#Beware_of_Rpath says:

"When a program installs internal libraries they are often not installed in the system path. These internal libraries are only used for the programs that are present in the package (for example, to factor out code that's common to the executables). These libraries are not intended for use outside of the package. When this occurs, it is acceptable for the programs within the package to use an rpath to find these libraries."

Which sounds like what we're using it for, or not? If it's only for bundled Spidermonkey as the comment in premake4.lua says, maybe it should be conditional on the use of the --with-system-mozjs185 option.

comment:2 Changed 2 years ago by pcpa

Thanks for the reply. The patch reason was for both, to disable rpath but also due to either setting rpath to libdir or an empty string depending on options used.

Not using rpath also make it easier to package as it is not required any special case handling.

But the report was mostly to let upstream know about the issue :-)

comment:3 Changed 2 years ago by pcpa

  • Status changed from new to closed
  • Resolution set to worksforme

comment:4 Changed 2 years ago by k776

  • Milestone Backlog deleted

comment:5 Changed 2 years ago by historic_bruno

  • Cc Yves added

I'm not sure this should be closed, I don't completely understand our use of rpath, but it doesn't seem correct as-is if Spidermonkey is provided by the system.

comment:6 Changed 22 months ago by leper

Could you check out #1516 as this includes a fix/change that affects the use of rpath (only use it when using our bundled SpiderMonkey).

comment:7 Changed 21 months ago by leper

  • Status changed from closed to reopened
  • Resolution worksforme deleted
  • Milestone set to Alpha 11

comment:8 Changed 21 months ago by leper

  • Status changed from reopened to closed
  • Resolution set to fixed

r12173 only adds rpath if building with the bundled SpiderMonkey.

comment:9 Changed 21 months ago by ben

In 12198:

Fixes incorrect exclusion of rpath that broke shared lib loading. Refs #1421, #1516

comment:10 Changed 20 months ago by pcpa

The problem happens again in my Fedora build, so I reinstantied the original patch. It is a minor issue, and my package uses LD_LIBRARY_PATH to avoid the need of special handling during rpmbuild, due to the error:

*******************************************************************************
*
* WARNING: 'check-rpaths' detected a broken RPATH and will cause 'rpmbuild'
*          to fail. To ignore these errors, you can set the '$QA_RPATHS'
*          environment variable which is a bitmask allowing the values
*          below. The current value of QA_RPATHS is 0x0000.
*
*    0x0001 ... standard RPATHs (e.g. /usr/lib); such RPATHs are a minor
*               issue but are introducing redundant searchpaths without
*               providing a benefit. They can also cause errors in multilib
*               environments.
*    0x0002 ... invalid RPATHs; these are RPATHs which are neither absolute
*               nor relative filenames and can therefore be a SECURITY risk
*    0x0004 ... insecure RPATHs; these are relative RPATHs which are a
*               SECURITY risk
*    0x0008 ... the special '$ORIGIN' RPATHs are appearing after other
*               RPATHs; this is just a minor issue but usually unwanted
*    0x0010 ... the RPATH is empty; there is no reason for such RPATHs
*               and they cause unneeded work while loading libraries
*    0x0020 ... an RPATH references '..' of an absolute path; this will break
*               the functionality when the path before '..' is a symlink
*          
*
* Examples:
* - to ignore standard and empty RPATHs, execute 'rpmbuild' like
*   $ QA_RPATHS=$[ 0x0001|0x0010 ] rpmbuild my-package.src.rpm
* - to check existing files, set $RPM_BUILD_ROOT and execute check-rpaths like
*   $ RPM_BUILD_ROOT=<top-dir> /usr/lib/rpm/check-rpaths
*  
*******************************************************************************
ERROR   0010: file '/usr/bin/pyrogenesis' contains an empty rpath in []
ERROR   0010: file '/usr/lib64/0ad/libCollada.so' contains an empty rpath in []
ERROR   0010: file '/usr/lib64/0ad/libAtlasUI.so' contains an empty rpath in []
Note: See TracTickets for help on using tickets.