gdbm @1.10 +universal Build fails: merge error

[abarnert@…]

I've tested this with two computers running Lion 10.7.2 and the 10.7.3 prerelease, both with Xcode 4.2.1. The 10.7.3 machine was a completely clean MacPorts installation; I just installed MacPorts and then did "sudo port selfupdate" and "sudo port install gdbm +universal".

Searching for information, I found ​http://stackoverflow.com/questions/8372001/macports-error-when-installing-gdbm which appears (at least at first glance) to be the same problem, but the reporter doesn't seem to have filed a ticket.

I've tried passing alternate values for configure.compiler, and get what appears to be the same error.

I can build the source distribution by following the instructions in the INSTALL file (the usual passing CC="gcc -arch i386 -arch x86_64" etc. to configure). The result is a universal binary that passes make check, and seems to work in a quick test from both 32-bit and 64-bit builds after installing it to /usr/local.

I tried figuring out the log output. There seem to be lots of harmless errors that occur in any project with .la files (e.g., a slew of errors from cp, lipo -info, etc.), and no indication of what the real error is... but it could be that the dependency_libs entries are different in the 32- and 64-bit versions of the .la file, possibly because somehow libiconv got picked up by the 64-bit configure but not the 32-bit one (even though I seem to have libiconv @1.14_0+universal)? I could be way off target here, but:

$ diff /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macpo\
rts.org_release_ports_databases_gdbm/gdbm/work/destroot-*//opt/local/lib/libgd\
bm.la
20c20
< dependency_libs=' -L/opt/local/lib -ldbm'
---
> dependency_libs=' -R/opt/local/lib -L/opt/local/lib /opt/local/lib/libintl.la \
/opt/local/lib/libiconv.la -lc -ldbm'

Anyway, build log attached.

[abarnert@…]

I found a fix that seems to work for me, although I don't know if it's the right way to do things.

Looking through the history, I found that a previous patch changed gdbm to "use muniversal". I don't know exactly what that means. Neither portgroup(7) nor the PortGroup section of the guide mentions muniversal. Googling macports.org turned up lots of discussion about past bugs with muniversal and patches to change specific ports to use it, but not an explanation of what/how/why it does. I started reading the portgroup definition in macports/sources, but it was too complex to figure out with a quick scan, so I figured I'd try to just un-muniversal the gdbm port and see if it works.

I did this by removing the PortGroup line and the if universal block inside post-patch. That seems to have changed it back to doing a simple (-arch i386 -arch x86_64) universal build instead of separate builds plus a merge, and the result seems to work. The libs are universal, the same test program that I used with my /usr/local build above worked just as well with /opt/local, and I was able to build and run a few other ports (with +universal) that depend on gdbm.

I'll attach the portfile.

[abarnert@…]

un-muniversal-ized version of gdbm portfile

[ryandesign (Ryan Carsten Schmidt)]

Replying to abarnert@…:

I found a fix that seems to work for me, although I don't know if it's the right way to do things.

Looking through the history, I found that a previous patch changed gdbm to "use muniversal".

Right, in r49956.

I don't know exactly what that means.

It means the port was switched to use the muniversal portgroup.

Neither portgroup(7) nor the PortGroup section of the guide mentions muniversal. Googling macports.org turned up lots of discussion about past bugs with muniversal and patches to change specific ports to use it, but not an explanation of what/how/why it does. I started reading the portgroup definition in macports/sources, but it was too complex to figure out with a quick scan,

We'll leave the matter of documenting muniversal to #32428.

so I figured I'd try to just un-muniversal the gdbm port and see if it works.

I did this by removing the PortGroup line and the if universal block inside post-patch. That seems to have changed it back to doing a simple (-arch i386 -arch x86_64) universal build instead of separate builds plus a merge, and the result seems to work. The libs are universal, the same test program that I used with my /usr/local build above worked just as well with /opt/local, and I was able to build and run a few other ports (with +universal) that depend on gdbm.

According to the commit message for r49956, the muniversal portgroup was used in order to resolve #19232. The ticket says "There is no apparent error with the old way, but muniversal is a safer option." That was three years ago when muniversal was new and shiny and we thought it solved all problems without any downsides, but you've clearly found a downside, and we've found others in other ports. So unless there's a reason to use muniversal, we shouldn't, and in this case there doesn't appear to be a reason.

I'll attach the portfile.

Could you please attach a unified diff instead? It makes it easier to review your proposed changes.

[ryandesign (Ryan Carsten Schmidt)]

And: thank you for your incredibly detailed investigation, and for even working out a solution.

[ryandesign (Ryan Carsten Schmidt)]

r88113.