#35468: nmh does not build with clang ------------------------------------------+--------------------------------- Reporter: nooneofconsequence@… | Owner: kenh@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.2 Keywords: clang | Port: nmh ------------------------------------------+--------------------------------- Changes (by ryandesign@…): * cc: ryandesign@… (added) * keywords: nmh clang gcc => clang * owner: macports-tickets@… => kenh@… Old description:

the workaround mentioned on the hotlist: https://trac.macports.org/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: https://trac.macports.org/wiki/PortfileRecipes#compiler

New description: 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 -- Comment: 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. -- Ticket URL: <https://trac.macports.org/ticket/35468#comment:1> MacPorts <http://www.macports.org/> Ports system for Mac OS

#35468: nmh does not build with clang ------------------------------------------+--------------------------------- Reporter: nooneofconsequence@… | Owner: kenh@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.2 Keywords: clang | Port: nmh ------------------------------------------+--------------------------------- Comment(by 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. -- Ticket URL: <https://trac.macports.org/ticket/35468#comment:3> MacPorts <http://www.macports.org/> Ports system for Mac OS

#35468: nmh does not build with clang ------------------------------------------+--------------------------------- Reporter: nooneofconsequence@… | Owner: kenh@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.2 Keywords: clang | Port: nmh ------------------------------------------+--------------------------------- Comment(by ryandesign@…): Replying to [comment:4 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. -- Ticket URL: <https://trac.macports.org/ticket/35468#comment:5> MacPorts <http://www.macports.org/> Ports system for Mac OS