Add support support for musl libc on linux

[BenJarg]

These changes are to make it possible to compile xrootd on musl libc, which is a standards conforming C standard library for linux. I put this together while packaging xrootd for void linux, which supports both glibc and musl ( void-linux/void-packages#34647 ).

[matthewfeickert]

@BenJarg do you have suggestions on additions that need to be made to the build chain? It would be helpful if you could both:

• Add a build test stage to .github/workflows/build.yml
• Rebase this branch to pick up some additional fixes

[Chocimier]

Hello,

here is a workflow building on musl Void: https://github.com/Chocimier/xrootd/commits/musl

[matthewfeickert]

Hello,

here is a workflow building on musl Void: https://github.com/Chocimier/xrootd/commits/musl

@BenJarg Do you want to take @Chocimier's CI contributions and commit those to this PR with a co-author note in the commit? e.g.

Co-authored-by: =?UTF-8?q?Piotr=20W=C3=B3jcik?= <chocimier@tlen.pl>

(@Chocimier that's what shows up as your name associated with commits at least according to https://github.com/Chocimier/xrootd/commit/be6e4dae6b617672ff11062d8e5a6d8fa9b97ddb.patch — if that's supposed to just be Piotr can you let us know?)

[BenJarg]

Rebased and added @Chocimier 's contributions. I see them listed as the author and me the committer; let me know if there's something else to do to make that more clear.

[Chocimier]

Fine for me.

[abh3]

OK, it seems no one really wants to take ownership of this. So, here is the problem. The patch here depends on inference (i.e. we have Linux and not something else). That is not a good approach. This patch will only be accepted if actual availability has been prescreened and a specific cmake variable has been set for applicability. That is, there needs to be a test to determine that must is indeed available and would set a specific cmake variable (i.e. have_muscl) this would then determine what is actually compiled. I am sorry to say that the current way of doing this is way to problematic.

[BenJarg]

@abh3 Yeah, this patch was originally an ad hoc solution to get xrootd to compile on musl for Void Linux, where glibc and musl are the two possible libcs. I went ahead and added some checks in cmake to see if all the relevent musl things are available given it's not glibc, then defines HAVE_MUSL_LIBC if they are. Let me know if you'd like any changes to the way this is done.

[simonmichal]

@BenJarg : are those tests:

     check_function_exists( __fseterr HAVE_fseterr )
     check_include_file( bits/alltypes.h HAVE_BITS_ALLTYPES )
     check_include_file( stdio_ext.h HAVE_STDIO_EXT )

unique for musl?

In general it looks good, all the tests passed including the one you added for voidlinux.

Maybe just to be on the safe side let's ask @amadio for his opinion ;-)

[BenJarg]

@simonmichal As far as I can tell, __fseterr and bits/alltypes.h are unique to musl, or at least I don't see them in glibc or the other Linux libcs I checked. Those three things are the features used in the musl-specific code blocks, so I think testing the three of them should be enough. Although, I don't have a lot of experience with alternative libcs, so input from others would be appreciated.

[amadio]

I am taking a look at merging this for 5.6. I think some of the changes can be simplified, though, like including sys/types.h in a few places rather than bits/alltypes.h with specific defines.

[amadio]

This has been superceded by #1908, which I just merged into the master branch. Thanks for the initial work on this!