nmh does not build with clang

[nooneofconsequence@…]

the workaround mentioned on the hotlist: wiki:ProblemHotlist

to specify gcc: like

configure.compiler=llvm-gcc-4.2

works, so here is the ticket for making it work with clang (the new default compiler).

The HotList recommends reading this for help: wiki:PortfileRecipes#compiler

[ryandesign (Ryan Carsten Schmidt)]

Remember to use WikiFormatting and TracLinks.

The error in the log is just:

:info:build Undefined symbols for architecture x86_64:
:info:build   "_libiconv_close", referenced from:
:info:build       _decode_rfc2047 in libmh.a(sbr_libmh_a-fmt_rfc2047.o)
:info:build   "_libiconv_open", referenced from:
:info:build       _decode_rfc2047 in libmh.a(sbr_libmh_a-fmt_rfc2047.o)
:info:build   "_libiconv", referenced from:
:info:build       _decode_rfc2047 in libmh.a(sbr_libmh_a-fmt_rfc2047.o)
:info:build ld: symbol(s) not found for architecture x86_64

So instead of changing the compiler, we should just make sure "-L${prefix}/lib" gets into LDFLAGS.

[kenh@…]

Replying to ryandesign@…:

So instead of changing the compiler, we should just make sure "-L${prefix}/lib" gets into LDFLAGS.

... which we can't do, because that might bring in MacPorts cyrus-sasl2, which is busted for Kerberos support.

[ryandesign (Ryan Carsten Schmidt)]

... oh, I had forgotten we were deliberately doing that in this port. In that case, you'll have to find some other way to inform nmh where libiconv is located. One way might be to change "-liconv" to "/opt/local/lib/libiconv.dylib". There might be other ways, perhaps with an environment variable like you already do for OpenSSL.

As an aside, is there any way we could fix whatever is busted about cyrus-sasl2 and kerberos so that we would not have to do these workarounds? That would seem to be the best solution of all.

[kenh@…]

Replying to ryandesign@…:

... oh, I had forgotten we were deliberately doing that in this port. In that case, you'll have to find some other way to inform nmh where libiconv is located. One way might be to change "-liconv" to "/opt/local/lib/libiconv.dylib". There might be other ways, perhaps with an environment variable like you already do for OpenSSL.

As an aside, is there any way we could fix whatever is busted about cyrus-sasl2 and kerberos so that we would not have to do these workarounds? That would seem to be the best solution of all.

I'll play around with it a bit more.

The basic problem with cyrus-sasl2 is that it's linking against MacPorts Kerberos instead of the system Kerberos; according to the MacPorts FAQ, Kerberos is one of the exceptions to the "always link with MacPorts versions of libraries" rule. The explanation for this is long and complicated, but the short answer is that third-party Kerberos libraries are not interoperable with the MacOS Kerberos implementation.

[ryandesign (Ryan Carsten Schmidt)]

Replying to kenh@…:

The basic problem with cyrus-sasl2 is that it's linking against MacPorts Kerberos instead of the system Kerberos; according to the MacPorts FAQ, Kerberos is one of the exceptions to the "always link with MacPorts versions of libraries" rule. The explanation for this is long and complicated, but the short answer is that third-party Kerberos libraries are not interoperable with the MacOS Kerberos implementation.

If we can find a way to make cyrus–sasl2 link with OS X kerberos, even if MacPorts kerberos is already installed, then we should do that.

[kenh@…]

Replying to ryandesign@…:

If we can find a way to make cyrus–sasl2 link with OS X kerberos, even if MacPorts kerberos is already installed, then we should do that.

I can take a look at that, if you want. It might require some autoconf surgery, though.

[jmroot (Joshua Root)]

Deleted in r151485.