[Tcsh] tcsh and Alpine Linux: progress, anyone?

[Vlad Meşco]

On Mon, 28 Nov 2022 at 12:47, Vlad Meșco <vlad.mesco at gmail.com> wrote:
>
> Le 28 novembre 2022 11:33:15 GMT+02:00, Luke Mewburn <luke at mewburn.net> a écrit :
> >On 22-11-26 23:41, Vlad Meșco wrote:
> >  | Le 26 novembre 2022 21:21:01 GMT+02:00, Christos Zoulas <christos at zoulas.com> a écrit :
> >  | >Alpine uses must c which is "opinionated" about things like
> >  | >defining a CPP symbol to differentiate itself because it claims one
> >  | >should not be needed because it provides a standards compliant
> >  | >implementation and such checks should be unnecessary:
> >  | >https://wiki.musl-libc.org/faq.html
> >  | >At the same time it uses a malloc implementation that causes
> >  | >problems for programs which try to use a custom allocator (replace musl's
> >  | >allocator):
> >  | >https://www.linkedin.com/pulse/testing-alternative-c-memory-allocators-pt-2-musl-mystery-gomes/
> >  | >https://gitlab.alpinelinux.org/alpine/aports/-/issues/12913
> >  | >
> >  |
> >  | My $0.02: Having to occasionally support cross platform builds
> >  | across a whole bunch of platforms at work, I wouldn't rely on GLIBC
> >  | not being defined meaning it's musl's/Alpine's  behaviour in 2022.
> >  | There's bionic, uclib, and probably someone out there is working on
> >  | a 15th standard C library, and there will be a distro using it. And
> >  | somewhere there will be an issue. It would be a neverending problem.
> >  |
> >  |  [...]
> >  |
> >  | You mention musl has issues with someone trying to replace the
> >  | allocator, surely that can be tested for? Now this is me being
> >  | ignorant to how autoconf works: is one able to add a custom check,
> >  | if such a check can be written? Then this could add a define to the
> >  | pile to force SYSMALLOC on in config_f.h (wishful thinking). I mean,
> >  | this is less of a preference and more of a necessity.
> >
> >Hi Vlad,
> >
> >If you can provide a minimal test program that we can run
> >to determine if the problem exists on Alpine / musl /... ,
> >versus not failing on more common platforms, I'm happy to work
> >with you to turn that into an autoconf check (since I have a
> >lot of experience with doing that).
> >
> >regards,
> >Luke.
>
> Cool!
>
> I'll go find some time.
>
> Vlad

Hello,

It turns out musl just doesn't make the sbrk syscall if you give
the library function anything other than 0 [1]. It's still true on their
HEAD.  I started off doing what tc.alloc.c/morecore() was doing:

    #include <unistd.h>

    int main(int argc, char* argv[])
    {
        void* p = sbrk(0);
        if(p == (void*)-1) return 1;
        if((long)p & 0x3ff) {
            p = sbrk((int) (1024 - ((long)p & 0x3ff)));
            if(p == (void*)-1) return 2;
        }
        p = sbrk(2048);
        if(p == (void*)-1) return 3;
        return 0;
    }

But that can be reduced to "one" line:

    #include <unistd.h>

    int main(int argc, char* arvv[])
    {
        return sbrk(2048) == (void*)-1;
    }

I've only tested on some older Alpine in WSL2 and a CentOS 7
machine (for sanity). This checks if sbrk() can increase; if sbrk()
is "read-only", then the custom allocator will not work, so tcsh
may as well use the system/libc malloc.

[1] http://git.musl-libc.org/cgit/musl/commit/src/linux/sbrk.c?id=7a995fe706e519a4f55399776ef0df9596101f93

Best regards,
Vlad