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

[Vlad Meșco]

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
>
>I guess one can do something weird like:
>defined(__linux__) && !defined(__GLIBC__)
>to work around this...
>
>christos
>
>
>> On Nov 26, 2022, at 2:09 PM, Nelson H. F. Beebe <beebe at math.utah.edu> wrote:
>> 
>> Thanks, Vlad, for the extra information about the Alpine Linux
>> community repository and their aports tree.
>> 
>> Because of the large number of VMs that I maintain in our test lab,
>> and because we need to do builds of major systems, like TeX Live, in
>> fairly stock environments, I tend not to enable additional
>> repositories, or do builds from source code in distribution-supplied
>> ports tree.
>> 
>> Still, it is good to have gotten recorded on this list that there are
>> multiple ways to get tcsh onto Alpine Linux, and I'm very pleased to
>> have had your good advice over the last couple of days.  Thanks again!
>> 
>> -------------------------------------------------------------------------------
>> - Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
>> - University of Utah                                                          -
>> - Department of Mathematics, 110 LCB    Internet e-mail: beebe at math.utah.edu  -
>> - 155 S 1400 E RM 233                       beebe at acm.org  beebe at computer.org -
>> - Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
>> -------------------------------------------------------------------------------
>> --
>> Tcsh mailing list
>> Tcsh at astron.com
>> https://mailman.astron.com/mailman/listinfo/tcsh
>

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.

I'd encourage Nelson to subscribe to the patches from aports/tcsh and integrate them into whatever ad-hoc build system they want to use there (I mean, someone on Alpine bothered figuring it out; even if you don't want prebuilt binaries, you can still integrate their patches.)

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.

Or similar to how Nelson added `#ifdef Alpine' to the list, then defined Alpine in CFLAGS, maybe add a `&& MUST_USE_SYSMALLOC' for ports to define as-needed?

Also, I'm not entirely sure why that header forcefully `undef' symbols instead of leaving them undefined. It sounds like the exact "problem" I complained about not long ago about SHORT_STRINGS being forced off on OpenBSD without a patch. I guess it all comes back to the comment in the file saying these are arbitrary defaults and we're free to change them. But I digress.

Further digression: I read through the last 2 links and I didn't get the impression musl is causing problems for programs who want to use other allocators -- at most, some allocators have trouble building, though others apparently work fine...?

Best regards,
Vlad