BUG: 'howl' will break 'gnome-vfs' when installed

[danchr@…]

Summary: gnome-vfs has the capability to support zeroconf through the howl library. This hasn't been explicitely disabled in the port file, so configure will detect it's precense and enable it. However, 'gnome-vfs' uses the functions salt_lock() and salt_unlock(), which the Mac OS X version of howl does not supply.

Steps to reproduce:

1. Install howl
2. Attempt to configure and compile gnome-vfs

Actual results: 'gnome-vfs' will fail at the linking stage complaining that several symbols from CoreFoundation, _salt_lock and _salt_unlock aren't defined.

Expected results: 'gnome-vfs' installs, either with or without zeroconf support, but it should install nonetheless.

Possible resolution: I see several possible solutions for this. The easiest solution would be to disable howl support in gnome-vfs. Another solution would be to force howl to use the non-Mac OS X implementation even on Mac OS X, and a third solution would be to actually solve the issues with the Mac implementation.

Cc'ing the howl maintainer.

[mww@…]

I dont think fixing Apple's zeroconf lib is the way to go; reagarding the other two solutions, I do not have a preference.

[mww@…]

totally sorry - just realized the problem here... salt_lock & friends lock/unlock a mutex - the OS-X implementations sw_salt struct though does not have the mentioned mutex; so we could perhaps happily hack some non-sense functions in there, if the locking really is unnecessary on OS-X/Darwin...

/*-posix-version-*/ sw_result sw_salt_lock( sw_salt self ) {

sw_assert(self); pthread_mutex_lock(&self->m_mutex);

}

[danchr@…]

(In reply to comment #2)

totally sorry - just realized the problem here...

Yes, that's what I figured out it was too. I remember also having issues with gnome-vfs not linking against CoreFoundation, and thus complaining that CF*-symbols where missing.

[danchr@…]

Taking. Patch coming up.

[danchr@…]

Fixed by the fix for the blocking bug. Sorry about the spam.