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