[MacPorts] #36438: ports which mirror system libraries can cause +universal ports to fail if they are -universal

MacPorts noreply at macports.org
Sat May 11 11:59:23 PDT 2013


#36438: ports which mirror system libraries can cause +universal ports to fail if
they are -universal
----------------------------+------------------------
  Reporter:  ahelfer1971@…  |      Owner:  jeremyhu@…
      Type:  defect         |     Status:  assigned
  Priority:  Normal         |  Milestone:
 Component:  ports          |    Version:  2.1.2
Resolution:                 |   Keywords:
      Port:  ld64           |
----------------------------+------------------------

Comment (by jeremyhu@…):

 Replying to [comment:56 cal@…]:
 > Replying to [comment:36 rmstonecipher@…]:
 > > Would making +universal a default variant for libstdcxx and other
 ports plagued by this problem be an acceptable solution?
 >
 > This would however require people to build a lot of universal code they
 might not want or need. I'd like to object this proposal.
 >
 > Replying to [comment:37 jeremyhu@…]:
 > > {{{
 > > /opt/local/lib $ for f in *; do [[ -f /usr/lib/$f ]] && port provides
 /opt/local/lib/$f; done | sed 's/.*: //' | sort -u
 > > }}}
 >
 > This lists _all_ ports that provide libraries also shipped with OS X.
 Note that we only need to consider those that are being used without a
 dependency being specified.

 Not really.  As I mentioned earlier, perl doesn't use libstdcxx.  One of
 its dependencies (a *host* framework) uses the host libstdc++.dylib.

 > It seems we should rather find out why the linker is trying to use
 libstdc++. Is it an indirect dependency of something in the perl build
 process?

 I forget what it was specifically, but something in either /usr/lib or
 /System/Library/Frameworks that perl was linking against has a link
 against /usr/lib/libstdc++.6.dylib

 > Is it hard-coded into the ld64 source?

 What is the "it" that you are asking about here?

 > While there are some hardcoded paths in the source, they point to
 /usr/lib and don't seem to cause this.

 It's the use of -L/opt/local/lib that is causing ld to resolve the
 /usr/lib/libstdc++.6.dylib link in an existing library to
 /opt/local/lib/libstdc++.6.dylib in much the same way that
 DYLD_LIBRARY_PATH operates at runtime for dyld.

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


More information about the macports-tickets mailing list