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: Philip Hölzenspies <email@hidden>
- Date: Tue, 22 Apr 2008 11:20:28 +0100
Dear all,
Just a few reactions and a new summary.
Steve Checkoway wrote:
I haven't been following this at all, but I have no idea what you mean
by bsd calling conventions vs. ansi-c calling conventions vs
objective-
c calling conventions. A function call convention is generally
something that the hardware specifies. See <http://compilers.iecc.com/comparch/article/03-02-079
The calling conventions for systems on which OS X is supported are
described in <http://developer.apple.com/documentation/DeveloperTools/Conceptual/LowLevelABI/Introduction.html
I didn't actually say "bsd *calling* conventions," but pointed out
that we use BSD conventions to clarify why we use .so files. I just
wanted to get rid of the dylib discussion which was, in my opinion,
irrelevant to the question I was asking.
Jean-Daniel commented on the differences between dylib and so. Also,
he remarked that there is no calling convention enforced by either
one. We use .so files, because our compiler assumes .so files on all
architectures we use it for (it's not a production compiler, so the
support of multiple-architectures is merely research luxury).
Simon has already pointed out that there are indeed things like a
Pascal and a C calling convention, both of which have little to do
with the architecture (they're defined in an architecture independent
manner, but will have some different implications for different
architectures, e.g. the language conventions state whether the caller
or the callee is responsible for saving the contents of some
registers; which registers are actually preserved "through" a call is
determined - to my knowledge - by the architecture's calling
convention).
Also, Simon noted that it's unclear what all this has to do with
Xcode. I actually agree that it's unclear. The problem was that I did
not find a mailing list for Apple's ld and the xcode list was the
closest thing that I did find.
Right... a recap:
Leopard's ld is complaining that the provided .so files are not for
the right architecture. These .so files have been generated with the
same gcc/ld on the same system with the same CFLAGS and LDFLAGS
settings. The call to gcc (and therewith ld) is generated by a
compiler that still works perfectly on Tiger. ALL the input .so and .o
files identify themselves (both through 'file' and 'lipo') as 'thin'
x86 files (I manually checked them all). The machine on which this
problem occurs is an x86 machine.
Given these observations and constraints, ld should not be complaining
(if I understand the manpage correctly). However, it IS complaining.
Somewhere, it decided that it was looking for non-x86 binaries OR for
fat files OR it can't recognize these files as x86 binaries. My
question is: How can I find out where ld makes the decision to look
for an architecture that it can not file in <foo>.so? Is there a
higher level of verbosity concerning the architecture choice (as
opposed to the options wrt. paths to loaded files specified in the
manpage) that I have overlooked?
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