Bug 10626 - talloc-2.1.1: unusable libraries because of an incorrect LC_ID_DYLIB
Summary: talloc-2.1.1: unusable libraries because of an incorrect LC_ID_DYLIB
Status: NEW
Alias: None
Product: TALLOC
Classification: Unclassified
Component: libtalloc (show other bugs)
Version: unspecified
Hardware: All Mac OS X
: P5 major
Target Milestone: ---
Assignee: Simo Sorce
QA Contact: Samba QA Contact
Depends on: 10885
  Show dependency treegraph
Reported: 2014-05-24 09:33 UTC by Axel Luttgens
Modified: 2020-10-27 23:17 UTC (History)
3 users (show)

See Also:

Steps to reproduce, additional info (5.92 KB, text/plain)
2014-05-24 09:33 UTC, Axel Luttgens
no flags Details
Suggested patch for bug 10626 (923 bytes, patch)
2020-10-26 16:27 UTC, Axel Luttgens
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Axel Luttgens 2014-05-24 09:33:55 UTC
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
   make install
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.
Comment 1 Douglas Bagnall 2020-10-22 03:06:04 UTC
Axel: still broken?
Otherwise we can close it as another OSX build mystery.
Comment 2 Axel Luttgens 2020-10-26 16:27:55 UTC
Created attachment 16309 [details]
Suggested patch for bug 10626
Comment 3 Axel Luttgens 2020-10-26 16:42:26 UTC
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 
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. ;-)

Comment 4 Douglas Bagnall 2020-10-27 23:17:43 UTC
Adding Ralph to the CC for Mac OSX expertise.