[gccsdk] libapr

[Lee Noar]

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.