On Wed, Sep 18, 2002 at 05:13:22PM +0200, Yann Dirson wrote:
> That's what we're trying to detect at configure-time. However, a
> simple test of building a non-pic shlib and linking a program with it
> does succeed. Relevant lines from the trace are:
In the gcc spec file there is a -fPIC - So any lib you generate
on mips is pic anyway.
> + gcc -c /tmp/actestydirson-lib1.c -o actestydirson-lib1.o
> + gcc -c /tmp/actestydirson-lib2.c -o actestydirson-lib2.o
> + ld -shared -o /tmp/actestydirson.so actestydirson-lib1.o actestydirson-lib2.o -lc -lm
> + gcc -o /tmp/Xactestydirson /tmp/actestydirson.c /tmp/actestydirson.so
> + /tmp/Xactestydirson
> This test is apparently sufficient on ia64, but for some reason it
> does not fail on mipsel (and surely on mips as well).
Why should it fail ? It should work ...
> The simple code provided by upstream does not explicitely call any
> libc function, so I even added a call to printf to check, but that did
> not change anything.
It shouldnt - the case above is valid. You CANT link pic and non-pic.
But the whole userspace on mips(el) is PIC by default. Its hardcoded
in the specs file - No way to generate non-pic code.
> Anyone understand why it works, and what should be tested for instead ?
Nothing - There is nothing like a "non-pic" library on mips & mipsel.
You can link together everything as you like.
Flo
--
Florian Lohoff flo@rfc822.org +49-5201-669912
Heisenberg may have been here.
Attachment:
pgp6cCYN3yDx1.pgp
Description: PGP signature