makeicns does not build on Snow Leopard with libc++

[steven.dwyer@…]

The makeicns port does not link on Snow Leopard after following the LibcxxOnOlderSystems.

:info:build /opt/local/bin/clang++-mp-3.7 -o makeicns makeicns.o IconFamily.o NSString+CarbonFSRefCreation.o -L/opt/local/lib -Wl,-headerpad_max_install_names -stdlib=libc++ -arch i386 -framework Foundation -framework AppKit -framework Carbon -isysroot /Developer/SDKs/MacOSX10.6.sdk
:info:build MACOS_MAJOR = 10
:info:build MACOS_MINOR = 6
:info:build DARWIN_MAJOR = 10
:info:build SDK = /Developer/SDKs/MacOSX10.6.sdk
:info:build ld: library not found for -lc++
:info:build clang: error: linker command failed with exit code 1 (use -v to see invocation)
:info:build make: *** [makeicns] Error 1

I'm using clang-3.7 as my default compiler, with my modified section of macports.conf after following LibcxxOnOlderSystems looking like:

cxx_stdlib		libc++
buildfromsource		always
delete_la_files		yes
default_compilers	macports-clang-3.7 macports-clang-3.4 macports-clang-3.3 gcc-4.2 apple-gcc-4.2 gcc-4.0

I had to use the LibcxxOnOlderSystems guide as I was trying to install the mkvtoolnix port (for which makeicns is a pre-requisite).

[steven.dwyer@…]

Log file

[mf2k (Frank Schima)]

The Milestone field is for use by Macports team members only, please do not set it.

In the future, please Cc the port maintainers (port info --maintainers makeicns), if any.

[mkae (Marko Käning)]

pixilla, do you perhaps have a clue what's going on here? I don't even have SL anymore to test this.

[ryandesign (Ryan Carsten Schmidt)]

The error message says the libc++ library could not be found. Please confirm via port -v installed libcxx and port contents libcxx that you do in fact have the libcxx port installed, which is the port that would provide that library.

[ryandesign (Ryan Carsten Schmidt)]

Cc Me!

[mojca (Mojca Miklavec)]

I remember a similar experience from a different port. Most likely the problem is in -isysroot /Developer/SDKs/MacOSX10.6.sdk and the fact that libcxx has only been installed in /usr/local, but not in /Developer/SDKs/MacOSX10.6.sdk where the compiler is looking for it. As a consequence libc++ isn't found.

[jeremyhu (Jeremy Huddleston Sequoia)]

Yep, that's it exactly.

[ryandesign (Ryan Carsten Schmidt)]

Should the libcxx port maybe install into /Developer/SDKs/MacOSX10.6.sdk as well?

[jeremyhu (Jeremy Huddleston Sequoia)]

I'm not sure I like that idea because the SDK should really be used for targeting 10.6 in general. To add libc++ to it would be wrong since 10.6 doesn't have libc++. However, I don't really see a good alternative to that.

[jeremyhu (Jeremy Huddleston Sequoia)]

(well, short of updating these ports to not use the SDK unless they're explicitly told to).

[ryandesign (Ryan Carsten Schmidt)]

10.7 and 10.8 survive the existence of libc++ in their SDKs, right? Even though libc++ is not the default on those platforms? Surely nothing targeting the 10.6 SDK would have a problem with a few extra files being in there? Nothing targeting the 10.6 SDK would explicitly be looking for libc++ there. It would only be MacPorts with LibcxxOnOlderSystems, or users building for the 10.6 SDK manually and specifying -stdlib=libc++, who would take any note of those files.

[danielluke (Daniel J. Luke)]

Replying to ryandesign@…:

10.7 and 10.8 survive the existence of libc++ in their SDKs, right?

I think the issue is that if we mess with the SDK on a user's system and they go to build some other software (outside of MacPorts) and attempt to use the SDK, they could pick up the MacPorts lib unintentionally.

I seem to recall that you had a trick where you symlink'd an installed lib into the build directory to solve a similar problem a long time ago.

If we have to modify the sdk, maybe a portgroup that does (before configure) and un-does (after build) the modifications would be worthwhile?

[steven.dwyer@…]

Replying to ryandesign@…:

The error message says the libc++ library could not be found. Please confirm via port -v installed libcxx and port contents libcxx that you do in fact have the libcxx port installed, which is the port that would provide that library.

Not sure if it is still required but here is the output:

$ port -v installed libcxx
The following ports are currently installed:
  libcxx @3.7.1_0 (active) platform='darwin 10' archs='i386'

$ port contents libcxx
Port libcxx contains:
  /opt/local/var/system_roots/libcxx-3.7.1-0.tgz

[pixilla (Bradley Giesbrecht)]

Could the libcxx port provide an /Developer/SDKs/MacOSX10.6-libcxx.sdk that we could teach other ports to use?

[mojca (Mojca Miklavec)]

I don't know the system well enough, so I could be wrong, but I would imagine that one can only use a single folder for isysroot at a time. If MacPorts was to provide a special SDK, it would have to be full of symlinks to the original SDK. I find that way too complicated.

But also: if we were to provide support for libcxx on 10.5, we would somehow need to provide patches for SDK for 10.5 which is equally or perhaps even more "problematic".

One potential problem with patching SDK is that when user upgrades or (removes and) reinstalls Xcode, the changes/patches/files could be gone. But apart from that I feel that patching SDK is hardly any more intrusive than installing /usr/lib/libc++.dylib. (And in case of multiple instances of MacPorts, the files already conflict.)

Steven, can you please try to comment out the following line and try again?

build.env-append SDK=${configure.sdkroot}

[steven.dwyer@…]

Replying to mojca@…:

Steven, can you please try to comment out the following line and try again?

build.env-append SDK=${configure.sdkroot}

I tried that but it didn't seem to make any difference - the SDK never appears in the reporting of environment variables when debug is turned on.

Commenting out the if surrounding the above line:

#if {${configure.sdkroot} != ""} {
     build.env-append SDK=${configure.sdkroot}
#}

results in an empty SDK environment variable and a working build! It seems that ${configure.sdkroot} is empty.

[mojca (Mojca Miklavec)]

Ah, OK. It seems that SDK is used by default and you can only override it. (With an empty variable in this case which achieves the goal I wanted to achieve in a different way from what I envisioned.)

So a backup solution (if most people happen to be against patching the SDK) would be to avoid ever using SDK in MacPorts, at least in 10.6.

[ryandesign (Ryan Carsten Schmidt)]

Replying to mojca@…:

Ah, OK. It seems that SDK is used by default and you can only override it. (With an empty variable in this case which achieves the goal I wanted to achieve in a different way from what I envisioned.)

It sounds like a bug in the makeicns build system. It should not use an SDK if not instructed to do so.

So a backup solution (if most people happen to be against patching the SDK) would be to avoid ever using SDK in MacPorts, at least in 10.6.

I don't think that's what we want.

[mojca (Mojca Miklavec)]

An (utopic?) idea from soc2007/epimenov:

Tracelib can map / to SDK dir.

Example: We building port with SDK MacOSX10.2.8.sdk. gcc wants to use /usr/include/stdio.h and calls open(/usr/include/stdio.h), but tracelib returns open(/Developer/SDKs/MacOSX10.2.8.sdk/usr/include/stdio.h).

I have no clue whether that is or has ever been working, but if this is theoretically possible, one could reverse logic and when a port asks for libc++, trace mode could redirect from SDK to $prefix.

This is just wild brainstorming, unlikely to work, but who knows ...

In order to fix this particular problem though: is anyone willing to (conditionally or unconditionally) add something like

build.env-append SDK=""

to the port to let it build on 10.6/libc++?

[mojca (Mojca Miklavec)]

I committed r146686 as suggested in comment:17 because we have problem building a lot of ports on 10.6. We should probably still "fix" libc++ though.