libevent upgrades

Blair Zajac blair at
Wed Apr 16 09:59:04 PDT 2008


This is a dynamic library, the issue is that libevent renames the .dylib on each 
version upgrade.  Maybe they change the ABI so this is a way to force dependents 
to recompile?  I don't know off hand.

The current shared library is named


and binaries that use it end up with this name in the binary:

$ otool -L /opt/local/bin/memcached
         /opt/local/lib/libevent-1.4.2.dylib (compatibility version 3.0.0, 
current version 3.0.0)
         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
version 88.3.10)

So an upgrade to libevent 1.4.3 presumably will remove that libevent-1.4.2.dylib 

I don't see how MacPorts should handle this problem gracefully.

Agreed that it is a pain to update all dependents.  Presumably a simple 
recursive grep should be enough to find them all.


Brett Eisenberg wrote:
> Blair,
> Thanks.
> I presumed that depends_lib would track versions for static libraries, 
> to maintain state. I was also unaware that dylibs are broken compared to 
> normal shared libraries, live and learn.
> Noted, and I'll track down the rest of the dependencies. Bumping 
> revisions manually in all dependent ports (possibly maintained by 
> separate authors) seems broken.
> b
> On Apr 16, 2008, at 12:19 , Blair Zajac wrote:
>> Brett,
>> When you bump a libevent version, please bump the revision number on 
>> all packages that depend upon it since they will need to be recompiled.
>> Here's memcached after running with the libevent upgrade:
>> $ /opt/local/bin/memcached --help
>> dyld: Library not loaded: 
>> /Users/blair/my-macports/lib/libevent-1.3e.1.dylib
>>  Referenced from: /opt/local/bin/memcached
>>  Reason: image not found
>> Trace/BPT trap
>> I've bumped the revision number of memcached in r36063 to force a 
>> recompile.
>> Regards,
>> Blair
>> !DSPAM:48062721763465369021049!

More information about the macports-dev mailing list