Upstreaming FreeBSD ports patches before 4.2.0?

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Upstreaming FreeBSD ports patches before 4.2.0?

Damjan Jovanovic
Hi

Can we please upstream the patches from FreeBSD ports, before the 4.2.0
release?

That idlc memory alignment SIGBUS crash from
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216206 is Clang specific,
not FreeBSD specific, and could happen on other operating systems.

Thank you
Damjan
Reply | Threaded
Open this post in threaded view
|

Re: Upstreaming FreeBSD ports patches before 4.2.0?

Don Lewis-2
On 14 Apr, Damjan Jovanovic wrote:
> Hi
>
> Can we please upstream the patches from FreeBSD ports, before the 4.2.0
> release?
>
> That idlc memory alignment SIGBUS crash from
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216206 is Clang specific,
> not FreeBSD specific, and could happen on other operating systems.

That one is a bit complicated to upstream.  In the FreeBSD port I only
apply the patch conditionally when building with recent clang on amd64.
I could be harmful in terms of memory consumption on 32-bit machines.
The changes in the patch would need to be #ifdefed in order to import
it.

Also the changes for the internal allocator are lightly tested at best.

https://svnweb.freebsd.org/ports/head/editors/openoffice-devel/files/extra-patch-align16?revision=432895&view=markup


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Upstreaming FreeBSD ports patches before 4.2.0?

Damjan Jovanovic
Alright thank you.

Would it be better to just scrap cpprt, like gbuild modules already do?

On Sat, Apr 14, 2018 at 4:59 PM, Don Lewis <[hidden email]> wrote:

> On 14 Apr, Damjan Jovanovic wrote:
> > Hi
> >
> > Can we please upstream the patches from FreeBSD ports, before the 4.2.0
> > release?
> >
> > That idlc memory alignment SIGBUS crash from
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216206 is Clang
> specific,
> > not FreeBSD specific, and could happen on other operating systems.
>
> That one is a bit complicated to upstream.  In the FreeBSD port I only
> apply the patch conditionally when building with recent clang on amd64.
> I could be harmful in terms of memory consumption on 32-bit machines.
> The changes in the patch would need to be #ifdefed in order to import
> it.
>
> Also the changes for the internal allocator are lightly tested at best.
>
> https://svnweb.freebsd.org/ports/head/editors/openoffice-
> devel/files/extra-patch-align16?revision=432895&view=markup
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Upstreaming FreeBSD ports patches before 4.2.0?

Pedro Giffuni
In reply to this post by Damjan Jovanovic
Hi guys;

Just to let you know, OpenOffice is about to break in FreeBSD due to a
boost update:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227553

No fix (yet) :(.

Pedro.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Upstreaming FreeBSD ports patches before 4.2.0?

Damjan Jovanovic
Hi

It should be an easy fix, we just #include that file that the boost
upstream commit deleted from its includes, into our files that need it.

On Mon, Apr 16, 2018 at 4:13 PM, Pedro Giffuni <[hidden email]> wrote:

> Hi guys;
>
> Just to let you know, OpenOffice is about to break in FreeBSD due to a
> boost update:
>
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227553
>
> No fix (yet) :(.
>
> Pedro.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Upstreaming FreeBSD ports patches before 4.2.0?

Don Lewis-2
In reply to this post by Damjan Jovanovic
I just committed a fix for this in r1830406.

Without this I get build failures due to crashes in the unit tests if
--enable-debug is specified.  With this change I am able to get a
working build with both the system alloc and the internal alloc.

I was unaware that this was not getting used on the gbuild side of
things.  Why not?  It seems like a useful debug feature.

On 15 Apr, Damjan Jovanovic wrote:

> Alright thank you.
>
> Would it be better to just scrap cpprt, like gbuild modules already do?
>
> On Sat, Apr 14, 2018 at 4:59 PM, Don Lewis <[hidden email]> wrote:
>
>> On 14 Apr, Damjan Jovanovic wrote:
>> > Hi
>> >
>> > Can we please upstream the patches from FreeBSD ports, before the 4.2.0
>> > release?
>> >
>> > That idlc memory alignment SIGBUS crash from
>> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216206 is Clang
>> specific,
>> > not FreeBSD specific, and could happen on other operating systems.
>>
>> That one is a bit complicated to upstream.  In the FreeBSD port I only
>> apply the patch conditionally when building with recent clang on amd64.
>> I could be harmful in terms of memory consumption on 32-bit machines.
>> The changes in the patch would need to be #ifdefed in order to import
>> it.
>>
>> Also the changes for the internal allocator are lightly tested at best.
>>
>> https://svnweb.freebsd.org/ports/head/editors/openoffice-
>> devel/files/extra-patch-align16?revision=432895&view=markup
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Upstreaming FreeBSD ports patches before 4.2.0?

Damjan Jovanovic
Great, thank you.

No idea. Either Sun/Oracle never got around to implementing it, or they
planned on scrapping it.

On Sat, Apr 28, 2018 at 4:51 AM Don Lewis <[hidden email]> wrote:

> I just committed a fix for this in r1830406.
>
> Without this I get build failures due to crashes in the unit tests if
> --enable-debug is specified.  With this change I am able to get a
> working build with both the system alloc and the internal alloc.
>
> I was unaware that this was not getting used on the gbuild side of
> things.  Why not?  It seems like a useful debug feature.
>
> On 15 Apr, Damjan Jovanovic wrote:
> > Alright thank you.
> >
> > Would it be better to just scrap cpprt, like gbuild modules already do?
> >
> > On Sat, Apr 14, 2018 at 4:59 PM, Don Lewis <[hidden email]> wrote:
> >
> >> On 14 Apr, Damjan Jovanovic wrote:
> >> > Hi
> >> >
> >> > Can we please upstream the patches from FreeBSD ports, before the
> 4.2.0
> >> > release?
> >> >
> >> > That idlc memory alignment SIGBUS crash from
> >> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216206 is Clang
> >> specific,
> >> > not FreeBSD specific, and could happen on other operating systems.
> >>
> >> That one is a bit complicated to upstream.  In the FreeBSD port I only
> >> apply the patch conditionally when building with recent clang on amd64.
> >> I could be harmful in terms of memory consumption on 32-bit machines.
> >> The changes in the patch would need to be #ifdefed in order to import
> >> it.
> >>
> >> Also the changes for the internal allocator are lightly tested at best.
> >>
> >> https://svnweb.freebsd.org/ports/head/editors/openoffice-
> >> devel/files/extra-patch-align16?revision=432895&view=markup
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>