Why can't gcc-4.2.1 build usable libreoffice?

Mikhail T. mi+thun at aldan.algebra.com
Tue Feb 19 18:54:07 UTC 2013


On 19.02.2013 13:19, Ian Lepore wrote:
> All strike me as being "complaints," but if that seems like a
> mis-characterization to you, then I apologize.
These were, indeed, complaints, but not about the port "not working after I 
broke it". My complaint is that, though the port "works" out of the box, the 
office@ maintainers have given up on the base compiler too easily -- comments in 
the makefile make no mention of any bug-reports filed with anyone, for example. 
It sure seems, no attempts were made to analyze the failures... I don't think, 
such "going with the flow" is responsible and am afraid, the inglorious days of 
building a special compiler just for the office will return...

Maybe, it is just an omission -- and the particular shortcomings of the base 
compiler (and/or the rest of the toolchain) are already known and documented 
somewhere else?
> Licensing prevents us from updating gcc in the base.
Licensing? Could you elaborate, which aspect of licensing you have in mind?
> Maintainers of large opensource suites are likely to have little interest in supporting
LibreOffice's own Native_Build page 
<https://wiki.documentfoundation.org/Development/Native_Build> makes no mention 
of a required compiler version. Unless a compiler is documented to not support a 
required feature, it is supposed to work. Thus, filing a bug-report with 
LibreOffice could've been fruitful -- if it is the code, rather than the 
toolchain, that are at fault...
> a buggy old compiler years after it has been obsoleted by newer versions.
So, it is your conclusion too, that our base compiler is "buggy" -- and that 
little can be done about it.

Am I really the only one here disturbed by the fact, that the compilers shipped 
as cc(1) and/or c++(1) in our favorite operating system's most recent stable 
versions (9.1 and 8.3) are considered buggy? Not just old -- and thus unable to 
process more modern language-standards/features, but buggy -- processing those 
features incorrectly? There is certainly nothing in our errata 
<http://www.freebsd.org/releases/9.1R/errata.html> about it...

On 19.02.2013 13:05, Adrian Chadd wrote:
> .. I think the compiler people just use the port as compiled with the
> compiler that is known to work with it, and move on.

Such people would, perhaps, be even better served by an RPM-based system, don't 
you think? But I don't think so -- the amount of OPTIONS in the port is large, 
and a lot of people are likely to build their own. Not because they like  it, 
but because they want a PostgreSQL driver or KDE4 (or GTK3) interface or...

    -mi



More information about the freebsd-stable mailing list