ports which mirror system libraries can cause +universal ports to fail if they are -universal

[ahelfer1971@…]

When attempting an upgrade of gcc47, dependency libgdiplus fails.

[ahelfer1971@…]

libgdiplus buidl log

[mf2k (Frank Schima)]

In the future, please fill in the Port field with the failed port and do not change the Priority field.

The log is incomplete. Please clean libgdiplus and try again, and attach the new main.log.

[jeremyhu (Jeremy Huddleston Sequoia)]

What is the output of:

/usr/bin/clang --version
ls /usr/lib/libstdc++*

[jeremyhu (Jeremy Huddleston Sequoia)]

Cc Me!

[jeremyhu (Jeremy Huddleston Sequoia)]

I can't reproduce this. Please figure out how clang is calling the linker by running the failing link command manually with '-v'

[jeremyhu (Jeremy Huddleston Sequoia)]

Ok, I am now able to reproduce this ...

[jeremyhu (Jeremy Huddleston Sequoia)]

The call to ld is:

"/usr/bin/ld" -demangle -dynamic -arch i386 -flat_namespace -macosx_version_min 10.8.0 -undefined suppress -undefined suppress -o /var/folders/kd/lg174pm94bz417bmp5vv57j80000gn/T/testgdi-qVJz5d.out -L/opt/local/lib -L/lib testgdi.o ../src/.libs/libgdiplus.dylib -lpthread /opt/local/lib/libpangocairo-1.0.dylib /opt/local/lib/libcairo.dylib /opt/local/lib/libpixman-1.dylib /opt/local/lib/libxcb-shm.dylib /opt/local/lib/libX11-xcb.dylib /opt/local/lib/libxcb-render.dylib /opt/local/lib/libXrender.dylib -lrt /opt/local/lib/libpangoft2-1.0.dylib /opt/local/lib/libpango-1.0.dylib /opt/local/lib/libgmodule-2.0.dylib /opt/local/lib/libgobject-2.0.dylib /opt/local/lib/libgthread-2.0.dylib /opt/local/lib/libffi.dylib /opt/local/lib/libglib-2.0.dylib -lresolv /opt/local/lib/libtiff.dylib -ljbig /opt/local/lib/libjpeg.dylib /opt/local/lib/libgif.dylib /opt/local/lib/libSM.dylib /opt/local/lib/libICE.dylib /opt/local/lib/libX11.dylib /opt/local/lib/libxcb.dylib /opt/local/lib/libXau.dylib /opt/local/lib/libXdmcp.dylib /opt/local/lib/libpng15.dylib /opt/local/lib/libexif.dylib /opt/local/lib/libintl.dylib -lc -lm /opt/local/lib/libfontconfig.dylib /opt/local/lib/libiconv.dylib /opt/local/lib/libfreetype.dylib -lz -lbz2 /opt/local/lib/libexpat.dylib -framework Foundation -framework Carbon -arch_multiple -final_output .libs/testgdi -lSystem /usr/bin/../lib/clang/4.2/lib/darwin/libclang_rt.eprintf.a /usr/bin/../lib/clang/4.2/lib/darwin/libclang_rt.osx.a

which makes me think this is an ld bug ... we're not even telling the linker to use that dylib, but it's still checking it for some reason...

[jeremyhu (Jeremy Huddleston Sequoia)]

<rdar://problem/12450551>

[jeremyhu (Jeremy Huddleston Sequoia)]

#32396 is essentially the same issue for libxml2.dylib

[ryandesign (Ryan Carsten Schmidt)]

Has duplicates #36444 and #36900 about perl5.12.

[ryandesign (Ryan Carsten Schmidt)]

Duplicate #35644 is about libxml2.dylib again.

[ryandesign (Ryan Carsten Schmidt)]

Duplicate #36971 is also about libxml2.dylib.

[4eppelin@…]

Cc Me!

[larryv (Lawrence Velázquez)]

Cc Me!

[larryv (Lawrence Velázquez)]

I am seeing this (or something vaguely similar, anyway) while trying to configure zsh for i386 with 64-bit libstdcxx installed. It still builds and installs, but none of zsh’s dynamic modules get installed because ./configure gets tripped up:

configure:11810: checking if environ is available in shared libraries
configure:11832: /usr/bin/clang -c -pipe -O2 -arch i386 -I/opt/local/include -fno-common conftest1.c 1>&5
configure:11835: $? = 0
configure:11838: /usr/bin/clang -o conftest1.bundle -v -L/opt/local/lib -Wl,-v -arch i386 -bundle -flat_namespace -undefined suppress conftest1.o -lgdbm -liconv -ldl -lm -lncurses -lc 1>&5
Apple clang version 4.1 (tags/Apple/clang-421.11.66) (based on LLVM 3.1svn)
Target: i386-apple-darwin12.2.0
Thread model: posix
@(#)PROGRAM:ld  PROJECT:ld64-134.9
configured to support archs: armv6 armv7 armv7s i386 x86_64
Library search paths:
	/opt/local/lib
	/opt/local/lib
	/usr/lib
	/usr/local/lib
Framework search paths:
	/Library/Frameworks/
	/System/Library/Frameworks/
ld: in /opt/local/lib/libstdc++.6.dylib, file was built for unsupported file format ( 0xcf 0xfa 0xed 0xfe 0x 7 0x 0 0x 0 0x 1 0x 3 0x 0 0x 0 0x 0 0x 6 0x 0 0x 0 0x 0 ) which is not the architecture being linked (i386): /opt/local/lib/libstdc++.6.dylib for architecture i386
clang: error: linker command failed with exit code 1 (use -v to see invocation)
configure:11841: $? = 1
configure:11929: result: no

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #38858.

[cooljeanius (Eric Gallager)]

Cc Me!

[tkbrekken@…]

Cc Me!

[deesto (John S. De Stefano Jr.)]

Cc Me!

[hapaguy (Brian Kurt Fujikawa)]

Cc Me!

[mf2k (Frank Schima)]

Cc Me!

[denpashogai@…]

Is there a known workaround for this? I can't upgrade perl, and "upgrade outdated" now aborts at that point.

[denpashogai@…]

Cc Me!

[4eppelin@…]

denpashogai@…

Remove all and install again.

[larryv (Lawrence Velázquez)]

Replying to denpashogai@…:

Is there a known workaround for this? I can't upgrade perl, and "upgrade outdated" now aborts at that point.

Force-deactivate libstdcxx for the duration of the upgrade.

sudo port -f deactivate libstdcxx
sudo port upgrade perl5.12
sudo port activate libstdcxx

[denpashogai@…]

Replying to larryv@…:

Force-deactivate libstdcxx for the duration of the upgrade.

sudo port -f deactivate libstdcxx
sudo port upgrade perl5.12
sudo port activate libstdcxx

That seems to have done the trick. Thanks! :)

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to denpashogai@…:

Is there a known workaround for this? I can't upgrade perl, and "upgrade outdated" now aborts at that point.

Another workaround is to install libstdcxx with +universal

[larryv (Lawrence Velázquez)]

Has duplicate #38890 against perl5.12.

[macports@…]

Cc Me!

[mf2k (Frank Schima)]

Has duplicate #38904 about perl5.12.

[bosch@…]

Cc Me!

[ivl1705]

Replying to larryv@…:

Force-deactivate libstdcxx for the duration of the upgrade.

sudo port -f deactivate libstdcxx
sudo port upgrade perl5.12
sudo port activate libstdcxx

Thanks, that solved the issue for me.

[rmstonecipher@…]

Cc Me!

[rmstonecipher@…]

Jeremy,
Would making +universal a default variant for libstdcxx and other ports plagued by this problem be an acceptable solution?

Ryan Stonecipher

[jeremyhu (Jeremy Huddleston Sequoia)]

Yeah, I was thinking that, but it's a long list. Here's from just the ports that I have installed:

/opt/local/lib $ for f in *; do [[ -f /usr/lib/$f ]] && port provides /opt/local/lib/$f; done | sed 's/.*: //' | sort -u
apr
apr-util
bzip2
curl
cyrus-sasl2
expat
kerberos5
libarchive
libcomerr
libedit
libffi
libiconv
libpcap
libstdcxx-devel
libxml2
libxslt
ncurses
neon
net-snmp
openldap
openssl
pcre
python27
readline
ruby
serf1
sqlite3
subversion
zlib

[stevej@…]

Replying to larryv@…:

Replying to denpashogai@…:

Is there a known workaround for this? I can't upgrade perl, and "upgrade outdated" now aborts at that point.

Force-deactivate libstdcxx for the duration of the upgrade.

sudo port -f deactivate libstdcxx
sudo port upgrade perl5.12
sudo port activate libstdcxx

When I try sudo port -f deactivate libstdcxx, I get "Error: port deactivate failed: Image error: port libstdcxx is not active." I am trying to resolve (apparently) the same issue described in this bug though. Trying to upgrade perl 5.12 says...

:info:build ld: in '/opt/local/lib/libstdc++.6.dylib', file was built for unsupported file format ( 0xcf 0xfa 0xed 0xfe 0x 7 0x 0 0x 0 0x 1 0x 3 0x 0 0x 0 0x 0 0x 6 0x 0 0x 0 0x 0 ) which is not the architecture being linked (i386): /opt/local/lib/libstdc++.6.dylib for architecture i386

[larryv (Lawrence Velázquez)]

Replying to stevej@…:

When I try sudo port -f deactivate libstdcxx, I get "`Error: port deactivate failed: Image error: port libstdcxx is not active.`" I am trying to resolve (apparently) the same issue described in this bug though. Trying to upgrade perl 5.12 says...

:info:build ld: in '/opt/local/lib/libstdc++.6.dylib', file was built for unsupported file format ( 0xcf 0xfa 0xed 0xfe 0x 7 0x 0 0x 0 0x 1 0x 3 0x 0 0x 0 0x 0 0x 6 0x 0 0x 0 0x 0 ) which is not the architecture being linked (i386): /opt/local/lib/libstdc++.6.dylib for architecture i386

Do you have libstdcxx-devel installed? Try the same thing using libstdcxx-devel instead of libstdcxx.

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #38946.

[larryv (Lawrence Velázquez)]

Has duplicate #38949 against perl5.12.

[tyson@…]

Cc Me!

[stevej@…]

Aha. In my case, I needed to deactivate/activate libstdcxx-devel instead of libstdcxx.

Replying to larryv@…:

Replying to stevej@…:

When I try sudo port -f deactivate libstdcxx, I get "`Error: port deactivate failed: Image error: port libstdcxx is not active.`" I am trying to resolve (apparently) the same issue described in this bug though. Trying to upgrade perl 5.12 says...

:info:build ld: in '/opt/local/lib/libstdc++.6.dylib', file was built for unsupported file format ( 0xcf 0xfa 0xed 0xfe 0x 7 0x 0 0x 0 0x 1 0x 3 0x 0 0x 0 0x 0 0x 6 0x 0 0x 0 0x 0 ) which is not the architecture being linked (i386): /opt/local/lib/libstdc++.6.dylib for architecture i386

Do you have libstdcxx-devel installed? Try the same thing using libstdcxx-devel instead of libstdcxx.

[schnitzenhymerstine@…]

Cc Me!

[maehne (Torsten Maehne)]

Cc Me!

[larryv (Lawrence Velázquez)]

Has duplicate #39016 against perl5.12.

[cooljeanius (Eric Gallager)]

Replying to rmstonecipher@…:

Jeremy,
Would making +universal a default variant for libstdcxx and other ports plagued by this problem be an acceptable solution?

I vote for either this or... actually nvm, just this.

[jsm@…]

Cc Me!

[gregmainland@…]

Cc Me!

[iwharry@…]

Cc Me!

[boydb@…]

Replying to larryv@…:

Force-deactivate libstdcxx for the duration of the upgrade.

sudo port -f deactivate libstdcxx
sudo port upgrade perl5.12
sudo port activate libstdcxx

For me this did not work off the bat, but if I cleaned my perl5.12 install it then fixed the issue for me.

So, if perl5.12 still fails to build for you after trying the above, here's one more process to try:

sudo port -f deactivate libstdcxx
sudo port clean perl5.12
sudo port upgrade perl5.12
sudo port activate libstdcxx

[cooljeanius (Eric Gallager)]

Actually I just came up with another idea: would throwing something like the following into perl5's universal variant work?

if {![catch "registry_active libstdcxx"]} {
    depends_lib-append path:lib/.libstdcxx:libstdcxx
    require_active_variants path:lib/.libstdcxx:libstdcxx universal
}

This is with including the active_variants 1.1 port group somewhere earlier in the portfile of course. Also I'm adding the dependency on libstdcxx because I'm assuming that require_active_variants only works with ports that are already in a port's dependency list.

[larryv (Lawrence Velázquez)]

Replying to egall@…:

Actually I just came up with another idea: would throwing something like the following into perl5's universal variant work?

if {![catch "registry_active libstdcxx"]} {
    depends_lib-append path:lib/.libstdcxx:libstdcxx
    require_active_variants path:lib/.libstdcxx:libstdcxx universal
}

This is with including the active_variants 1.1 port group somewhere earlier in the portfile of course. Also I'm adding the dependency on libstdcxx because I'm assuming that require_active_variants only works with ports that are already in a port's dependency list.

1. As a dependency of a universal port, MacPorts would already make sure that libstdcxx was installed universal. So active_variants-1.1 would not be necessary.
2. So then perl5.12 +universal would be recorded as being a dependent of libstdcxx, which it doesn’t use at all? No, this is not a viable workaround.

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to egall@…:

Actually I just came up with another idea: would throwing something like the following into perl5's universal variant work?

if {![catch "registry_active libstdcxx"]} {
    depends_lib-append path:lib/.libstdcxx:libstdcxx
    require_active_variants path:lib/.libstdcxx:libstdcxx universal
}

This is with including the active_variants 1.1 port group somewhere earlier in the portfile of course. Also I'm adding the dependency on libstdcxx because I'm assuming that require_active_variants only works with ports that are already in a port's dependency list.

No. perl doesn't even use the libstdcxx port, so it should not be a dependency.

[neverpanic (Clemens Lang)]

Replying to 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 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. zlib or kerberos5 are not affected, because ports using them should declare a dependency on them, which would cause MacPorts to ensure they are present in the required architecture(s).

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? Is it hard-coded into the ld64 source? While there are some hardcoded paths in the source, they point to /usr/lib and don't seem to cause this.

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to cal@…:

Replying to 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 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.

[larryv (Lawrence Velázquez)]

r105987 should fix this for perl5.12.

[larryv (Lawrence Velázquez)]

r105992 is a preemptive strike against the other Perls. America wins again.

[jeremyhu (Jeremy Huddleston Sequoia)]

There's not really anything we can do about this. This is how the toolchain works...

libstdc++.6.dylib is one of the more common culprits, and with the libgcc change, I've moved it out of ${prefix}/lib into ${prefix}/lib/libgcc. For now, however, we still have a symlink present in ${prefix}/lib, so that doesn't help us (but maybe eventually we can get rid of the symlink).

[ryandesign (Ryan Carsten Schmidt)]

Duplicate #57541 is about libxar.1.dylib while building gts.