This was mentioned earlier, but there was no follow up. In any case, the situation is pretty bad, and it's purely by chance this hasn't been a serious issue until now.
The culprit is libtool's handling of "convenience libraries", which are used in a number of projects (glib, gtk, xlib) to build intermediate libraries from sub directory projects - these libraries, although .a archives, contain only PIC objects, and they end up in the static .a at the level above when it is created. It seems that this is actually ok most everywhere, although Cygwin has the same problem: http://www.mail-archive.com/[email protected]/msg11472.html With the assumption that you can just use a PIC object in place of a non-PIC one (which is definitely not true under our PIC handling). In the mean time, I've adjusted ro-install to scan .a files to be installed for PIC objects and reject them. I'm not sure what the fix is going to be here - one option is maybe to build the libraries twice, but this is going to cause a lot of problems. You'll find that quite a number of your libraries are affected. Try e.g.: for file in $(find /home/riscos/env/lib | grep "\.a\$"); do if /home/riscos/cross/bin/arm-unknown-riscos-objdump -p $file | \ grep -q "position" ; then echo $file fi done Which will print any static libraries containing PIC objects. _______________________________________________ GCCSDK mailing list [email protected] Bugzilla: http://www.riscos.info/bugzilla/index.cgi List Info: http://www.riscos.info/mailman/listinfo/gcc Main Page: http://www.riscos.info/index.php/GCCSDK
