Date: Sun, 16 Oct 2011 03:35:26 +0300 From: "Luchesar V. ILIEV" <luchesar.iliev@gmail.com> To: freebsd-office@freebsd.org Subject: Re: Still can't build libreoffice Message-ID: <4E9A26CE.1030601@gmail.com> In-Reply-To: <13459014.2iGCsMRJz1@pcoliver.heesakkers.info> References: <4E8818EF.10204@FreeBSD.org> <20111004214907.GD19540@azathoth.lan> <4E98A4F2.20304@FreeBSD.org> <13459014.2iGCsMRJz1@pcoliver.heesakkers.info>
next in thread | previous in thread | raw e-mail | index | archive | help
On 15/10/2011 23:32, Oliver Heesakkers wrote:
> Op vr 14 okt 2011 14:09:06 schreef Doug Barton:
>> Well I have good news of a sort. I was previously working with a
>> world/kernel that was built by clang. I finally had a chance to rebuild
>> with the stock gcc, and now that I have, libreoffice builds and runs
>> just fine with the GTK option the only one selected (i.e., no debug).
>>
>> So hopefully this will help you track down the problem.
>>
>>
>
> Confirmed (only option KDE4). It's disheartening to see how many things break
> in unsuspecting places while using clang, even for building kernel and world.
I can also confirm the problem, at least on stable/9 (different
revisions from the past 2-3 weeks):
1. LO builds and runs without problem* on GCC-built system.
2. LO, built on a GCC-built system, fails to run on a Clang-built one.
3. LO fails to build on a Clang-built system, getting stuck with
cppunittest, just like Doug explained in his first e-mail.
4. LO builds successfully on a Clang-built system with DEBUG=on, and
then runs fine (for a debug build, that is). I haven't touched the other
options, so they don't seem to make much (or any) difference:
WEBDAV=on "Support webdav protocol"
KDE4=off "With Qt4/KDE4 vclplug support"
GTK=on "With GTK vclplug support"
GNOME=on "Better integration in gnome environnement"
JAVA=on "Add Java support (XML Filters, macros)"
PYUNO=on "Allow to script libreoffice in python"
SYSTRAY=on "Enable systemtry quickstarter"
MMEDIA=on "Enable multimedia backend for impress"
SDK=off "Build with SDK"
Basically clean make.conf, with only Perl and Ruby version variables.
*) Actually, the first instance seems to always segfault (and dump core)
to me, however this is most likely unrelated to the current problem, as
I've been noticing it for some time and on GCC-built systems, too.
Cheers,
Luchesar
--
i.dea.is/luchesar
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4E9A26CE.1030601>