Can't compile in alpine linux

[asierguti]

Hi there,

I am trying to compile folly inside a alpine docker container. This is the error that I get.

bash-5.0# make -j8
[ 1%] Building CXX object CMakeFiles/folly_base.dir/folly/experimental/symbolizer/Elf.cpp.o
/root/folly/folly/experimental/symbolizer/Elf.cpp: In member function 'folly::symbolizer::ElfFile::OpenResult folly::symbolizer::ElfFile::init()':
/root/folly/folly/experimental/symbolizer/Elf.cpp:226:27: error: 'ELFCLASSFOLLY_ELF_NATIVE_CLASS' was not declared in this scope
226 | #define EXPECTED_CLASS P1(ELFCLASS, FOLLY_ELF_NATIVE_CLASS)
| ^~~~~~~~
/root/folly/folly/experimental/symbolizer/Elf.cpp:228:18: note: in definition of macro 'P2'
228 | #define P2(a, b) a##b
| ^
/root/folly/folly/experimental/symbolizer/Elf.cpp:226:24: note: in expansion of macro 'P1'
226 | #define EXPECTED_CLASS P1(ELFCLASS, FOLLY_ELF_NATIVE_CLASS)
| ^~
/root/folly/folly/experimental/symbolizer/Elf.cpp:230:38: note: in expansion of macro 'EXPECTED_CLASS'
230 | if (elfHeader.e_ident[EI_CLASS] != EXPECTED_CLASS) {
| ^~~~~~~~~~~~~~
make[2]: *** [CMakeFiles/folly_base.dir/build.make:1421: CMakeFiles/folly_base.dir/folly/experimental/symbolizer/Elf.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:216: CMakeFiles/folly_base.dir/all] Error 2
make: *** [Makefile:149: all] Error 2

I guess it has to do with the fact that alpine uses musl instead of glibc. Any ideas how to fix this?

Cheers,
Asier

[mateusmedeiros]

Just hit that myself while trying to build in alpine.

The problem seems to be that the file expects __ELF_NATIVE_CLASS to be defined at least for platforms besides FreeBSD-based ones, and so it defines FOLLY_ELF_NATIVE_CLASS with it.

folly/folly/experimental/symbolizer/Elf.cpp

Lines 38 to 48 in c7245ac

	#if defined(__ELF_NATIVE_CLASS)
	#define FOLLY_ELF_NATIVE_CLASS __ELF_NATIVE_CLASS
	#elif defined(__FreeBSD__)
	#if defined(__LP64__)
	#define FOLLY_ELF_NATIVE_CLASS 64
	#else
	#define FOLLY_ELF_NATIVE_CLASS 32
	#endif
	#endif // __ELF_NATIVE_CLASS

Without __ELF_NATIVE_CLASS (and apparently musl does not define it), FOLLY_ELF_NATIVE_CLASS is also not defined so what was supposed to be expanded to ELFCLASS32 or ELFCLASS64 ends up being ELFCLASSFOLLY_ELF_NATIVE_CLASS.

My hacky workaround was to manually include sys/reg.h and define __ELF_NATIVE_CLASS to __WORDSIZE.

--- a.txt
+++ b.txt
@@ -2,6 +2,15 @@
 #define STT_GNU_IFUNC 10
 #endif

+#include <sys/reg.h>
+#define __ELF_NATIVE_CLASS __WORDSIZE
+
 #if defined(__ELF_NATIVE_CLASS)
 #define FOLLY_ELF_NATIVE_CLASS __ELF_NATIVE_CLASS
 #elif defined(__FreeBSD__)
 #if defined(__LP64__)
 #define FOLLY_ELF_NATIVE_CLASS 64
 #else
 #define FOLLY_ELF_NATIVE_CLASS 32
 #endif
 #endif // __ELF_NATIVE_CLASS

Though looking at it now I guess what would make more sense would be to use the FreeBSD fallback, something like:

--- a.txt
+++ b.txt
@@ -4,10 +4,8 @@

 #if defined(__ELF_NATIVE_CLASS)
 #define FOLLY_ELF_NATIVE_CLASS __ELF_NATIVE_CLASS
-#elif defined(__FreeBSD__)
-#if defined(__LP64__)
+#elif defined(__LP64__)
 #define FOLLY_ELF_NATIVE_CLASS 64
 #else
 #define FOLLY_ELF_NATIVE_CLASS 32
-#endif
 #endif // __ELF_NATIVE_CLASS

I don't have enough knowledge to come out with the actual proper solution, but at least for my own build here it did the trick.

[asierguti]

Thanks a lot for the tip.

Yes, it worked. I had to link with libexecinfo also, but other than that, everything worked like a charm.

Cheers!

[asierguti]

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 2a3865d57..de5e92a8b 100755
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -541,6 +541,7 @@ if (BUILD_TESTS)
       folly
       ${LIBGMOCK_LIBRARIES}
       ${GLOG_LIBRARY}
+      libexecinfo
   )
   apply_folly_compile_options_to_target(folly_test_support)

[ronaldtse]

A hark back from 4 years ago -- is there interest in making folly compatible with musl-based platforms like Alpine? It would save much distribution efforts in carrying these patches around.

[yfeldblum]

A hark back from 4 years ago -- is there interest in making folly compatible with musl-based platforms like Alpine? It would save much distribution efforts in carrying these patches around.

I would say it's not the highest priority. But as long as it's all reasonable and not all too much effort, we can merge some patches.