Opened 9 years ago

Closed 2 years ago

Last modified 2 years ago

#35468 closed defect (wontfix)

nmh does not build with clang

Reported by: nooneofconsequence@… Owned by: kenh@…
Priority: Normal Milestone:
Component: ports Version: 2.1.2
Keywords: clang Cc: ryandesign (Ryan Schmidt), chrstphrchvz (Christopher Chavez)
Port: nmh

Description (last modified by ryandesign (Ryan Schmidt))

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

Attachments (1)

nmh_main.log (382.0 KB) - added by nooneofconsequence@… 9 years ago.

Download all attachments as: .zip

Change History (9)

Changed 9 years ago by nooneofconsequence@…

Attachment: nmh_main.log added

comment:1 Changed 9 years ago by ryandesign (Ryan Schmidt)

Cc: ryandesign@… added
Description: modified (diff)
Keywords: nmh gcc removed
Owner: changed from macports-tickets@… to kenh@…

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.

comment:2 in reply to:  1 Changed 9 years ago by 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.

comment:3 Changed 9 years ago by ryandesign (Ryan 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.

comment:4 in reply to:  3 ; Changed 9 years ago by 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.

comment:5 in reply to:  4 ; Changed 9 years ago by ryandesign (Ryan 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.

comment:6 in reply to:  5 Changed 9 years ago by 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.

comment:7 Changed 2 years ago by chrstphrchvz (Christopher Chavez)

Cc: chrstphrchvz added

comment:8 Changed 2 years ago by jmroot (Joshua Root)

Resolution: wontfix
Status: newclosed

Deleted in r151485.

Last edited 2 years ago by jmroot (Joshua Root) (previous) (diff)
Note: See TracTickets for help on using tickets.