Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Porting from Linux, plug-ins that depend on other plug-ins

On 04/05/2004 at 1:32 PM, Shantonu Sen <email@hidden> wrote:

> You need to use the -dylib_file linker option, as documented in the
> ld(1) man page. This will provide an alternate physical path for an
> install name while ld is resolving dependencies recursively.

I read about the dylib_file linker option earlier today. However, while
that option does solve the problem of having to install the indirectly
referenced dynamic libraries, I still need to explicitly specify them to
the linker.

What I'm really trying to find, and didn't make clear earlier, is a
solution where I don't have to specify the indirectly referenced dynamic
libraries to the linker in any fashion and I don't have to install them.
Is this even possible?

I hope this is possible since having to explicitly specify the
indirectly reference dynamic libraries to the linker somewhat violates
the insulation of my component-based system. That is, if I change a
framework such that it links against a new framework, other frameworks
that link against the original framework have to change the options
passed to the linker when they are built in order to specify this new
dependency. I had hoped such a change would be transparent to these
other frameworks.

Thanks!

geoff


> On May 4, 2004, at 12:49 PM, Geoffrey Schmit wrote:
>
>> On 03/05/2004 at 11:03 AM, email@hidden wrote:
>>
>>> Doing this I noticed that when I link one of my .dylib files I have
>>> to string out every single other library name they reference in
>>> order to avoid undefined references. The Linux linker only seems to
>>> require you to list the top-level dependencies.
>>>
>>> ...
>>>
>>> When I build each library I setup the -o to be the full pathname of
>>> where the library is to be loaded from, so the install names of each
>>> library should have the info the linker needs to find them.
>>>
>>> Is there any way to make this process a bit simpler so that all the
>>> indirect references don't need to be listed?
>>
>> I ran into what may be a similar situation yesterday, but my
>> experience was slightly different. Regardless, it may help.
>>
>> I was getting warnings that ld couldn't open the indirectly
>> referenced dynamic library followed by undefined symbols errors. My
>> problem, however, was that the indirectly referenced dynamic library
>> was not installed. These dynamic libraries are built in a difference
>> location than where they are installed. When they are linked, the -
>> install_name option is used to specify where they will be installed.
>> If I installed the dynamic libraries, ld would find the indirectly
>> reference dynamic library and successful complete the link operation.
>> I did not need to explicitly specify the indirectly referenced
>> dynamic library. I'm working on Mac OS X 10.3.3 which may make a
>> difference.
>>
>> I'm still trying to find a way to successfully link without having to
>> install the indirectly referenced dynamic libraries first....
>>
>> BTW, I would be wary of building everything with the -flat_namespace
>> option since you may run into multiple-symbol-definition problems.
_______________________________________________
darwin-development mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-development
Do not post admin requests to the list. They will be ignored.

References: 
 >Re: Porting from Linux, plug-ins that depend on other plug-ins (From: Shantonu Sen <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.