GLFW builds dylib without correct path

[rosssmith@…]

The GLFW port is currently unusable without extra work by users. It seems to be built without an absolute path embedded in the dylib:

otool -L /opt/local/lib/libglfw.3.dylib 
/opt/local/lib/libglfw.3.dylib:
	libglfw.3.dylib (compatibility version 3.0.0, current version 3.0.0)
	/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 20.0.0)
	/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 855.11.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)
	/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
	/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices (compatibility version 1.0.0, current version 48.0.0)
	/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 1265.0.0)
	/System/Library/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics (compatibility version 64.0.0, current version 600.0.0)
	/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1056.0.0)

The reference to itself on the first line, which will be embedded in any executable that tries to use it, is unqualified, so the executable will fail to find the dylib at runtime unless it has been copied or symlinked into the current directory. Compare with any other working dylib, e.g. PCRE:

otool -L /opt/local/lib/libpcre.1.dylib 
/opt/local/lib/libpcre.1.dylib:
	/opt/local/lib/libpcre.1.dylib (compatibility version 4.0.0, current version 4.1.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)

Notice that the first line, the reference to the PCRE dylib itself, is fully qualified.

I'm afraid I don't know enough about Macports internals to detail how to fix this, but presumably anyone who has created a working Macport that includes a dylib will know what to do here.

[ryandesign (Ryan Carsten Schmidt)]

Agreed; the library's install_name is wrong.

[michaelld (Michael Dickens)]

Yeah, true. This issue was fixed with patches I pushed upstream a while ago, and is found in the GIT master. I had hoped that the upstream would create a new version quickly, but that's not happening. So, I'm moving glfw-devel -> glfw and just having glfw follow the latest GIT master. Checking that in soon.

[michaelld (Michael Dickens)]

Done in r112622. This change works for me on 10.8 using the latest xcode, so I'm closing this ticket as fixed. Reopen it if the glfw library still has this issue for you after the update.