gettext +universal: gnu.gettext.DumpResource differs and cannot be merged

[alexoedelman@…]

After most recent update, port upgrade fails on gettext with:

Error: Target org.macports.destroot returned: /opt/local/lib/gettext/gnu.gettext.DumpResource differs in /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_gettext/work/destroot-i386 and /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_gettext/work/destroot-x86_64 and cannot be merged
Log for gettext is at: /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_gettext/main.log
Error: Unable to upgrade port: 1
Error: Unable to execute port: upgrade gettext failed

Force uninstall, clean, install does not help.

Installing -universal works.

Build log attached.

[alexoedelman@…]

Cc Me!

[jmroot (Joshua Root)]

Please remember to cc the maintainer, and note that you do not need to be in cc when you are the reporter.

[ryandesign (Ryan Carsten Schmidt)]

The relevant message in the log is

Target org.macports.destroot returned: /opt/local/lib/gettext/gnu.gettext.DumpResource differs in /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_gettext/work/destroot-i386 and /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_gettext/work/destroot-x86_64 and cannot be merged

But the latest update (r69669) did not change anything that would have caused this.

Could you please attach the two files mentioned so I can look at what's different about them?

Actually, I've never heard of the file gnu.gettext.DumpResource and do not have it in my gettext installation. If you have any idea why you have it, let me know.

[alexoedelman@…]

i386 version

[alexoedelman@…]

x86_64 version

[alexoedelman@…]

Attached. No idea why anything would have changed. Gettext has sat happily at the bottom of a giant heap of dependencies forever and only complained the other day.

(Sorry for not following reporting conventions.)

[rosssmith@…]

I'm getting this too:

$ sudo port upgrade gettext
--->  Computing dependencies for gettext
--->  Staging gettext into destroot
Error: Target org.macports.destroot returned: /opt/local/lib/gettext/gnu.gettext.DumpResource differs in /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_gettext/work/destroot-i386 and /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_gettext/work/destroot-x86_64 and cannot be merged
Log for gettext is at: /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_gettext/main.log
Error: Unable to upgrade port: 1
To report a bug, see <http://guide.macports.org/#project.tickets>

[ryandesign (Ryan Carsten Schmidt)]

Thank you, Alex, for the files, and Ross, for confirming this is not an isolated incident. Both files attached are x86_64 executables, which explains why we can't merge them. So we have two problems:

1. These files being built for the two of you but not for me or presumably some other users.
2. The files are being built for the native architecture even when we're intending to be cross-compiling for i386

We need to fix (1) by either building the files for all users or for no users. If we decide we do want to include these files, then we need to fix (2) as well.

[pgf]

I'm experiencing the same problem.

From two weeks I have an Intel based Mac Book Pro running Snow Leopard 10.6.4, Xcode 3.2.3 and the latest MacPorts release. I turned on the 64-bit kernel prior to installing anything.

I'm trying to install wine. gettext is already installed but when I request wine MacPorts starts reinstalling gettext. I think the installed version is for x86_64 platform but wine depends on the universal variant.

[alexoedelman@…]

On a hunch, I switched my compiler from gcc45 to gcc44. Gettext +universal built like a charm. I really don't know what to make of this.

[ryandesign (Ryan Carsten Schmidt)]

Thanks, Alex. That information was very helpful. I'll have this fixed in a moment.

[ryandesign (Ryan Carsten Schmidt)]

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.