Le 21 avr. 08 à 17:56, Sherm Pendley a écrit : On Mon, Apr 21, 2008 at 11:01 AM, Philip Hölzenspies <email@hidden> wrote:
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?"
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.
Since you're not passing an -arch flag to ld, the output defaults to the architecture on which ld is running. The error is telling you that a binary component for that architecture does not exist in the input libraries. For instance, if you're running on Intel, but the libraries are PPC-only.
In fact, according to man ld, ld first try to determine the arch using the linked objects, and then it defaults to the running arch:
The architecture for the output file is specified using the -arch option. If this option is not used, ld attempts to determine the output architecture by examining the object files in command line order. The first "thin" architecture determines that of the output file. If no input object file is a "thin" file, the native 32-bit architecture for the host is used.
So to determine what append, we should know what are the architectures of each objects, but the OP didn't give us any hint about them.
|