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: Mon, 21 Apr 2008 17:33:25 +0200
Le 21 avr. 08 à 17:01, Philip Hölzenspies a écrit :
On Apr 10, 2008, at 5:04 PM, Chris Espinosa wrote:
On Apr 10, 2008, at 3:03 AM, Philip Hölzenspies wrote:
$ ld -r -o linked.o libMyListMod.so libMyListTree.so
ld: warning -arch not specified
ld: warning in libMyListMod.so, file is not of required architecture
ld: warning in libMyListTree.so, file is not of required
architecture
What's in these .so files? What created them? Try the 'file'
command, which will tell you whether they are indeed linkable
binaries.
If they're shared libraries (in which case, the Mac OS X convention
for file extension is '.dylib", not ".so"), then they should
probably follow, rather than precede, your object files on the link
line. And there don't seem to be any object code input files (.o
or .a). And the output of the linker is normally either a static
archive (.a) or a dynamic library (.dylib), or the executable for
an app or command-line tool.
So let's start from "What are you really trying to do?"
Dear Chris, Alastair, all,
I had a workshop all of last week, so my linking problem went on the
back-burner.
The problem I have with isolating an example is that people will
remain intent on trying to find a workaround for the example. I am
trying to learn how to interpret this linker message. All the .so
files that I include in the linking have been built with the same
gcc/ld and using the same CFLAGS and LDFLAGS variables.
The call to gcc I posted is generated by a compiler under
development, that compiles a high-level language down to c and hands
that to gcc. This is what I'm trying to do. Some of the intermediate
results are built to a /tmp/... directory, i.e. all referenced code
in /tmp/... is code from the same build-cycle.
With regards to the dylib/so discussion: I want to wash my hands of
it. Our compiler uses BSD conventions. I'm not quite sure on the
issue, but somehow I have this idea in the back of my mind that
dylib defaults to objective-c calling conventions. I actually
require ANSI-C calling conventions, because other stuff will be
linked against my libs. Mind you, a lot of the default Mac
installation comes with .so files (apache2, sasl2, openmpi, zsh,
pam, to name but a few examples).
dylib does not defaults to any calling convention. dylib is the darwin
Dynamic Library file format and it can contains C, Obj-C, C++, or
anything dyld understand.
Most of the .so files on OS X are not dynamic library, but bundle. You
may try to use the 'file' command on apache2 .so files
file /usr/libexec/apache2/mod_vhost_alias.so
/usr/libexec/apache2/mod_vhost_alias.so: Mach-O universal binary
with 4 architectures
/usr/libexec/apache2/mod_vhost_alias.so (for architecture ppc7400):
Mach-O bundle ppc
/usr/libexec/apache2/mod_vhost_alias.so (for architecture ppc64): Mach-
O 64-bit bundle ppc64
...
whitch is not the same than the 'file' output for a dylib (even a
dylib with a .so extension)
file /usr/lib/libz.dylib
/usr/lib/libz.dylib: Mach-O universal binary with 4 architectures
/usr/lib/libz.dylib (for architecture ppc7400): Mach-O dynamically
linked shared library ppc
/usr/lib/libz.dylib (for architecture ppc64): Mach-O 64-bit
dynamically linked shared library ppc64
....
That said, you are free to use .so instead of dylib, as long as you
library install_name match.
_______________________________________________
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