Note that some of these are trivial to fix. For example, a SIP-friendly
InfoTest for libmetalink3 only requires...
diff -[Jack-Howarths-Computer:main/finkinfo/net] howarth% diff -u
libmetalink3.info libmetalink3.info.sip
--- libmetalink3.info 2015-09-14 11:05:26.000000000 -0400
+++ libmetalink3.info.sip 2015-09-14 11:05:06.000000000 -0400
@@ -30,10 +30,15 @@
InfoTest:<<
TestDepends: cunit1
- TestScript: DYLD_LIBRARY_PATH="%b/lib/.libs" make check
CPPFLAGS="-DHAVE_INTTYPES_H" || exit 2
+ TestScript: make check CPPFLAGS="-DHAVE_INTTYPES_H" || exit 2
<<
+CompileScript: <<
+ %{default_script}
+ install_name_tool -id %b/lib/.libs/libmetalink.3.dylib
%b/lib/.libs/libmetalink.3.dylib
+<<
InstallScript: <<
+ install_name_tool -id %p/lib/libmetalink.3.dylib
%b/lib/.libs/libmetalink.3.dylib
make install DESTDIR=%d
<<
On Mon, Sep 14, 2015 at 10:29 AM, Jack Howarth <howarth.at.f...@gmail.com>
wrote:
> One issue we have to address is the fallout of the new Security
> Integrity Protection feature on DYLD_LIBRARY_PATH handling during builds
> and testsuite runs...
>
>
> https://developer.apple.com/library/prerelease/ios/documentation/Security/Conceptual/System_Integrity_Protection_Guide/System_Integrity_Protection_Guide.pdf
>
> The most extreme category will be those packages which need to run
> their own binaries during the build/installation. The gcc5 package fails in
> that category but fortunately in a non-fatal manner when it tries to run
> gcj-dbtool.
> The second category are the testsuites which will fail unless the
> shared libs of the package are already installed. libmetalink3, nghttp2 and
> libssh2 are a few examples of that.
> The available solutions are...
>
> 1) Readjust the build to use DYLD_FALLBACK_LIBRARY_PATH but this creates
> the problem of accidental testing against the previous copy of the shared
> libraries.
> 2) Adjust the build to set the shared library install name to the actual
> build directory location and link the executables against that. However
> this requires the install script to reset the install names of the shared
> libraries and their usages in the executables to the final correct location.
> 3) Use @loader_path, @executable_path or @rpath. This is problematic
> unless the build currently stows the built binaries in subdirectories that
> mirror the final installation (eg bin and lib at the same directory level).
> This could be worked around in the same manner as option 2 by having the
> install name set to the actual build directory and then resetting them
> appropriately on installation.
> Jack
>
> ps These issues are already getting some traffic on the developer mailing
> lists...
>
> https://forums.developer.apple.com/message/35499#35499
> https://forums.developer.apple.com/message/28622#28622
>
------------------------------------------------------------------------------
_______________________________________________
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel
