Created attachment 9974 [details]
Steps to reproduce, additional info
Running the configure/make system yields libraries with an incorrect LC_ID_DYLIB.
As a result, no project may be linked against those libraries.
A corrective action is possible (see attachment), but this is probably the tree hiding the forest...
Steps to Reproduce:
Just perform the usual
The libraries are built with LC_ID_DYLIB showing rather strange paths.
LC_ID_DYLIB should reflect the installation path.
Build Date & Platform:
I met the problem a week ago, when I needed talloc for building a project that relies on it.
This is on Mac OS X 10.8.5, but I suspect the problem could happen on any other version of the OS.
Axel: still broken?
Otherwise we can close it as another OSX build mystery.
Created attachment 16309 [details]
Suggested patch for bug 10626
Yes, the problem is still there, unfortunately.
Attached patch proposal seems to solve the problem.
For example, after having configured with --prefix=/_ROOT/talloc, the installed dylibs now have a right LC_ID_DYLIB; eg:
$ otool -l /_ROOT/talloc/lib/libtalloc.2.3.1.dylib
magic cputype cpusubtype caps filetype ncmds sizeofcmds flags
0xfeedfacf 16777223 3 0x00 6 14 1504 0x00100085
Load command 3
name /_ROOT/talloc/lib/libtalloc.2.3.1.dylib (offset 24)
time stamp 1 Thu Jan 1 01:00:01 1970
current version 0.0.0
compatibility version 0.0.0
The patch achieves this by passing the relevant -install_name option to the linker.
Without such an option, the LC_ID_DYLIB value defaults to the path passed in the -o option, that is the path where the dylib is created.
Of course, it could well be that I've overlooked something, and that the patch introduces some side effects. But the idea is there. ;-)
Adding Ralph to the CC for Mac OSX expertise.