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: Greg Guerin <email@hidden>
- Date: Wed, 23 Apr 2008 10:25:34 -0700
Philip K.F. Hölzenspies wrote:
> I have downloaded one of the Xcode-3.1 beta versions so may have
a newer
> ld version to you.
The release notes tell you:
1. That Xcode 3.1 beta is under NDA, not for public discussion.
2. How to communicate with Apple about the beta.
3. How to file bug-reports.
Here is an attempt to reproduce:
>
> mb% echo 'int x=1;' > x.c
> mb% echo 'int y=1;' > y.c
> mb% echo 'extern int x,y; int main() { return x+y;}' > main.c
> mb% cc -dynamiclib -o libx.so x.c
> mb% cc -dynamiclib -o liby.so y.c
> mb% ld -r -o z.o libx.so liby.so
> ld warning: -arch not specified
> mb% cc -c main.c
> mb% ld -o main libx.so liby.so main.o /usr/lib/crt1.10.5.o -lSystem
> mb% ./main
> mb% echo $?
> 2
> mb% ld -v
> @(#)PROGRAM:ld PROJECT:ld64-83.2
If this attempt to reproduce would actually reproduce my errors, the
linker would be broken for any and every link attempt. This it clearly
is not.
What error is it attempting to reproduce? What do you want to happen
that isn't happening?
Judging by the warning, 'ld -r' is not working, but you never attempt
to use "z.o", so we can't tell what the actual problem is. The most
obvious solution would be to eliminate the 'ld -r' line completely,
as it does nothing that is subsequently used or needed, and simply
emits a spurious warning.
This works:
cc -c -o libx.so x.c
cc -c -o liby.so y.c
ld -r -o z.o libx.so liby.so
and the file "z.o" is produced without warnings. Subsequently, this
works:
cc -c main.c
cc -o main z.o main.o
and the resulting executable ./main runs correctly.
If these changes do not embody what you want to accomplish with 'ld -
r', then please explain in more detail what you are trying to do.
> Now the 'ld warning: -arch not specified' for the ld -r is simply
> because there were no actual input files (the shared libraries
are not
> included in the output) so ld could not guess the arch.
This is the wrong diagnosis. The original 'ld -r' has two existing
input files, both clearly visible with 'ls'. An output file is
produced, z.o, which appears to work when actually used to produce an
executable. Ld's warning message is simply irrelevant.
Compile with 'cc -c' instead of 'cc -dynamiclib' and the apparent
problem disappears (ld no longer complains), because now ld's input
files are a different type This has nothing to do with arch, and
everything to do with Mach-O file type.
The 'file' command tells you the type. I suggest running it on
the .so's produced by 'cc -dynamiclib' and then again on the .so's
from 'cc -c'. You may also want to apply the 'nm' command to each
compile's .so's.
The shouting clearly didn't help either... like I said, the .so-only
example was over reduced to be functional. The point is not to simply
link two .so files. If you want to see the whole problem, I'll repaste
my gcc-call:
gcc -arch i386 -Wall -no-cpp-precomp -Wno-unused -fno-builtin -arch
i386 -Isac2c/include/ -Lsac2c/lib/ -L/tmp/SAC_nwXADZ -O3 -o
quicksort_list quicksort_list.c -L. -L. -Lsac2c/lib -Lsac2c/lib
-Lstdlib/modules/structures/lib -Lstdlib/modules/structures/lib
-Lstdlib/modules/numerical/lib -Lstdlib/modules/numerical/lib
-Lstdlib/ world/system/lib -Lstdlib/world/system/lib
-Lstdlib/world/stdio/lib -Lstdlib/world/stdio/lib
-Lstdlib/world/stdio/dislin/lib -Lstdlib/world/ stdio/dislin/lib
-Lstdlib/classes/random/lib -Lstdlib/classes/random/ lib
-Lstdlib/utrace/lib -Lstdlib/utrace/lib -L. -L. -lMyListMod
-lRandomMod -lStdIOMod -lBinFileMod -lScalarIOMod -lArrayIOMod
-lFibreIOMod -lListIOMod -lComplexIOMod -lComplexMod -lIOresourcesMod
-lListMod -lArrayFormatMod -lArrayMod -lMathArrayMod -lFileMod
-lTermFileMod -lComplexArrayArithMod -lComplexArrayTransformMod
-lComplexArrayBasicsMod -lComplexScalarArithMod -lArrayTransformMod
-lTerminalMod -lFileSystemMod -lSysErrMod -lWorldMod -lConstantsMod
-lArrayArithMod -lComplexBasicsMod -lMathMod -lBoolMod -lStringMod
-lCharMod -lm -lArrayBasicsMod -lScalarArithMod -lsacpreludeMod
-lsac_seq
You said this is causing an error, but you didn't say what that error
is.
What do you expect to happen? What *does* happen?
Also, I see no 'ld -r' here. How is this example related to the
earlier example with 'ld -r'?
Everything in stdlib/* has just been compiled with the exact same
compiler/linker
and all .so and .a files therein are reported by both file and lipo to
be thin x86.
What TYPE are the files? Are they relocatable and relinkable, or
not? Use the 'file' command, and pay attention to the words before
"i386".
The files were produced by the same compiler/linker, so exactly what
was the compile or link command? Was it 'cc -c' or 'cc -
dynamiclib'? What role did 'ld -r' play, if any?
-- GG
_______________________________________________
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