Why can't gcc-4.2.1 build usable libreoffice?

Chris Rees utisoft at gmail.com
Tue Feb 19 19:14:15 UTC 2013


Somehow attribution has been screwed here-- I will perhaps blame the
appalling Android Gmail app that I used to reply to an earlier
message.

On 19 February 2013 18:54, Mikhail T. <mi+thun at aldan.algebra.com> wrote:
<snip>
> 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...

I'm sorry that you feel that the maintainers of Libreoffice have taken
an easy route; you can certainly show them how easy it is to do by
providing some patches/fixes, or working with upstream.  I don't see
how anyone on freebsd-stable@ will either be interested or
knowledgeable in Libreoffice internals.

> 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?

GPLv3.

>> Maintainers of large opensource suites are likely to have little interest in supporting
>> LibreOffice's own Native_Build page 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.

That is why we're replacing it with LLVM/Clang.

> 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 about it...

It is no secret that our base compiler is old.  What do you think
happens in newer versions, if not added features and bugfixes?

> 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...

Irrelevant.  You choosing to compile with a different compiler adds no
value and can't be compared with a different interface.

Please fix it yourself, or talk to upstream.

Chris


More information about the freebsd-office mailing list