Created attachment 46654 [details]
build error.

->ht: What does that switch do? Is an earlier version of stlport used then?

No, it uses the STL libs from my gcc4 installation instead. This was working in
OpenOffice 2.2.1

Confirmed, added thb to CC list.

->ht: Couldn't reproduce yet, as OOo build fails in sal with
"--without-stlport4" in m219 (the version I am currently working on). Usage of
STL classes in sal seems to be new. Does an issue for this already exist?

Weird error in sal. Here is the compiler output and the relevant source:

/ooo/chart07/src680-m219/sal/osl/all/debugbase.cxx: In function 'bool
osl_detail_ObjectRegistry_storeAddresses(const char*)':
/ooo/chart07/src680-m219/sal/osl/all/debugbase.cxx:106: error: invalid
initialization of reference of type 'const rtl::OString&' from expression of
type 'const rtl::OUString'

debugbase.cxx:58
typedef std::vector<rtl::OString, rtl::Allocator<rtl::OUString> > OStringVec;

struct StaticDebugBaseAddressFilter
    : rtl::StaticWithInit<OStringVec const, StaticDebugBaseAddressFilter> {
    OStringVec const operator()() const {
        OStringVec vec;
        rtl_uString * pStr = 0;
        rtl::OUString const name(
            RTL_CONSTASCII_USTRINGPARAM("OSL_DEBUGBASE_STORE_ADDRESSES") );
        if (osl_getEnvironment( name.pData, &pStr ) == osl_Process_E_None) {
            rtl::OUString const str(pStr);
            rtl_uString_release(pStr);
            sal_Int32 nIndex = 0;
            do {
                vec.push_back( rtl::OUStringToOString(
                                   str.getToken( 0, ';', nIndex ),
                                   RTL_TEXTENCODING_ASCII_US ) );
            }
            while (nIndex >= 0);
        }
        return vec;
    }
};

debugbase.cxx:102
    OStringVec const& rVec = StaticDebugBaseAddressFilter::get();
    if (rVec.empty())
        return false;
    // check for "all":
    rtl::OString const& rFirst = rVec[0];  // this is line 106

Not sure, the only module before chart2 in m219 that failed to build for me was
basebmp and that was fixed with this patch http://pastebin.archlinux.org/9306 
(I don't remember with cws).

Created attachment 46705 [details]
opportunistic sal fix

@dbo: that allocator type - typo or on purpose?

with the patch, sal at least builds like a charm ;-)

For the records: this prolly never occured to anyone out there, since it happens
with a dbg-util-enabled build - might even be a nice _STLP_DEBUG feature...

Fixed the first error by changing "lcl_ValarrayToSequence" to
"lcl_ValarrayToSequence< tDataType::value_type >". (See CWS chart07).

However, there remains a problem, I don't know how to fix. If I fix the problem
it works, but it no longer does on Solaris with STL-port. See attachment for
explanation.

Created attachment 46723 [details]
Explanation of the current problem with InternalDataProvider.cxx

Er, comment on my attachment: I think the STL implementation used by gcc is
broken that it isn't able to add an element to a vector< tMyMultimap::value_type
>, not the breakage after patching.

Hm, looking closely at the code: why is the temporary storage a vector? It can
as well be a multimap, as the order is not important. So, doing this change
makes all compilers happy.

Actually, now chart2 compiles completely without STL-Port in my Linux OOo build.

For the problem in sal see Issue 79535

Did OOo build wiht switch --without-stlport4 with patches for sal, basebmp and
the changes commited to this CWS in chart2, successfully.

Confirmed fixed here as well on i686. Chart2 builds correctly now without-stlport4
Thanks bm.

Found integrated in master SRC680.m223