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
I checked in the installed libapr-1.a, and that appears to be
all non-PIC objects.
In any case, if we're still generating static binaries from
PIC objects, then we might be missing a check. I forget John's
exact conclusion here.
> Yes, hopefully my last two commits to UnixLib will fix these problems
> and they may make dynamically linked Firefox more stable too
That does sound promising. The libapr issues tested pthreads + SL
in a controlled way that may have been impossible to diagnose
directly in Firefox. I will test today.
Thanks.
_______________________________________________
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
