Re: tcsh -- build without sbrk

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

Re: tcsh -- build without sbrk

Marc Espie-2
On Mon, Nov 05, 2018 at 11:31:53AM +0000, Stuart Henderson wrote:

> On 2018/11/04 10:29, Daniel Dickman wrote:
> > The below overrides the cached autoconf value that says that we have
> > sbrk(2) on our system and pretends like we don't have it.
> >
> > With this we can build tcsh without a need for sbrk(2).
> >
> > ok?
>
> Should we just remove or change the entry in infrastructure/db/config.site
> instead?
>
> This is where it shows up.
>
It looks worthwhile to try.

Or we could just finally remove brk and sbrk from the libc ?

Now that emacs21 is dead, is there any need for those functions ?

Archeology shows them in POSIX 1997, marked as "legacy" at that point.

I don't see them even mentioned in POSIX 2017....

Reply | Threaded
Open this post in threaded view
|

Re: tcsh -- build without sbrk

Daniel Dickman
(dropping ports@)

> On Nov 5, 2018, at 9:22 AM, Marc Espie <[hidden email]> wrote:
>
>> On Mon, Nov 05, 2018 at 09:15:28AM -0500, Daniel Dickman wrote:
>>   gcc uses them for precompiled headers (PCH) which is a local diff added
>>   by kurt@ in 2009. its likely nothing in base uses PCH but i don't know
>>   what in ports needs this:
>
> This has always been a mess. I suspect it's not really important these days
> because pch only make sense for large C++ codebases, which are definitely
> not going to be happy with the gcc from base anyway.
>
> There is also some snippet using sbrk to avoid malloc in gmon.c.
>
> That might be more of an issue...

i did not run into anything else when i compiled base gcc on an i386 system with a modified libc. looked to me like just the pch functionality, although we’d need to test every platform to be certain, i guess.

>
>>   [3]https://github.com/openbsd/src/commit/cfee5d1
>>
>>   choices there would be to disable PCH support or maybe there's a
>>   different way to reimplement without brk/sbrk.
>
>>   clang looks like they have a HAVE_SBRK ifdef or something like that. so
>>   usage can likely be turned off but i don't know this codebase that well
>>   so that's just an assumption.
>
> Yep, I'll have to look.


let me know if you want me to test any llvm diffs on my system.