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: Wed, 23 Apr 2008 11:42:40 +0200
On Tue, Apr 22, 2008 at 12:18:17PM -0500, Peter O'Gorman wrote:
> Philip Hölzenspies wrote:
>
> > This was an over-reduced example, but whether I would want to do this or
> > not, the error should DEFINATELY NOT BE that the files is NOT OF
> > REQUIRED ARCHITECTURE.
>
> Please don't shout at me.
Sorry, but I didn't know how to get the point throught. Stating it in
lower case didn't have the desired effect in the previous two
attempts.
> I have downloaded one of the Xcode-3.1 beta versions so may have a newer
> ld version to you. 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.
> 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. Linking an
> application did not give any warnings.
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
To make sure there are no misunderandings, all the libraries indicated
with -lXXXX are in the directories indicated with -LXXXXX. 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. The same holds for anything in sac2c/*. The files in
/tmp/SAC_XXXXX have actually been generated by 'this' execution of our
compiler (this gcc invocation came from our compiler, which compiles
stuff down to C). This means that every .so and .a file in
/tmp/SAC_XXXXX is - according to both file and lipo - a thin x86
binary. It has been noted that there are two -arch flags, but that
shouldn't matter and the same error occur when I remove either the
first or the second.
I haven't gotten around to following up on Alastair's suggestion of
-Wl,-t (which I had read and which disappeared from my todo list soon
thereafter... no one knows why). Also, I don't have my laptop with me
today, but I will give it a go.
Unfortunately, there are ongoing license discussions, so I can not
simply post the whole code-base. You may be able to reproduce it using
the binary release of our compiler, which can be found at
sac-home.org. The invocation you see above is from the attempted
compilation of the c_from_sac demo in the sac directory. I seem to
recall that the binary distribution [1] also showed this problem (I
use the source distribution).
Regards,
Philip
[1] http://www.sac-home.org/~sah/beta/sac2c-1.00-beta-darwin-i386.tar.gz
_______________________________________________
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