Mixing libraries for different architectures into a shared lib

[Ian Lance Taylor]

Erik Leunissen <e.leunissen@hccnet.nl> writes:

> I'd like to understand what happens when I (inadvertently) link object
> files for different architectures like this (all build commands being
> done on linux for linux target):
>
> # two source files:
> lib1.c
> lib2.c
>
> # compiling one for i386 and the other for i686
> gcc -march=i386 -o lib1.o -c lib1.c
> gcc -march=i686 -o lib2.o -c lib2.c
>
> # linking the both into a shared lib
> gcc -shared -o myshlib.so lib1.o lib2.o
>
> I can imagine that things go wrong at load time or run time when
> launching a program (on a i686 machine) that uses myshlib.so:
> - does it run?
> - will it even load myshlib.so at runtime?

Well, you're not going to have any trouble running the library on a i686
machine, since all the i386 code will run fine on i686.  You could have
trouble the other way around: if you try to run the library on a i386
machine (assuming you can find one).

More generally, the Intel family does not record the specific processor
type in the ELF object in a way that makes any difference to the kernel.
So, yes, the library will load.  And, yes, it will run.  But if the
program happens to execute an instruction not supported on the current
processor, the program will crash or do something weird.


> Does it make a difference if the binaries are produced for windows
> (using a cross-toolchain and adjusting file names properly, of
> course)?

I don't know whether the PE format used on Windows records this kind of
information.

Ian