RE: Load commands in 10.7 dylib block install_name_tool on 10.6
RE: Load commands in 10.7 dylib block install_name_tool on 10.6
- Subject: RE: Load commands in 10.7 dylib block install_name_tool on 10.6
- From: "Dallman, John" <email@hidden>
- Date: Thu, 08 Sep 2011 15:18:50 +0000
- Thread-topic: Load commands in 10.7 dylib block install_name_tool on 10.6
> You don't need install_name to respect theses constaints, just use a
> relative path in your dynamic library.
I am not in control of what the customers do, and sometimes they confuse
themselves very skilfully. We already tell them about the relative paths,
and they still get into trouble. Making then set install names seems to
work much better.
thanks,
--
John Dallman
-----Original Message-----
From: Jean-Daniel Dupas [mailto:email@hidden]
Sent: 08 September 2011 16:04
To: Dallman, John
Cc: email@hidden
Subject: Re: Load commands in 10.7 dylib block install_name_tool on 10.6
Le 8 sept. 2011 à 15:51, Dallman, John a écrit :
> I'm trying to build a dylib from C code on Mac OS X 10.7 with Xcode 4.1 and Clang,
> which needs to be usable by software developers working on 10.6.
>
> I am working at the command line, rather than with Xcode, because my C code is
> generated from a source language that Xcode doesn't understand.
>
> I compile with
>
> -isysroot /Developer/SDKs/MacOSX10.6.sdk -mmacosx-version-min=10.6
>
> That produces me a dylib that runs on 10.6. But when I try to use the 10.6 version of
> install_name_tool on this dylib, it refuses, with
>
> install_name_tool: object: libpskernel.dylib malformed object (unknown load command 8)
>
> Using otool -l to list the load commands in the dylib, there seem to be two load commands
> that the 10.7 linker is using, and the 10.7 otool can decode, but which the 10.6 versions
> of otool, install_name_tool, and so on don't understand. They are:
>
> LC_VERSION_MIN_MACOSX
> LC_FUNCTION_STARTS
>
> While the 10.7 ld's manpage lists options for suppressing some LC_ commands, I can't
> find anything in it about these ones.
>
> I'm using 10.6.6 and 10.7. The reason I need developers working on 10.6 to be able to
> use install_name_tool on my dylib is that it is not part of a framework, and it is
> necessary for several different applications installed on the same machine to be able
> to have their own copies of it, and update them without interfering with each other.
> So there isn't, and can't be, a canonical place in the filesystem for it to live in.
>
You don't need install_name to respect theses constaints, just use a relative path in your dynamic library.
And if a fixed relative path (using @loader_path) is not enough, just use @rpath.
http://www.dribin.org/dave/blog/archives/2009/11/15/rpath/
> Googling hasn't shown me much, but suggests that these LC_ values were added during
> the life of 10.6. I've tried otool -l on a 10.6.8 machine, but it still
> doesn't understand these new LC_ commands.
>
> I had similar problems building on 10.6 for backwards compatibility to 10.5, with
> different then-new LC_ commands. That cost me an Apple technical support incident
> to find out that the ld option -no_compact_linkedit was what was needed, but that
> doesn't help with this problem.
>
> Can anyone suggest a way of suppressing these new LC_ commands?
>
> thanks,
-- Jean-Daniel
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden