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 K.F. Hölzenspies <email@hidden>
- Date: Thu, 24 Apr 2008 15:08:27 +0200
Dear all,
A few gathered responses (I get the digest, so I just gather all
replies in a single mail):
Greg Guerin:
You're rather responding to a post as if it is first or second in a
thread. There was a considerable thread to come before it. If you
missed that and want to read up; I have all relevant digests archived
and I could send them to you, but to go and repeat the problem again
(multiple recaps and reformulations already) to the entire list seems
a bit crude.
Peter O'Gorman:
I was thinking about your earlier comments and I actually revoke the
notion of an 'over reduced' example. Even though the resulting object
file will be 'empty' (actually, it contains the header, so you could
see this as gathering dependencies), ld should still not complain
about it not being able to determin the architecture, should it?
Anyway, even a "ld -arch i386 -r -o foo.o bar.o" should work, even
though it is useless. I'll try and dig up an object file that I may
redistribute that produces this error when linking in this very
minimal way; that will probably ease the discussion somewhat (mind
you, this depends on the point in response to Ian).
Ian MacArthur:
You got me there; I actually didn't check relocatability and what not.
Like I said to Peter (above): I should try and find an object file
that does this (as opposed to a *shared* object file). Also, I will
try to find out more; maybe it *is* explicitly a problem with .so
files, in which case I should come up with some sort of "ld -arch i386
-o main main.o libMain.so" example.
Steve Checkoway & Jonas Maebe:
After the point you made, Steve, I started doubting myself. With some
spare time, I went leafing through X3.159-1989 and you were actually
right. I thought the __cdecl stemmed from this document, but it
didn't. The part I had in mind was section 7.6 on the setjmp.h from
the standard library that provides means to store and restore
environments when doing long jumps. Function calls are (in the
flattest possible sense) long jumps, but this part of the standard
library only provides means to do them, it doesn't enforce anything.
Jonas' intuition is much the same as mine; the callee doesn't know the
number of parameters, so it "can't" clean up. This is, of course,
technically not true; compilers could compile a function call such
that on top of all the arguments is the number of elements pushed onto
the stack to do the call. In this way, the callee could clean 'itself'
up. I think we could agree that this is a very unwise way of
implementing, but there might be merrits to this in JIT compilation,
or some form of simulated ad-hoc inlining.
Anyway: the conclusion: it is indeed not part of the code. When I said
"ANSI-C calling convention," I actually meant to say __cdecl.
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