You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Damjan Jovanovic <da...@apache.org> on 2016/12/26 18:45:36 UTC
Buildbots are working again
Hi
All the buildbots are successfully building now.
The FreeBSD bot was fixed by changing the buildbot script to use Clang
instead of GCC. From what I've seen, on FreeBSD, loading a mixture of C++
libraries built with GCC and C++ libraries built with Clang into the same
process, and using more advanced C++ features like exception handling,
causes memory corruption and crashes due to incompatible C++ ABIs; either
every library has to be built with GCC or every library has to be built
with Clang. In practice, the former requires a rebuild of the entire base
system and building all ports from source, which is why the latter is
better.
The Linux bots were much harder to fix. The build was breaking because libc
isn't linked to in some gbuild modules, something that was fixed by
explicitly always linking to libc on Linux, and because Google Test wasn't
linking to libpthread, somehow resulting in missing symbols in at least
main/binaryurp when built without --enable-dbgutil, which was fixed by
explicitly linking it to libpthread. I don't like these linker mysteries,
which never happen on FreeBSD, and some of which can be worked around with
the "gold" linker...
Damjan
Re: Buildbots are working again
Posted by Peter Kovacs <le...@gmail.com>.
Thanks a lot Damjan.
Sounds really great. I will update my repository and try to build open
office again. Maybe it works for me.
:)
All the best
Peter
Damjan Jovanovic <da...@apache.org> schrieb am Mo., 26. Dez. 2016, 19:46:
> Hi
>
> All the buildbots are successfully building now.
>
> The FreeBSD bot was fixed by changing the buildbot script to use Clang
> instead of GCC. From what I've seen, on FreeBSD, loading a mixture of C++
> libraries built with GCC and C++ libraries built with Clang into the same
> process, and using more advanced C++ features like exception handling,
> causes memory corruption and crashes due to incompatible C++ ABIs; either
> every library has to be built with GCC or every library has to be built
> with Clang. In practice, the former requires a rebuild of the entire base
> system and building all ports from source, which is why the latter is
> better.
>
> The Linux bots were much harder to fix. The build was breaking because libc
> isn't linked to in some gbuild modules, something that was fixed by
> explicitly always linking to libc on Linux, and because Google Test wasn't
> linking to libpthread, somehow resulting in missing symbols in at least
> main/binaryurp when built without --enable-dbgutil, which was fixed by
> explicitly linking it to libpthread. I don't like these linker mysteries,
> which never happen on FreeBSD, and some of which can be worked around with
> the "gold" linker...
>
> Damjan
>
--
Disclaimer: Diese Nachricht stammt aus einem Google Account. Ihre Antwort
wird in der Google Cloud Gespeichert und durch Google Algorythmen zwecks
werbeanaöysen gescannt. Es ist derzeit nicht auszuschließen das ihre
Nachricht auch durch einen NSA Mitarbeiter geprüft wird. Durch
kommunikation mit diesen Account stimmen Sie zu das ihre Mail, ihre
Kontaktdaten und die Termine die Sie mit mir vereinbaren online zu Google
konditionen in der Googlecloud gespeichert wird. Sollten sie dies nicht
wünschen kontaktieren sie mich bitte Umgehend um z.B. alternativen zu
verhandeln.
Re: Buildbots are working again
Posted by Damjan Jovanovic <da...@apache.org>.
Hi Peter
If trunk is stable and I develop in branches, then buildbots will either be
equally broken as they will break on the branches, or they will build trunk
and be stable but useless to me.
I think your biggest problem is building on Arch Linux, and I am
downloading it now to try it myself. Which bitness are you using?
Damjan
On Wed, Jan 4, 2017 at 3:00 PM, Peter Kovacs <le...@gmail.com> wrote:
> Hi all,
>
> I am a bit unhappy with this approach. It basicly blocks all other efforts
> on the code.
>
> Ok. I am still struggeling with the build, but since I started to change
> code itself I actually making progress. I currently do not know where to
> commit those changes, so I can check on different machines (And see if my
> changes are still compatible with all other machines).
>
> I personally like to open up a branch.
>
> I also would like to see that trunc is the most stable branch we have,
> since this is the one we advertise people to start with. It is pretty hard
> to get familiar with the code if you work on something unstable.
>
> I do not mean to offend Damjan, who is doing a fine Job! - It is just I
> have the feeling our current organization is only working for a view, and
> not for all activities we are on.
>
>
> All the best
>
> Peter
>
>
> On 04.01.2017 13:27, Damjan Jovanovic wrote:
>
>> Yes, the last problem was that main/curl needed adding to
>> RepositoryExternal.mk. I've committed a fix and am testing it on the
>> FreeBSD bot now.
>>
>> The bots will be quite unstable going forward, as I am actively porting
>> modules to gbuild. They help me a lot to test different platforms quickly,
>> with different build settings - my PC mostly uses system libraries, the
>> bots internal ones. If you don't see commits to SVN for a while, and the
>> bots are still broken, then there's a problem ;-).
>>
>> Damjan
>>
>>
>>
>> On Wed, Jan 4, 2017 at 2:16 PM, Matthias Seidel <
>> matthias.seidel@hamburg.de>
>> wrote:
>>
>> Hi Damjan,
>>>
>>> Last night the linux64-41x buildbot (and maybe others) failed. Last
>>> successful build was 31.12.2016.
>>>
>>> Do you have any idea?
>>>
>>> Regards, Matthias
>>>
>>>
>>> Am 26.12.2016 um 19:45 schrieb Damjan Jovanovic:
>>>
>>>> Hi
>>>>
>>>> All the buildbots are successfully building now.
>>>>
>>>> The FreeBSD bot was fixed by changing the buildbot script to use Clang
>>>> instead of GCC. From what I've seen, on FreeBSD, loading a mixture of
>>>> C++
>>>> libraries built with GCC and C++ libraries built with Clang into the
>>>> same
>>>> process, and using more advanced C++ features like exception handling,
>>>> causes memory corruption and crashes due to incompatible C++ ABIs;
>>>> either
>>>> every library has to be built with GCC or every library has to be built
>>>> with Clang. In practice, the former requires a rebuild of the entire
>>>> base
>>>> system and building all ports from source, which is why the latter is
>>>> better.
>>>>
>>>> The Linux bots were much harder to fix. The build was breaking because
>>>>
>>> libc
>>>
>>>> isn't linked to in some gbuild modules, something that was fixed by
>>>> explicitly always linking to libc on Linux, and because Google Test
>>>>
>>> wasn't
>>>
>>>> linking to libpthread, somehow resulting in missing symbols in at least
>>>> main/binaryurp when built without --enable-dbgutil, which was fixed by
>>>> explicitly linking it to libpthread. I don't like these linker
>>>> mysteries,
>>>> which never happen on FreeBSD, and some of which can be worked around
>>>>
>>> with
>>>
>>>> the "gold" linker...
>>>>
>>>> Damjan
>>>>
>>>>
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
Re: Buildbots are working again
Posted by Patricia Shanahan <pa...@acm.org>.
I plan to be back on AOO next week, and would also appreciate a
reasonably stable, reliably building svn environment.
There are two options. Ideally, trunk becomes stable and reliably
building, and destabilizing activities go in branches. If that gets in
the way of using the buildbots to test the gbuild activity, maybe create
a stable branch.
On 01/04/2017 01:00 PM, Peter Kovacs wrote:
> Hi all,
>
> I am a bit unhappy with this approach. It basicly blocks all other
> efforts on the code.
>
> Ok. I am still struggeling with the build, but since I started to
> change code itself I actually making progress. I currently do not know
> where to commit those changes, so I can check on different machines
> (And see if my changes are still compatible with all other machines).
>
> I personally like to open up a branch.
>
> I also would like to see that trunc is the most stable branch we have,
> since this is the one we advertise people to start with. It is pretty
> hard to get familiar with the code if you work on something unstable.
>
> I do not mean to offend Damjan, who is doing a fine Job! - It is just
> I have the feeling our current organization is only working for a
> view, and not for all activities we are on.
>
>
> All the best
>
> Peter
>
> On 04.01.2017 13:27, Damjan Jovanovic wrote:
>> Yes, the last problem was that main/curl needed adding to
>> RepositoryExternal.mk. I've committed a fix and am testing it on the
>> FreeBSD bot now.
>>
>> The bots will be quite unstable going forward, as I am actively porting
>> modules to gbuild. They help me a lot to test different platforms
>> quickly,
>> with different build settings - my PC mostly uses system libraries, the
>> bots internal ones. If you don't see commits to SVN for a while, and the
>> bots are still broken, then there's a problem ;-).
>>
>> Damjan
>>
>>
>>
>> On Wed, Jan 4, 2017 at 2:16 PM, Matthias Seidel
>> <ma...@hamburg.de>
>> wrote:
>>
>>> Hi Damjan,
>>>
>>> Last night the linux64-41x buildbot (and maybe others) failed. Last
>>> successful build was 31.12.2016.
>>>
>>> Do you have any idea?
>>>
>>> Regards, Matthias
>>>
>>>
>>> Am 26.12.2016 um 19:45 schrieb Damjan Jovanovic:
>>>> Hi
>>>>
>>>> All the buildbots are successfully building now.
>>>>
>>>> The FreeBSD bot was fixed by changing the buildbot script to use Clang
>>>> instead of GCC. From what I've seen, on FreeBSD, loading a mixture
>>>> of C++
>>>> libraries built with GCC and C++ libraries built with Clang into
>>>> the same
>>>> process, and using more advanced C++ features like exception handling,
>>>> causes memory corruption and crashes due to incompatible C++ ABIs;
>>>> either
>>>> every library has to be built with GCC or every library has to be
>>>> built
>>>> with Clang. In practice, the former requires a rebuild of the
>>>> entire base
>>>> system and building all ports from source, which is why the latter is
>>>> better.
>>>>
>>>> The Linux bots were much harder to fix. The build was breaking because
>>> libc
>>>> isn't linked to in some gbuild modules, something that was fixed by
>>>> explicitly always linking to libc on Linux, and because Google Test
>>> wasn't
>>>> linking to libpthread, somehow resulting in missing symbols in at
>>>> least
>>>> main/binaryurp when built without --enable-dbgutil, which was fixed by
>>>> explicitly linking it to libpthread. I don't like these linker
>>>> mysteries,
>>>> which never happen on FreeBSD, and some of which can be worked around
>>> with
>>>> the "gold" linker...
>>>>
>>>> Damjan
>>>>
>>>
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Buildbots are working again
Posted by Peter Kovacs <le...@gmail.com>.
Hi all,
I am a bit unhappy with this approach. It basicly blocks all other
efforts on the code.
Ok. I am still struggeling with the build, but since I started to change
code itself I actually making progress. I currently do not know where to
commit those changes, so I can check on different machines (And see if
my changes are still compatible with all other machines).
I personally like to open up a branch.
I also would like to see that trunc is the most stable branch we have,
since this is the one we advertise people to start with. It is pretty
hard to get familiar with the code if you work on something unstable.
I do not mean to offend Damjan, who is doing a fine Job! - It is just I
have the feeling our current organization is only working for a view,
and not for all activities we are on.
All the best
Peter
On 04.01.2017 13:27, Damjan Jovanovic wrote:
> Yes, the last problem was that main/curl needed adding to
> RepositoryExternal.mk. I've committed a fix and am testing it on the
> FreeBSD bot now.
>
> The bots will be quite unstable going forward, as I am actively porting
> modules to gbuild. They help me a lot to test different platforms quickly,
> with different build settings - my PC mostly uses system libraries, the
> bots internal ones. If you don't see commits to SVN for a while, and the
> bots are still broken, then there's a problem ;-).
>
> Damjan
>
>
>
> On Wed, Jan 4, 2017 at 2:16 PM, Matthias Seidel <ma...@hamburg.de>
> wrote:
>
>> Hi Damjan,
>>
>> Last night the linux64-41x buildbot (and maybe others) failed. Last
>> successful build was 31.12.2016.
>>
>> Do you have any idea?
>>
>> Regards, Matthias
>>
>>
>> Am 26.12.2016 um 19:45 schrieb Damjan Jovanovic:
>>> Hi
>>>
>>> All the buildbots are successfully building now.
>>>
>>> The FreeBSD bot was fixed by changing the buildbot script to use Clang
>>> instead of GCC. From what I've seen, on FreeBSD, loading a mixture of C++
>>> libraries built with GCC and C++ libraries built with Clang into the same
>>> process, and using more advanced C++ features like exception handling,
>>> causes memory corruption and crashes due to incompatible C++ ABIs; either
>>> every library has to be built with GCC or every library has to be built
>>> with Clang. In practice, the former requires a rebuild of the entire base
>>> system and building all ports from source, which is why the latter is
>>> better.
>>>
>>> The Linux bots were much harder to fix. The build was breaking because
>> libc
>>> isn't linked to in some gbuild modules, something that was fixed by
>>> explicitly always linking to libc on Linux, and because Google Test
>> wasn't
>>> linking to libpthread, somehow resulting in missing symbols in at least
>>> main/binaryurp when built without --enable-dbgutil, which was fixed by
>>> explicitly linking it to libpthread. I don't like these linker mysteries,
>>> which never happen on FreeBSD, and some of which can be worked around
>> with
>>> the "gold" linker...
>>>
>>> Damjan
>>>
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Buildbots are working again
Posted by Damjan Jovanovic <da...@apache.org>.
Yes, the last problem was that main/curl needed adding to
RepositoryExternal.mk. I've committed a fix and am testing it on the
FreeBSD bot now.
The bots will be quite unstable going forward, as I am actively porting
modules to gbuild. They help me a lot to test different platforms quickly,
with different build settings - my PC mostly uses system libraries, the
bots internal ones. If you don't see commits to SVN for a while, and the
bots are still broken, then there's a problem ;-).
Damjan
On Wed, Jan 4, 2017 at 2:16 PM, Matthias Seidel <ma...@hamburg.de>
wrote:
> Hi Damjan,
>
> Last night the linux64-41x buildbot (and maybe others) failed. Last
> successful build was 31.12.2016.
>
> Do you have any idea?
>
> Regards, Matthias
>
>
> Am 26.12.2016 um 19:45 schrieb Damjan Jovanovic:
> > Hi
> >
> > All the buildbots are successfully building now.
> >
> > The FreeBSD bot was fixed by changing the buildbot script to use Clang
> > instead of GCC. From what I've seen, on FreeBSD, loading a mixture of C++
> > libraries built with GCC and C++ libraries built with Clang into the same
> > process, and using more advanced C++ features like exception handling,
> > causes memory corruption and crashes due to incompatible C++ ABIs; either
> > every library has to be built with GCC or every library has to be built
> > with Clang. In practice, the former requires a rebuild of the entire base
> > system and building all ports from source, which is why the latter is
> > better.
> >
> > The Linux bots were much harder to fix. The build was breaking because
> libc
> > isn't linked to in some gbuild modules, something that was fixed by
> > explicitly always linking to libc on Linux, and because Google Test
> wasn't
> > linking to libpthread, somehow resulting in missing symbols in at least
> > main/binaryurp when built without --enable-dbgutil, which was fixed by
> > explicitly linking it to libpthread. I don't like these linker mysteries,
> > which never happen on FreeBSD, and some of which can be worked around
> with
> > the "gold" linker...
> >
> > Damjan
> >
>
>
>
Re: Buildbots are working again
Posted by Matthias Seidel <ma...@hamburg.de>.
Hi Damjan,
Last night the linux64-41x buildbot (and maybe others) failed. Last
successful build was 31.12.2016.
Do you have any idea?
Regards, Matthias
Am 26.12.2016 um 19:45 schrieb Damjan Jovanovic:
> Hi
>
> All the buildbots are successfully building now.
>
> The FreeBSD bot was fixed by changing the buildbot script to use Clang
> instead of GCC. From what I've seen, on FreeBSD, loading a mixture of C++
> libraries built with GCC and C++ libraries built with Clang into the same
> process, and using more advanced C++ features like exception handling,
> causes memory corruption and crashes due to incompatible C++ ABIs; either
> every library has to be built with GCC or every library has to be built
> with Clang. In practice, the former requires a rebuild of the entire base
> system and building all ports from source, which is why the latter is
> better.
>
> The Linux bots were much harder to fix. The build was breaking because libc
> isn't linked to in some gbuild modules, something that was fixed by
> explicitly always linking to libc on Linux, and because Google Test wasn't
> linking to libpthread, somehow resulting in missing symbols in at least
> main/binaryurp when built without --enable-dbgutil, which was fixed by
> explicitly linking it to libpthread. I don't like these linker mysteries,
> which never happen on FreeBSD, and some of which can be worked around with
> the "gold" linker...
>
> Damjan
>