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

[Luke Mewburn]

Thanks Kimmo.


There's an another pull request with a change to the testsuite
to adapt to the busybox implementation of diff,
that's also related to this Alpine Linux thread.


I'll send through another pull request in the next couple of days with
various miscellaneous cleanups, including:

- A tweak to this pull request to use !defined(HAVE_WORKING_SBRK)
  instead of !HAVE_WORKING_SBRK, because tcsh uses the former pattern
  and I should have been consistent (plus it turns out that gcc -Wundef
  can complain about the latter, and the autoconf manual uses both
  idioms but leans to the former).  I

- More man page improvements.



cheers,
Luke.

On 22-11-30 10:44, Kimmo Suominen wrote:
  | Thanks, Luke!
  | 
  | I've merged your pull request, and committed the changed files from
  | running autoreconf.
  | 
  | Cheers,
  | + Kimmo
  | 
  | On Wed, 30 Nov 2022 at 09:32, Luke Mewburn <luke at mewburn.net> wrote:
  | >
  | > Hi folks,
  | >
  | > I've enhanced configure to search for a working sbrk(N) (HAVE_WORKING_SBRK)
  | > based on Vlad's analysis, and changed config_f.h to force SYSMALLOC
  | > unless HAVE_WORKING_SBRK.
  | >
  | > The pull request is: https://github.com/tcsh-org/tcsh/pull/61
  | >
  | > I also did some configure style cleanups first.
  | >
  | >
  | > Note that I have NOT committed the output of autoreconf, because
  | > I have different/older autoconf / gettext versions that the last
  | > system that regenerated, and I wanted to avoid the diff skew.
  | >
  | >
  | > cheers,
  | > Luke.
  | >
  | >
  | > On 22-11-28 14:15, Vlad Meşco wrote:
  | >   | 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
  | > --
  | > Tcsh mailing list
  | > Tcsh at astron.com
  | > https://mailman.astron.com/mailman/listinfo/tcsh