You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Pedro Giffuni <pf...@apache.org> on 2012/04/05 19:12:22 UTC
How to report a build breaker in BZ?
Hi;
There is a build breaker on FreeBSD when building vcl with silgraphite.
It's something related to STLport ...
___
...
[ build DEP ] LNK:Library/libvcl.so
[ build CXX ] vcl/source/glyphs/glyphcache
In file included from /usr/include/c++/4.2/memory:53,
from
/work/tinderbox-ligeti8amd64/portstrees/FreeBSD/ports/editors/openoffice-3-devel/work/ooo/main/solver/340/unxfbsdx.pro/inc/stl/preextstl.h:48,
from
/work/tinderbox-ligeti8amd64/portstrees/FreeBSD/ports/editors/openoffice-3-devel/work/ooo/main/vcl/inc/graphite_features.hxx:28,
from
/work/tinderbox-ligeti8amd64/portstrees/FreeBSD/ports/editors/openoffice-3-devel/work/ooo/main/vcl/source/glyphs/glyphcache.cxx:40:/usr/include/c++/4.2/bits/stl_algobase.h:321:
error: 'ostreambuf_iterator' was not declared in this scope
/usr/include/c++/4.2/bits/stl_algobase.h:321: error: template argument 2
is invalid
/usr/include/c++/4.2/bits/stl_algobase.h:321: error: expected
unqualified-id before '>' token
/usr/include/c++/4.2/bits/stl_algobase.h:326: error:
'ostreambuf_iterator' was not declared in this scope
/usr/include/c++/4.2/bits/stl_algobase.h:326: error: template argument 2
is invalid
/usr/include/c++/4.2/bits/stl_algobase.h:326: error: expected
unqualified-id before '>' token
/usr/include/c++/4.2/bits/stl_algobase.h:331: error: template
declaration of 'typename
__gnu_cxx::__enable_if<std::__is_char<_Tp>::__value, _CharT*>::__type
std::__copy_aux'/usr/include/c++/4.2/bits/stl_algobase.h:331: error:
'istreambuf_iterator' was not declared in this scope
/usr/include/c++/4.2/bits/stl_algobase.h:331: error: expected
primary-expression before '>' token
/usr/include/c++/4.2/bits/stl_algobase.h:331: error: expected
primary-expression before ',' token
/usr/include/c++/4.2/bits/stl_algobase.h:331: error:
'istreambuf_iterator' was not declared in this scope
/usr/include/c++/4.2/bits/stl_algobase.h:331: error: expected
primary-expression before '>' token
/usr/include/c++/4.2/bits/stl_algobase.h:331: error: expected
primary-expression before ',' token
/usr/include/c++/4.2/bits/stl_algobase.h:332: error: expected
primary-expression before '*' token
/usr/include/c++/4.2/bits/stl_algobase.h:332: error: expected
primary-expression before ')' token
/usr/include/c++/4.2/bits/stl_algobase.h:407: error:
'ostreambuf_iterator' was not declared in this scope
/usr/include/c++/4.2/bits/stl_algobase.h:407: error: template argument 2
is invalid
/usr/include/c++/4.2/bits/stl_algobase.h:407: error: expected
unqualified-id before '>' token
...
____
Maho-san has a workaround in the BSD port that is not acceptable for
the codebase so I would like to register it in BZ. Fixes for the build
issue
are welcome but I am rather interested in having this type of bugs easier
to report in BZ.
Unfortunately, despite the BZ cleanup, it is still not clear to me on which
category this should be filed in! It is not installation error, nor ucb
or sdk
or wp (that category probably doesn't belong in our bz anymore), how
should it be classified, a new category perhaps?
cheers,
Pedro.
Pedro.
Re: How to report a build breaker in BZ?
Posted by Pedro Giffuni <pf...@apache.org>.
On 04/05/12 14:20, Herbert Duerr wrote:
> Hi Pedro,
> [...]
>> You are warned that it's really ugly. The bug is
>> in VCL or in STLport but we workaround it in
>> Graphite:
>>
>> http://s.apache.org/HPl
>
> Have you tried if it works when you build with this patch?
>
Hmm.. I think so but I don't use graphite fonts.
> If it does then maybe a define to "enable unicode support" for your
> system STL is missing somewhere (e.g. _GLIBCXX_USE_WCHAR_T?). I'm
> sorry I can't help more as I don't have such a system and I'll be away
> for a few days (first the holidays then a bit in the hospital...)
>
Ahh... that's the issue. The BSDs don't use glibc (and never will).
I will have to look at the STL issues later on. I actually wanted to update
STLport but I may just try fix things enough to disable it. It's a huge
can of worms only second to ICU ;).
It's not an urgent matter though, Maho's patch seems to do it's
homework for the time being.
Pedro.
Re: How to report a build breaker in BZ?
Posted by Herbert Duerr <hd...@apache.org>.
Hi Pedro,
> [...]
>> Do you happen to have a link to the diff?
>
> You are warned that it's really ugly. The bug is
> in VCL or in STLport but we workaround it in
> Graphite:
>
> http://s.apache.org/HPl
Have you tried if it works when you build with this patch?
If it does then maybe a define to "enable unicode support" for your
system STL is missing somewhere (e.g. _GLIBCXX_USE_WCHAR_T?). I'm sorry
I can't help more as I don't have such a system and I'll be away for a
few days (first the holidays then a bit in the hospital...)
> [...]
>> I'd put it into GSL, because GSL ("graphics system layer")
>> libraries are involved.
>
> Thanks! It is not clear to the new guys (like me) so
> some polishing from our bugzilla experts is welcome.
Well the problem was that there is a big asymmetry in bugzilla: creating
a new category was easy, removing it once issues have been filed against
it is a lot of work.
This is even more so with version numbers. The ability to deprecate old
version will that will be possible once our bugzilla is upgraded will
help a bit to relieve the asymmetrie.
If we started all anew then having categories for just each app and for
framework, localizations, platform support, SDK and external-deps should
have sufficed.
Herbert
Re: How to report a build breaker in BZ?
Posted by Pedro Giffuni <pf...@apache.org>.
Hi Herbert;
--- Gio 5/4/12, Herbert Duerr <hd...@apache.org> ha scritto:
>
> This looks like the compiler provided STL not STLport.
>
We are using STLport: the build just doesn't work
disabling STLport.
> Mixing these two template libraries is not a good idea, e.g.
> when using the system silgraphite with system STL and the
> internal AOO libs with the in-tree STLport. I guess it will
> work better if you don't run configure
> -with-system-graphite, but only with --enable-graphite. Then
> AOO will build graphite with the same STL template library
> it is using itself.
>
We did that a while ago but it still causes breakage.
> > Maho-san has a workaround in the BSD port that is not
> acceptable for
> > the codebase [...]
>
> Do you happen to have a link to the diff?
>
You are warned that it's really ugly. The bug is
in VCL or in STLport but we workaround it in
Graphite:
http://s.apache.org/HPl
> > [...]
> > Unfortunately, despite the BZ cleanup, it is still not
> clear to me on which
> > category this should be filed in! It is not
> installation error, nor ucb
> > or sdk
> > or wp (that category probably doesn't belong in our bz
> anymore), how
> > should it be classified, a new category perhaps?
>
> I'd put it into GSL, because GSL ("graphics system layer")
> libraries are involved.
>
Thanks! It is not clear to the new guys (like me) so
some polishing from our bugzilla experts is welcome.
I will open a new issue and I will upload the build log.
cheers,
Pedro.
Re: How to report a build breaker in BZ?
Posted by Herbert Duerr <hd...@apache.org>.
On 04/05/2012 07:12 PM, Pedro Giffuni wrote:
> There is a build breaker on FreeBSD when building vcl with silgraphite.
> It's something related to STLport ...
> ___
> ...
> [ build DEP ] LNK:Library/libvcl.so
> [ build CXX ] vcl/source/glyphs/glyphcache
> In file included from /usr/include/c++/4.2/memory:53,
This looks like the compiler provided STL not STLport.
Mixing these two template libraries is not a good idea, e.g. when using
the system silgraphite with system STL and the internal AOO libs with
the in-tree STLport. I guess it will work better if you don't run
configure -with-system-graphite, but only with --enable-graphite. Then
AOO will build graphite with the same STL template library it is using
itself.
> Maho-san has a workaround in the BSD port that is not acceptable for
> the codebase [...]
Do you happen to have a link to the diff?
> [...]
> Unfortunately, despite the BZ cleanup, it is still not clear to me on which
> category this should be filed in! It is not installation error, nor ucb
> or sdk
> or wp (that category probably doesn't belong in our bz anymore), how
> should it be classified, a new category perhaps?
I'd put it into GSL, because GSL ("graphics system layer") libraries are
involved.
Herbert