#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