Peter Naulls wrote:
Lee Noar wrote:
Peter Naulls wrote:
[SNIP crash]
This is a static binary, and I have turned off threading and other
things which might be causing a problem. This seems to be triggered
by, or around the "writev" test in testall.
The static binaries contain PIC code and it's this that causes them to
crash, so this is a build problem. The dynamic binaries also contain
PIC code, but that doesn't seem to be as much of a problem. The fact
that they are already registered to SOManager and the mechanisms for
shared library code are in place no doubt help a lot here, but I'm not
100% certain that it's bulletproof.
Hm, how did you get this build? Actually getting static code out if
does take some explicit steps, such as reusing the build,
setting the variables, then reconfiguring manually (which does
static only by default).
Here's what I did:
/usr/src/gccsdk/autobuilder/build -D libapr1
bash (to get an environment I can dump after)
cd libapr1/apr-1.3.8/
make clean
. /usr/src/gccsdk/autobuilder/libraries/libapr1/setvars
/home/riscos/env/ro-config --disable-dso
cd test
make
Yes, that produces PIC clean static binaries for me too. I originally
tried manually relinking the executable with -static tacked on the
autobuilder generated link line (for testlockperf). When that produced
the PIC in executable code (in executable objects, not library objects),
I compiled and linked it manually away from autobuilder to get a clean
binary. Sorry, guess that was a red herring.
testall in static form crashes in the same place as the dynamic version,
so we can cross dynamic linking off the list of culprits :-)
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
