• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Dylib Dependencies (again)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Dylib Dependencies (again)


  • Subject: Re: Dylib Dependencies (again)
  • From: Dave <email@hidden>
  • Date: Fri, 8 Jun 2007 18:39:18 +0100

H Greg,

Thanks for your time on this.

I was mistaken when I said it didn't work before! After I had run install_name_tool on the 3rd Party Universal File, the dependency name in the bundle file changed from being a long path name to a single name "libfpacore2_uni.dylib" and the script I was using to replace the path didn't handle the case of just a file name. I fixed the script and re-ran everything and it seems to be working. I will ship it to our beta testers on Monday, but it worked ok on both the machines here.

Here are the commands:

lipo -create libfpacore2_ppc.dylib libfpacore2_x86.dylib -output libfpacore2_uni.dylib
install_name_tool -id libfpacore2_uni.dylib libfpacore2_uni.dylib


I hadn't realized that you had to set the name in the Target Dynamic Library, I was just setting the path in the bundle file.

Hopefully this mystery has been solved. Thanks again for your efforts I really appreciate them.

All the Best
Dave

On 8 Jun 2007, at 18:33, Greg Guerin wrote:

Dave wrote:

Which shows the correct dependency file path for the Bundle File
(@loader_path/../../../../DynamicLibraries/libfpacore2_uni.dylib). If
I run this on a PowerPC the Bundle and the 3rd party library work ok.

I copied it onto an intel machine and it failed to load. When I
looked at the path with otool, the file path had not been set
correctly or rather had been left unchanged.

First, thanks for posting all the output. It helped clarify things a lot.
It also confirmed that install_name_tool isbehaves the same on your machine
as on mine: it sets the names of all sub-libs in a fat lib-file.


What I'd like to see next, please, is the output of this cmd:
  otool -L -arch all FPALibrary

I can see from your posted output that the ppc version of the lib is
correct, as you explained. However, if you're still not getting it to work
on i386, you can use the '-arch all' option with -L to inspect the i386
names, even though the bundle is still on the PPC box. It's not necessary
to transfer files to the Intel-based Mac just to see the i386 lib- names
that FPALibrary refers to.


  -- GG


_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40looktowindward.com


This email sent to email@hidden

_______________________________________________ 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
References: 
 >Re: Dylib Dependencies (again) (From: Greg Guerin <email@hidden>)

  • Prev by Date: Re: Dylib Dependencies (again)
  • Next by Date: Re: Universal Binaries
  • Previous by thread: Re: Dylib Dependencies (again)
  • Next by thread: Xcode CVS compare problem
  • Index(es):
    • Date
    • Thread