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: Mon, 21 Apr 2008 16:01:55 +0100
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).
In short: does anybody know whether there is a way to find out what
architectures ld is looking for and when/why/where it made that
decision? Just to make it clear: I don't want a workaround for my
current specific problem, but I want to understand how to solve this
class of problems in the future.
Kind 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