Building epics-base fails on musl based systems

[Sébastien Wertz]

I am trying to build EPICS base 7.0.4 inside a docker container based on alpine linux, which uses musl in place of glibc.

The build options used are CXXFLAGS="-DIPPORT_USERRESERVED=5000 -fPIC".

The build fails because the "backtrace" function does not exist in musl:

/usr/bin/g++ -o iocLogServer -L/EPICS/base/lib/linux-x86_64 -Wl,-rpath,/EPICS/base/lib/linux-x86_64 -rdynamic -m64 iocLogServer.o -lCom
/usr/lib/gcc/x86_64-alpine-linux-musl/9.2.0/../../../../x86_64-alpine-linux-musl/bin/ld: /EPICS/base/lib/linux-x86_64/libCom.so: undefined reference to `backtrace'
collect2: error: ld returned 1 exit status

Looking into epics-base/modules/libcom/src/osi/os/posix/osdExecinfoBackTrace.cpp, which is the only file using that function, I was in the end able to successfully build EPICS by adding "-D__UCLIBC_MAJOR__=0" to the build options.

However, it would be better to detect the presence of backtrace() by testing the existence of __GLIBC__ or __GNU_LIBRARY__, or, alternatively, to provide the user with the possibility of disabling backtrace support.

[mdavidsaver (mdavidsaver)]

The "posix" code in Base supports more than just Linux with glibc, uclibc, or perhaps musl. It also includes the c libraries from Apple, freebsd, and (at least for the moment) solaris. All of these provide the backtrace() function. So it is easier to express uclibc as the exception.

Still, I think it would be acceptable if someone were motivated to figure out all of the relevant macros, and do the testing. Perhaps aided by:

https://sourceforge.net/p/predef/wiki/Home/

Personally. I looked into musl recently and was disappointed by the deliberate omission of identifying macros (eg. __MUSL__). It strikes me as presumptuous for a new entrant to demand a rewrite and retest of existing compatibility logic as a price of entry. Maybe it would be better to use uclibc instead of musl?

https://wiki.musl-libc.org/faq.html#Q:-Why-is-there-no-%3Ccode%3E__MUSL__%3C/code%3E-macro?

[J. Lewis Muir (jlmuir)]

I think it would be better to test for the presence of the backtrace() function at build time. This is what Autoconf and various other build configuration systems do. It's much better to test for a feature than an OS version or, in this case, a C standard library implementation.

[Andrew Johnson (anj)]

The os/posix/osdExecinfoBackTrace.cpp file is pretty simple, so someone could put a copy of it in the os/Linux directory which would then take precedence over the posix one for Linux targets. That would be where the code could explicitly look for glibc and uclib and assume musl if not – Michael's SourceForge page above provides help with how to detect the others. I don't know how many other libc's are in use on Linux, hopefully none of the others take musl's approach to compile-time identification.

The alternative would be to require musl users to add a line like
    OP_SYS_CPPFLAGS += -D__MUSL__
to their configure/os/CONFIG_SITE.Common.linux-x86_64 file before building and to use that as another input to the macros in os/posix/osdExecinfoBackTrace.cpp.

We would be happy to see a patch file implementing one of these two approaches.

[mdavidsaver (mdavidsaver)]

> OP_SYS_CPPFLAGS += -D__MUSL__

I know I've argued against this pattern in the past, and we are moving away from it. ('-DUNIX', '-DCYGWIN32', '-Dlinux', etc.) In the case of musl though, it seems to me the least bad solution.

[Sébastien Wertz (sebastien-wertz)]

Thanks for the quick feedback!

> Maybe it would be better to use uclibc instead of musl?

This is unfortunately not feasible here, when using base container images themselves built on top of a linux distro that uses musl.

> The alternative would be to require musl users to add a line like
> OP_SYS_CPPFLAGS += -D__MUSL__
> to their configure/os/CONFIG_SITE.Common.linux-x86_64 file before building and to use that as another input to the macros in os/posix/osdExecinfoBackTrace.cpp.

This would be entirely acceptable (provided it is documented)!