[MacPorts] #25681: gettext +universal: gnu.gettext.DumpResource differs and cannot be merged
MacPorts
noreply at macports.org
Thu Jul 29 14:56:57 PDT 2010
#25681: gettext +universal: gnu.gettext.DumpResource differs and cannot be merged
-------------------------------------+--------------------------------------
Reporter: alexoedelman@… | Owner: ryandesign@…
Type: defect | Status: closed
Priority: Normal | Milestone:
Component: ports | Version: 1.9.1
Resolution: fixed | Keywords:
Port: gettext |
-------------------------------------+--------------------------------------
Changes (by ryandesign@…):
* status: assigned => closed
* resolution: => fixed
Comment:
The problem is that gettext looks for and, if found, uses a Java compiler
to compile its Java stuff into native executables. If gettext does not
find a Java compiler, or the Java compiler it finds is broken, gettext
ignores it and moves on. (I wish it had instead printed an error message;
we would have more quickly identified the problem.) Mac OS X does not
include a Java compiler. gcc45 and gcc46 have a working Java compiler but
gcc44's is broken; see #22066. If you "sudo gcc_select mp-gcc45" (or "sudo
gcc_select mp-gcc46") this creates a symlink /opt/local/bin/gcj which
gettext then finds and uses.
So we can't build these compiled Java programs all the time; doing so
would require declaring a dependency on e.g. gcc45 which would be way too
heavy a dependency for such an essential low-level library as gettext.
Therefore we should ensure these Java programs are never compiled to
native code, even if gcj is available. And this is how I fixed it in
r70100.
See also UsingTheRightCompiler for info about the general problems of
ports using whatever compiler they find and the reasons why we instead
want them to use a specific known-good compiler, and how that is
accomplished.
--
Ticket URL: <http://trac.macports.org/ticket/25681#comment:10>
MacPorts <http://www.macports.org/>
Ports system for Mac OS
More information about the macports-tickets
mailing list