[112937] trunk/dports/gnome/gconf/Portfile

[Ryan Schmidt]

On Nov 4, 2013, at 13:42, Blair Zajac wrote:

> On 11/04/2013 11:35 AM, Ryan Schmidt wrote:
>> 
>> On Nov 4, 2013, at 13:22, blair at macports.org wrote:
>> 
>>> Revision
>>> 112937
>>> Author
>>> blair at macports.org
>>> Date
>>> 2013-11-04 11:22:31 -0800 (Mon, 04 Nov 2013)
>>> Log Message
>>> 
>>> gconf: rebuild due to library reversioning libsasl2.2 -> libsasl2.
>>> 
>>> --->  Scanning binaries for linking errors: 34.3%
>>> Could not open /opt/local/lib/libsasl2.2.dylib: Error opening or reading file (referenced from /opt/local/lib/GConf/2/libgconfbackend-evoldap.so)
>> 
>> Looks like this would only occur if the +openldap variant of gconf was selected, and only if it was overlinked (i.e. ports had not been reinstalled since MacPorts 2.2).
> 
> Yes, this is a Mac running MacPorts for a long while.
> 
> Overlinked means what?

gconf (with the openldap variant) links with libldap. libldap links with libsasl2. But because of how libtool works and because it lists all used libraries in the dependency_libs line of .la files, gconf (with the openldap variant) would end up linked to libsasl2, even though it doesn’t itself use libsasl2. That’s overlinking. And it means that even though gconf (with the openldap variant) doesn’t directly use libsasl2, it breaks when libsasl2’s install_name changes.


> Are you saying something changed in the mean time?

MacPorts 2.2 was released which clears the dependency_libs line (on Mountain Lion and earlier) or deletes the .la file entirely (on Mavericks and later). But the overlinking doesn’t stop until all ports have been rebuilt with 2.2. For example, you could rebuild gconf (with the openldap variant) as many times as you like under 2.2 and it would still be overlinked unless you had first rebuilt openldap under 2.2.


> Shouldn't that have been a rev-bump somewhere previously?

I had wanted to rebuild all ports en-masse after updating to 2.2 to solve this problem all at once, but Joshua thought that was overkill, so yes, from now until eternity, we get to manually discover these problems and revbump these ports.

I’m still of the opinion that we don’t need to revbump ports that are only affected by this issue in their non-default variants, because rev-upgrade will rebuild them automatically. The reason why revbumping ports affected by this issue in their default variants is important is that we provide binary packages, and it’s dumb if users download a binary package that’s broken which then immediately has to be rebuilt to fix the brokenness.