Patch premake to not generate rpath

[pcpa]

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.

[pcpa]

0ad-r11339-rpath.patch

[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.

[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 :-)

[historic_bruno]

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.

[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).

[leper]

r12173 only adds rpath if building with the bundled SpiderMonkey.

[ben]

In 12198:

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

[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 []