On Tue, Dec 19, 2017 at 11:16:30PM +0100, Kamil Rytarowski wrote: > On 19.12.2017 14:59, Anders Magnusson wrote: > > Den 2017-12-19 kl. 14:45, skrev Christos Zoulas: > >> In article <c7e15629-8b30-0a40-ae62-fc893a29e49a%ludd.ltu.se@localhost>, > >> Anders Magnusson? <ragge%ludd.ltu.se@localhost> wrote: > >> > >>> IIRC it was not a problem to run Emacs, it was a problem to compile it. > >>> So if the user want to compile an old Emacs,? COMPAT_80 or so must be > >>> added to the kernel. > >> And let's not forget all the old binaries that might be using it. > >> > > That was not a problem since they used the sbrk(3) version instead. > > ...which assumes that they are dynamically linked, of course :-) > > > > -- Ragge > > SYS_sstk, SYS_sbrk and SYS_vadvise are gone. SYS_sstk has never been implemented anywhere AFACT. The function was empty when introduced and stayed that way (at least in FreeBSD). > sbrk(2) users: > - gpl2/libmalloc > - LLVM (Process::GetMallocUsage()) > - am-utils (debug) > - unbound (debug) > - binutils / nm (debug) > - binutils / gas (debug) > - binutils / ld (debug) > - binutils / libiberty (debug) > - gcc / libiberty (debug) > - gdb One thing be aware of with the GNU ones: if you want to generate binaries that don't use sbrk going forward (a good thing) then you have to patch because configure will find it and add a declaration if required so long as the symbol resolves. IIRC binutils will avoid if so long as you convince the scripts it's really not there. -- Brooks
Attachment:
signature.asc
Description: PGP signature