#37867 closed defect (fixed)
Weird library install_names for MacPorts dylibs
Reported by: | ryandesign (Ryan Carsten Schmidt) | Owned by: | macports-tickets@… |
---|---|---|---|
Priority: | Low | Milestone: | MacPorts 2.6.0 |
Component: | base | Version: | 2.1.2 |
Keywords: | Cc: | ||
Port: |
Description
I noticed that the dylibs installed by MacPorts itself have weird install_names. Here's what I see on most of my systems:
$ find /opt/local/share/macports -name *.dylib | xargs otool -L /opt/local/share/macports/Tcl/darwintrace1.0/darwintrace.dylib: darwintrace.dylib (compatibility version 0.0.0, current version 0.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0) /opt/local/share/macports/Tcl/machista1.0/machista.dylib: machista.dylib (compatibility version 0.0.0, current version 0.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0) /opt/local/share/macports/Tcl/macports1.0/MacPorts.dylib: MacPorts.dylib (compatibility version 0.0.0, current version 0.0.0) /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 744.12.0) /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration (compatibility version 1.0.0, current version 453.18.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0) /opt/local/share/macports/Tcl/pextlib1.0/Pextlib.dylib: Pextlib.dylib (compatibility version 0.0.0, current version 0.0.0) /usr/lib/libcurl.4.dylib (compatibility version 7.0.0, current version 7.0.0) /usr/lib/libedit.3.dylib (compatibility version 2.0.0, current version 3.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0) /opt/local/share/macports/Tcl/registry2.0/registry.dylib: registry.dylib (compatibility version 0.0.0, current version 0.0.0) /usr/lib/libsqlite3.dylib (compatibility version 9.0.0, current version 9.6.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
Here's what I see with the MacPorts 2.1.3 I just built on Tiger:
$ find /opt/local/share/macports/ -name *.dylib | xargs otool -L /opt/local/share/macports//Tcl/darwintrace1.0/darwintrace.dylib: /var/tmp//cc6fy8Fu.out (compatibility version 0.0.0, current version 0.0.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.3.9) /opt/local/share/macports//Tcl/machista1.0/machista.dylib: /var/tmp//cce0Q9af.out (compatibility version 0.0.0, current version 0.0.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.3.9) /opt/local/share/macports//Tcl/macports1.0/MacPorts.dylib: /var/tmp//cccEvqbY.out (compatibility version 0.0.0, current version 0.0.0) /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 368.28.0) /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.3.9) /opt/local/share/macports//Tcl/pextlib1.0/Pextlib.dylib: /var/tmp//cc4tRiPy.out (compatibility version 0.0.0, current version 0.0.0) /usr/lib/libcurl.3.dylib (compatibility version 4.0.0, current version 4.0.0) /usr/lib/libedit.2.dylib (compatibility version 2.0.0, current version 2.0.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.3.9) /opt/local/share/macports//Tcl/registry2.0/registry.dylib: /var/tmp//ccQKhLEE.out (compatibility version 0.0.0, current version 0.0.0) /usr/lib/libsqlite3.0.dylib (compatibility version 9.0.0, current version 9.6.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.3.9)
Does it matter? Should we fix it by setting the -install_name
parameter?
Change History (6)
comment:1 Changed 12 years ago by jmroot (Joshua Root)
comment:2 Changed 8 years ago by jmroot (Joshua Root)
Resolution: | → invalid |
---|---|
Status: | new → closed |
The observation is correct, but it's not a problem, hence closing as "invalid".
comment:3 Changed 7 years ago by ryandesign (Ryan Carsten Schmidt)
Milestone: | → MacPorts 2.5.0 |
---|---|
Resolution: | invalid |
Status: | closed → reopened |
In the mean time, the install_name
of Pextlib.dylib and registry.dylib are being set. PR 87 fixes the install_name
of the 3 other plugins.
comment:4 Changed 6 years ago by jmroot (Joshua Root)
Milestone: | MacPorts 2.5.0 → MacPorts Future |
---|
Ticket retargeted after milestone closed
comment:5 Changed 6 years ago by ryandesign (Ryan Carsten Schmidt)
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
comment:6 Changed 6 years ago by jmroot (Joshua Root)
Milestone: | MacPorts Future → MacPorts 2.6.0 |
---|
Note: See
TracTickets for help on using
tickets.
They're used like plugins rather than libraries, with the Tcl interpreter loading them with dlopen(), so it probably doesn't matter at all.