xalanc @1.11: build failure due to build setting DYLD_LIBRARY_PATH

[jlaura@…]

Xalanc 1.10.0 OS X 10.10 Xcode 6.1

Xalanc is failing to build using clang and gcc on 10.10 due to errors with SQLite3.

Error snippet:

dyld: Symbol not found: _sqlite3_intarray_bind
  Referenced from: /System/Library/Frameworks/CoreData.framework/Versions/A/CoreData
  Expected in: /opt/usgs/v002/ports/lib/libsqlite3.dylib
 in /System/Library/Frameworks/CoreData.framework/Versions/A/CoreData

I have both a system installation and the ports installation of sqlite3. It looks like the xalanc port is seeing the system install and not the ports install?

prog18:~ jlaura$ sqlite3 -version
3.8.7.1 2014-10-29 13:59:56 3b7b72c4685aa5cf5e675c2c47ebec10d9704221
prog18:~ jlaura$ /usr/bin/sqlite3 -version
3.8.5 2014-08-15 22:37:57 c8ade949d4a2eb3bba4702a4a0e17b405e9b6ace

otool -L /System/Library/Frameworks/CoreData.framework/Versions/A/CoreData

/System/Library/Frameworks/CoreData.framework/Versions/A/CoreData:
        /System/Library/Frameworks/CoreData.framework/Versions/A/CoreData (compatibility version 1.0.0, current version 526.0.0)
        /System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 1.0.0, current version 57031.1.27)
        /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1151.13.0)
        /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1151.14.0)
        /usr/lib/libsqlite3.dylib (compatibility version 9.0.0, current version 166.0.0)
        /usr/lib/libicucore.A.dylib (compatibility version 1.0.0, current version 53.1.0)
        /usr/lib/libauto.dylib (compatibility version 1.0.0, current version 1.0.0)
        /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5)
        /usr/lib/libDiagnosticMessagesClient.dylib (compatibility version 1.0.0, current version 1.0.0)
        /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0)

[jlaura@…]

Install logs

[mf2k (Frank Schima)]

In the future, please fill in the Port field and Cc the port maintainers (port info --maintainers xalanc), if any.

[ryandesign (Ryan Carsten Schmidt)]

The only reason why a system library or framework like CoreData, which is linked with macOS sqlite not MacPorts sqlite, would try to use MacPorts sqlite, is if the build is setting DYLD_LIBRARY_PATH to include your MacPorts prefix, which would be a wrong thing for it to try to do.

[ryandesign (Ryan Carsten Schmidt)]

Yup, there it is:

$ grep DYLD work/xalan-c-1.11/c/Makefile.incl.in
work/xalan-c-1.11/c/Makefile.incl.in:  export DYLD_LIBRARY_PATH := $(XERCESCROOT)/lib:$(ICULIB_LOC):$(DYLD_LIBRARY_PATH)

Whoever wrote this Makefile fragment must have thought that DYLD_LIBRARY_PATH on macOS works like LD_LIBRARY_PATH on Linux, but it does not.

Has duplicate #61520.

On my 10.13 system I got an even stranger error:

dyld: initializer in image (/usr/lib/libc++.1.dylib) that does not link with libSystem.dylib
gnumake: *** [all] Abort trap: 6

(/usr/lib/libc++.1.dylib most certainly does link with libSystem.dylib.)

The build succeeded when I removed the DYLD_LIBRARY_PATH line from the file so I'll commit that in a moment.

There is a new version 1.12 available, but it completely replaces the old autotools build system with cmake so that's more work than just adjusting a patchfile.

[ryandesign (Ryan Carsten Schmidt)]

In 9d78b0a14e187d81195af4b8edde4f05de2125df/macports-ports (master):

xalanc: Do not set DYLD_LIBRARY_PATH willy-nilly

It causes builds to fail.

Closes: #46110

[ryandesign (Ryan Carsten Schmidt)]

They did something similar in that they replaced DYLD_LIBRARY_PATH with DYLD_FALLBACK_LIBRARY_PATH:

​https://github.com/apache/xalan-c/commit/596b3bbd3dfd3a6d64566de5393b6568ecacae69

There's no reason why the libraries it's linking with wouldn't be located at the places they say they are, so there's no reason to set a fallback path.