[Tcsh] tcsh and Alpine Linux: progress, anyone?
Vlad Meșco
vlad.mesco at gmail.com
Wed Nov 30 15:06:21 UTC 2022
Le 30 novembre 2022 16:55:47 GMT+02:00, Kimmo Suominen <kim at netbsd.org> a écrit :
>PR#60 is the one for the diff style. It said it might help w/ the
>issue discussed here, so I was hoping someone would test it and
>confirm in the PR. I don't have Alpine or an environment where diff
>comes from busybox.
>
>https://github.com/tcsh-org/tcsh/pull/60
>
>Looking forward to more PRs to merge. :)
>
>Cheers,
>+ Kimmo
>
>
>On Wed, 30 Nov 2022 at 13:20, Luke Mewburn <luke at mewburn.net> wrote:
>>
>> 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
I'll get around to it (and HEAD) in a couple of days if no one else can test til then.
Vlad
More information about the Tcsh
mailing list