Peter Naulls wrote:
Lee Noar wrote:
Jan-Jaap van der Geer wrote:
Looks like a shared library problem, R8 is bogus. My guess is
either there is an inconsistent shared library build, or we have
SOManager loader problem. Lee, is this something you can help to
diagnose ?
What do you mean with inconsistent? Calling something that is not in
the shared library or with another signature?
That seems a bit strange as I am pretty sure it is staticaly linked,
so I would have expected it to fail at linking then.
It is in fact built statically. It would seem that the problem is with
libglib2. For some reason, parts of the static archive are built with
-fPIC and Vala is being linked with this bogus code. We'll have to
look at the build process of libglib2 to fix this.
I have reviewed the build, including especially the gprintf stuff,
and it all looks ok - just the usual libtool craziness with two
different object files, but it all ends up in the right place.
Yes, usually non-PIC .o files are placed in the build directory and PIC
files in a .libs sub-directory and that is occurring here, however, the
archive is being created from those .o files in .libs. The libgnulib.a
archive is an example:
/bin/bash ../../libtool --tag=CC --mode=link
/home/riscos/cross/bin/arm-unknown-riscos-gcc -Wall
-L/home/riscos/env/lib
-L/home/riscos/cross/bin/../arm-unknown-riscos/lib -o libgnulib.la
asnprintf.lo printf-args.lo printf-parse.lo vasnprintf.lo printf.lo
-lintl
/home/riscos/cross/bin/arm-unknown-riscos-ar cru .libs/libgnulib.a
.libs/asnprintf.o .libs/printf-args.o .libs/printf-parse.o
.libs/vasnprintf.o .libs/printf.o
Perhaps Jan-Jaap linked in RISC OS and got the wrong library?
I've checked my version of libglib2 in /home/riscos/env/lib and have
found that it does contain PIC code.
Lee.
_______________________________________________
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
