Created attachment 9974 [details] Steps to reproduce, additional info Overview: 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 configure make make install steps. See attachment. Actual Results: The libraries are built with LC_ID_DYLIB showing rather strange paths. Expected Results: 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
Hello Douglas, 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 /_ROOT/talloc/lib/libtalloc.2.3.1.dylib: Mach header magic cputype cpusubtype caps filetype ncmds sizeofcmds flags 0xfeedfacf 16777223 3 0x00 6 14 1504 0x00100085 [...] Load command 3 cmd LC_ID_DYLIB cmdsize 64 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. ;-) HTH, Axel
Adding Ralph to the CC for Mac OSX expertise.