[SOLVED] Re: build failure: sc_ucalc.test - cppunittester abort trap (core dumped)

[R Skinner]

On 04/03/12 03:30, Lubos Lunak wrote:
> On Sunday 01 of April 2012, R Skinner wrote:
>> On 03/31/12 18:49, Lubos Lunak wrote:
>>>    If you use the Clang compiler, then I somehow doubt you'll manage to
>>> get 3.4.5 working with that. In fact I'm even surprised the link mentions
>>> 3.5 as usable with Clang, since I had to do several fixes in master this
>>> month to get LO compile and run with Clang on Linux.
>> With a bit raping in the Makefile it seems to work, roughly, on FreeBSD-
>> clang is designed to run on its descendant after all (MacOSX) ;)
>>
>> I'm stuck here though:
>>
>> In file included from
>> /usr/ports/editors/libreoffice/work/libreoffice-bootstrap-3.4.5.2/soltools/
>> giparser/gi_list.cxx:33: In file included from ../inc/gi_list.hxx:33:
>> ../inc/st_list.hxx:298:10: error: use of undeclared identfier 'push_back'
>>                   push_back( new XY(*(*it)) );
>>                   ^
>>                   this->
>> ... more notes - usually related to this issue...
>> ../inc/st_list.hxx:311:5: error: use of undeclared identifier 'checkSize'
>>                   checkSize(DynamicList<XY>::len-2);
>>                   ^
>>                   this->
>> ... even more notes the last error...
>>
>> And then the usual fail routine.
>>
>> Any pointers on what is going on? I love clang - it shows up all the
>> little nuances :) More than likely the root of my original issue...
>   As I said, I think you're unlikely to build out-of-the-box-3.4.5 with clang.
> Maybe if you try a version which does not have the stricter C++11 support
> yet. Or you can try to fix the source as clang suggests you to do.
>
Hmmm. Apparently it has worked on FBSD in the past, but this is not an 
easy fix for me in this instance. Besides, it is likely to happen 
elsewhere in the code.

Interesting solution actually. After trawling for hours following the 
thread through numerous config files, configure scripts, Makefiles, 
build scripts (and getting totally lost), I got fed up and went screw it 
and built it on another amd64 machine (didn't think of it actually).

This was a FreeBSD 9.0 amd64 (as the original unit with issues), but it 
had a *real* processor in it, not a toy one: Atom D255.

It built beautifully, and I was able to create a package and install it 
on the Atom unit.

The ports system on FreeBSD also adds a layer of abstraction to the 
build (probably necessary, but still disconcerting) which means that not 
all options are available as they seem to be 'hardwired' in (CC env, 
others). This did make it difficult to work out what was actually happening.

Not sure where to go from here. You guys have been real helpful, this is 
a strange issue though and I'm reporting the resolution for your 
interest. I hope someone can use this if they end up the same creek, or 
fix it somehow...

Thanks guys.