[MacPorts] #41005: GLFW builds dylib without correct path

MacPorts noreply at macports.org
Sun Oct 27 15:35:09 PDT 2013


#41005: GLFW builds dylib without correct path
-------------------------+--------------------------------
 Reporter:  rosssmith@…  |      Owner:  macports-tickets@…
     Type:  defect       |     Status:  new
 Priority:  Normal       |  Milestone:
Component:  ports        |    Version:  2.2.0
 Keywords:               |       Port:
-------------------------+--------------------------------
 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.

-- 
Ticket URL: <https://trac.macports.org/ticket/41005>
MacPorts <http://www.macports.org/>
Ports system for OS X


More information about the macports-tickets mailing list