Opened 14 years ago

Closed 14 years ago

#25681 closed defect (fixed)

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

Reported by: alexoedelman@… Owned by: ryandesign (Ryan Carsten Schmidt)
Priority: Normal Milestone:
Component: ports Version: 1.9.1
Keywords: Cc:
Port: gettext

Description

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.

Attachments (3)

main.log (479.0 KB) - added by alexoedelman@… 14 years ago.
gnu.gettext.DumpResource (32.8 KB) - added by alexoedelman@… 14 years ago.
i386 version
gnu.gettext.2.DumpResource (32.8 KB) - added by alexoedelman@… 14 years ago.
x86_64 version

Download all attachments as: .zip

Change History (13)

Changed 14 years ago by alexoedelman@…

Attachment: main.log added

comment:1 Changed 14 years ago by alexoedelman@…

Cc: alexoedelman@… added

Cc Me!

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

Cc: alexoedelman@… removed
Owner: changed from macports-tickets@… to ryandesign@…

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

comment:3 Changed 14 years ago by ryandesign (Ryan Carsten Schmidt)

Summary: gettext 0.18.1.1 staging into destroot failsgettext +universal: gnu.gettext.DumpResource differs and cannot be merged

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.

Changed 14 years ago by alexoedelman@…

Attachment: gnu.gettext.DumpResource added

i386 version

Changed 14 years ago by alexoedelman@…

Attachment: gnu.gettext.2.DumpResource added

x86_64 version

comment:4 Changed 14 years ago by 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.)

comment:5 Changed 14 years ago by 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>

comment:6 Changed 14 years ago by ryandesign (Ryan Carsten Schmidt)

Status: newassigned

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.

comment:7 Changed 14 years ago by 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.

comment:8 Changed 14 years ago by 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.

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

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

comment:10 Changed 14 years ago by ryandesign (Ryan Carsten Schmidt)

Resolution: fixed
Status: assignedclosed

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.

Note: See TracTickets for help on using tickets.