[MacPorts] #32427: gdbm @1.10 +universal Build fails: merge error
MacPorts
noreply at macports.org
Tue Dec 6 01:10:15 PST 2011
#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
More information about the macports-tickets
mailing list