Re: thin linking: "file is not of required architecture"
Re: thin linking: "file is not of required architecture"
- Subject: Re: thin linking: "file is not of required architecture"
- From: Jean-Daniel Dupas <email@hidden>
- Date: Fri, 25 Apr 2008 18:12:05 +0200
As you see, the absolute library path is saved into your executable.
This path is generated by the linker using the "install name" of each
library you link on.
And this "install name" is created when you link your libraries.
For example:
you have a library libCommandLineMod.so
When you create it, you have to pass the install_name as argument
ld -install_name "/install/name/path/libCommandLineMod.so" -o
libCommandLineMod.so ....
Then when you link an executable using this library, ld will add a
dependency to "/install/name/path/libCommandLineMod.so" (wherever the
library is at build time)
And when you launch this executable, dyld will search the /install/
name/path/libCommandLineMod.so library.
The install_name can be relative too. Prior to 10.4 it was possible
to precise a path relative to the executable using the
@executable_path keyword.
-install_name "@executable_path/lib/libCommandLineMod.so"
Tiger (10.4) introduced the @loader_path keyword that allows to
defined a path relative to the loader (for example a path relative to
a bundle or an other library)
And 10.5 introduced the @rpath concept. (see dylib release note for
details: http://developer.apple.com/releasenotes/DeveloperTools/RN-
dyld/ )
Le 25 avr. 08 à 15:54, Philip K.F. Hölzenspies a écrit :
Dear Ian, Peter, all,
Relocatability was, indeed, the problem. As a matter of fact; the
build system had explicit -bundle flags in different places. Changing
them to -dylib fixed this (btw. gcc seems to take -dynamiclib which
seems to correspond with ld's -dylib; the ld manual refers to
-dynamiclib, but actually never explains what it is).
Peter, you mentioned something about a bug you filed. Did you file
this invalid error message as a bug (because the error message *is*
wrong)? If not, should I?
I'm just a very simple unix guy, so to me there are objects (possibly
grouped in archives which are sometimes referred to as "static
(link) libraries" and shared objects ("dynamic libraries"). The bundle
thing confuses me. In the Tiger version of the compiler, all generated
shared objects are actually bundles. When I query the final executable
with "otool -L", the only anser is:
% otool -L a.out
a.out:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 88.3.10)
If I query the version from my Leopard machine (where I changed the
-bundle flags to -dy(namic)lib), the answer lists all .so files that
our compiler offered to the linker (I still need to get into dead-link
elimination, because most of them are not actually used).
Weird new problem, though; when I start the application, the dynamic
linker can't find the libraries:
% ./a.out
dyld: Library not loaded: lib/libCommandLineMod.so
[snip]
I wanted to (again) reduce this to something simple, so I have a
reduced example, now, that is linked as follows:
% ld -arch i386 -o a.out main.o *.{so,a} /usr/lib/libc.dylib /usr/
lib/crt1.o
Where I have now copied all .so and .a files that I actually need to
the current directory. This links fine, but still gives the above
error upon execution. If I create a symlink, everything works:
% ln -s . lib
% ./a.out
Hello, World!
The problem seems to be that "lib/" has been recorded as part of the
shared object's name. Adding '-rpath .' doesn't actually help. How
does the recording of paths to required objects work for run-time
reference?
Thanks so much for all input already... I would just like to get this
last thing working. It all works if I fill my DYLD_LIBRARY_PATH with
all relevant lib directories, but that shouldn't actually be required
(it isn't on other platforms; if I ldd the resulting binary on linux,
the fully qualified path is in the resource table).
Regards,
Philip
_______________________________________________
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
_______________________________________________
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