blair at orcaware.com
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
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:
> 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.
> On Apr 16, 2008, at 12:19 , Blair Zajac wrote:
>> 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:
>> 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
More information about the macports-dev