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 firstname.lastname@example.org +49-5201-669912 Heisenberg may have been here.
Description: PGP signature