brett at macports.org
Wed Apr 16 10:05:11 PDT 2008
That makes sense. I'll get the dependents revisions updated, and for
future releases see about patch libevent to embed the version
information into the library. Apologies for the confusion.
On Apr 16, 2008, at 12:59 , Blair Zajac wrote:
> 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
> 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 file.
> 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
>>> Here's memcached after running with the libevent upgrade:
>>> $ /opt/local/bin/memcached --help
>>> dyld: Library not loaded: /Users/blair/my-macports/lib/
>>> 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