kerberos5: using gettext opportunistically - failing if gettext is broken

[tim@…]

Kerberos build fails with Error: Unable to upgrade port: 1 I am attaching logfile

[Ionic (Mihai Moldovan)]

Next time, please remember to CC the port's maintainer(s), if any, and fill out the Port field.

---

This is not a kerberos5 problem per se.

msgfmt of port gettext fails because it still links against libncurses.5.dylib, which is now gone.

gettext is not listed as a dependency for kerberos5, though, and I don't have it on my list of trace mode violations either. I'm not sure why it's being used on your machine.

[ryandesign (Ryan Carsten Schmidt)]

compressed version of tim's log

[ryandesign (Ryan Carsten Schmidt)]

I replaced your uncompressed log attachment with a compressed version, to save space and bandwidth.

The error shown in the log is actually:

:info:build dyld: Library not loaded: /opt/local/lib/libncurses.6.dylib
:info:build   Referenced from: /opt/local/bin/msgfmt
:info:build   Reason: image not found

So it seems your gettext has already been rebuilt against ncurses 6, but for some reason you don't have ncurses 6. Did you perhaps deliberately deactivate ncurses 6 and reactivate ncurses 5? If so, reactivate ncurses 6.

I've added the forgotten gettext dependency to kerberos5 in r139737. No revbump, because gettext would already have been installed on user systems, because it was already a dependency of other kerberos5 dependencies.

[Ionic (Mihai Moldovan)]

Okay, but I wonder why I haven't seen gettext-related trace mode violations?

[ryandesign (Ryan Carsten Schmidt)]

gettext was already an indirect dependency before. Is that enough to have satisfied trace mode?

[Ionic (Mihai Moldovan)]

Nope, only direct dependencies are good enough. Looks like msgfmt was never executed on my system then. No idea why it does on the user's system. A hint may be autoreconf: configure.in: not using Gettext output by autoreconf, but that's just a guess.