#32427: gdbm @1.10 +universal Build fails: merge error --------------------------------+------------------------------------------- Reporter: abarnert@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.0.3 Keywords: | Port: gdbm --------------------------------+------------------------------------------- Changes (by ryandesign@…): * cc: ryandesign@… (added) Comment: Replying to [comment:1 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. -- Ticket URL: <https://trac.macports.org/ticket/32427#comment:2> MacPorts <http://www.macports.org/> Ports system for Mac OS