On Jul 26, 2008, at 1:50 PM, Dan Fandrich wrote:
>>
>
> Try --disable-shared to link the binary statically. It might also be
> that
> your self-compiled curl binary with debug symbols is using an old
> dynamic
> libcurl sitting elsewhere on your system. Not only could that cause
> problems
> with debugging, but it could also mean that you're encountering a
> bug that
> has long ago been fixed. See what 'ldd yourapp' (or the Mac OS X
> equivalent
> to ldd) says about which shared libraries its using. In any case,
> using
> --disable-shared, or linking your app with `curl-config --shared-libs`
> should solve that problem.

Thanks Dan. I feel pretty stupid as I should have known that, having
dealt with it in the past. Why I completely forgot it this time, I
don't know. However, when a library I compiled with debugging only
showed assembly, that should have been an immediate red flag that I
was not linking with what I thought was linking.

For the archives, the problem is that on OS X (and most Unix systems
in general I believe) the linker will search ALL library directories
including the system directories for a matching shared library. If it
finds one, that's what it will link with. Only after it has finished
searching all library directories will it go back and start searching
those directories for a static library. In my case, it was finding /
usr/lib/libcurl.dylib.

The solution in XCode is to pass "-search_paths_first <full path to
static library>" in the target's "Other Linker Flags". The -
search_paths_first flag will cause the linker to look for a static
library in the directory being searched before moving on to the next
directory, and specifying the static library by its full path will
ensure that the desired library is found.

(BTW, the OS X equivalent of ldd is otool -L yourapp)

Thanks again,

Wade
Received on 2008-07-31