Error compiling 1.11.0 with LLVM and musl

[doitwithnotepad]

Seems to be something related to an incomplete type being used in a standard library container, specifically std::vector<std::pair<QByteArray, (anonymous namespace)::Container>> located on src/Json/Json_Parser.cpp.
Compile just fine with g++ with the same setup.

System:

Alpine Linux 3.20.2 cloud image
Linux 6.6.41-0-virt
x86_64

Compiling flags:

CC="clang"\
CXX="${CC}++"\
CFLAGS="-O3 -pipe -march=native -fPIE"
CXXFLAGS="$CFLAGS"
LDFLAGS="-pie -Wl,--as-needed"
MAKEFLAGS="-j$(nproc)"

Dependencies:

apk add autoconf clang git lz4-dev make pkgconf qt6-qtbase-dev rocksdb-dev zeromq-dev libzmq qt6-qtbase rocksdb libstdc++
# jemalloc needs to be compiled
cd /tmp
VERSION=5.3.0
wget https://github.com/jemalloc/jemalloc/releases/download/$VERSION/jemalloc-$VERSION.tar.bz2
tar xjf jemalloc-$VERSION.tar.bz2 && cd jemalloc-$VERSION
printf "$VERSION\n" > VERSION
 
sed 's/  \*-\*-linux\*)/  \*-\*-linux-musl\*)\
\tdnl syscall(2) and secure_getenv(3) are exposed by _GNU_SOURCE.\
\tJE_APPEND_VS(CPPFLAGS, -D_GNU_SOURCE)\
\tabi="elf"\
\tAC_DEFINE([JEMALLOC_PURGE_MADVISE_DONTNEED_ZEROS], [ ], [ ])\
\tAC_DEFINE([JEMALLOC_HAS_ALLOCA_H], [ ], [ ])\
\tAC_DEFINE([JEMALLOC_PROC_SYS_VM_OVERCOMMIT_MEMORY], [ ], [ ])\
\tAC_DEFINE([JEMALLOC_THREADED_INIT], [ ], [ ])\
\tif test "${LG_SIZEOF_PTR}" = "3"; then\
\t\tdefault_retain="1"\
\tfi\
\tzero_realloc_default_free="1"\
\t;;\
  \*-\*-linux\*)/' \
    configure.ac > _
mv -f _ configure.ac
 
sed 's/(__FreeBSD__))/(__FreeBSD__) || (defined(__linux__) \&\& !defined(__GLIBC__)))/' \
    include/jemalloc/jemalloc_macros.h.in > _
mv -f _ include/jemalloc/jemalloc_macros.h.in
 
./autogen.sh \
    --prefix=/usr \
    --enable-xmalloc \
    --enable-shared \
    --disable-static \
    --disable-doc \
    --with-lg-page=12 \
    --with-lg-hugepage=21
make
make install_lib install_include

Steps to reproduce:

cd /tmp
VERSION=1.11.0
git clone --branch v$VERSION https://github.com/cculianu/Fulcrum.git && cd Fulcrum
qmake6 \
    Fulcrum.pro \
    -spec "linux-$CC" \
    -o build/
make -C build

Error:

[...]
In file included from ../src/Json/Json_Parser.cpp:26:
In file included from ../src/Json/Json.h:28:
In file included from ../src/Common.h:21:
In file included from /usr/include/qt6/QtCore/QString:1:
In file included from /usr/include/qt6/QtCore/qstring.h:14:
In file included from /usr/include/qt6/QtCore/qchar.h:9:
In file included from /usr/bin/../lib/gcc/x86_64-alpine-linux-musl/13.2.1/../../../../include/c++/13.2.1/functional:64:
In file included from /usr/bin/../lib/gcc/x86_64-alpine-linux-musl/13.2.1/../../../../include/c++/13.2.1/vector:66:
/usr/bin/../lib/gcc/x86_64-alpine-linux-musl/13.2.1/../../../../include/c++/13.2.1/bits/stl_vector.h:367:35: error: arithmetic on a pointer to an incomplete type 'std::pair<QByteArray, (anonymous namespace)::Container>'
  367 |                       _M_impl._M_end_of_storage - _M_impl._M_start);
      |                       ~~~~~~~~~~~~~~~~~~~~~~~~~ ^
/usr/bin/../lib/gcc/x86_64-alpine-linux-musl/13.2.1/../../../../include/c++/13.2.1/bits/stl_vector.h:528:7: note: in instantiation of member function 'std::_Vector_base<std::pair<QByteArray, (anonymous namespace)::Container>, std::allocator<std::pair<QByteArray, (anonymous namespace)::Container>>>::~_Vector_base' requested here
  528 |       vector() = default;
      |       ^
/usr/bin/../lib/gcc/x86_64-alpine-linux-musl/13.2.1/../../../../include/c++/13.2.1/type_traits:1246:60: note: in defaulted default constructor for 'std::vector<std::pair<QByteArray, (anonymous namespace)::Container>>' first required here
 1246 |                             decltype(__helper<const _Tp&>({}))* = 0);
      |                                                            ^
/usr/bin/../lib/gcc/x86_64-alpine-linux-musl/13.2.1/../../../../include/c++/13.2.1/type_traits:1255:24: note: while substituting deduced template arguments into function template '__test' [with _Tp = (anonymous namespace)::Container]
 1255 |       typedef decltype(__test(declval<_Tp>())) type;
      |                        ^
/usr/bin/../lib/gcc/x86_64-alpine-linux-musl/13.2.1/../../../../include/c++/13.2.1/type_traits:1260:14: note: in instantiation of template class 'std::__is_implicitly_default_constructible_impl<(anonymous namespace)::Container>' requested here
 1260 |     : public __is_implicitly_default_constructible_impl<_Tp>::type
      |              ^
/usr/bin/../lib/gcc/x86_64-alpine-linux-musl/13.2.1/../../../../include/c++/13.2.1/type_traits:161:30: note: in instantiation of template class 'std::__is_implicitly_default_constructible_safe<(anonymous namespace)::Container>' requested here
  161 |                                       __enable_if_t<bool(_Bn::value)>...>;
      |                                                          ^
/usr/bin/../lib/gcc/x86_64-alpine-linux-musl/13.2.1/../../../../include/c++/13.2.1/type_traits:177:16: note: (skipping 18 contexts in backtrace; use -ftemplate-backtrace-limit=0 to see all)
  177 |     : decltype(__detail::__and_fn<_Bn...>(0))
      |                ^
/usr/bin/../lib/gcc/x86_64-alpine-linux-musl/13.2.1/../../../../include/c++/13.2.1/bits/stl_construct.h:193:35: note: in instantiation of function template specialization 'std::_Destroy_aux<false>::__destroy<(anonymous namespace)::Container *>' requested here
  193 |         return std::_Destroy_aux<false>::__destroy(__first, __last);
      |                                          ^
/usr/bin/../lib/gcc/x86_64-alpine-linux-musl/13.2.1/../../../../include/c++/13.2.1/bits/alloc_traits.h:948:12: note: in instantiation of function template specialization 'std::_Destroy<(anonymous namespace)::Container *>' requested here
  948 |       std::_Destroy(__first, __last);
      |            ^
/usr/bin/../lib/gcc/x86_64-alpine-linux-musl/13.2.1/../../../../include/c++/13.2.1/bits/stl_vector.h:1934:11: note: in instantiation of function template specialization 'std::_Destroy<(anonymous namespace)::Container *, (anonymous namespace)::Container>' requested here
 1934 |             std::_Destroy(__pos, this->_M_impl._M_finish,
      |                  ^
/usr/bin/../lib/gcc/x86_64-alpine-linux-musl/13.2.1/../../../../include/c++/13.2.1/bits/stl_vector.h:1603:9: note: in instantiation of member function 'std::vector<(anonymous namespace)::Container>::_M_erase_at_end' requested here
 1603 |       { _M_erase_at_end(this->_M_impl._M_start); }
      |         ^
../src/Json/Json_Parser.cpp:538:41: note: in instantiation of member function 'std::vector<(anonymous namespace)::Container>::clear' requested here
  538 |     void clear() { data.clear(); values.clear(); entries.clear(); typ = Null; }
      |                                         ^
/usr/bin/../lib/gcc/x86_64-alpine-linux-musl/13.2.1/../../../../include/c++/13.2.1/bits/stl_iterator.h:2992:12: note: definition of 'std::pair<QByteArray, (anonymous namespace)::Container>' is not complete until the closing '}'
 2992 |     struct pair;
      |            ^
1 error generated.
make: *** [Makefile:1571: Json_Parser.o] Error 1
make: *** Waiting for unfinished jobs....
make: Leaving directory '/tmp/Fulcrum/build'

[cculianu]

The incomplete type seems to be std::pair which is an ISO standard c++ type.

Either musl lacks std::pair or it has some bugs, I don't know.

I do not officially support musl.. too niche.. and too incomplete.

If you can figure out a patch to fix this, it's welcome but I lack the time to support this. Sorry man.

[doitwithnotepad]

Thanks, but if i change the step to reproduce to VERSION=1.10.0 it compiles flawlessly, and theres also some std::pair in it...

[cculianu]

Hmm. Ah, interesting.

Well one big difference is that 1.11.0 switched the compiler standard to use C++20. Maybe there's something weird/out of spec with musl and C++20?

[cculianu]

Hmm.

I wonder if this error might be related to llvm trying to use libstcd++ (gcc's C++ headers and lib) rather than its own libc++ (clang C++ headers and lib)... from the paths in the above error log it looks like that might be what's going on.

And it could be that with language standard c++17 it "just worked" but with c++20 somehow that trips things up.

You may have to figure out what flags to use to use the llvm/clang headers?

No idea man.. this is kind of beyond the scope of my time commitments right now.. but if you do figure it out, patches welcome.

[doitwithnotepad]

It's out of my scope too, but I found some possible related problems. Maybe someone could find the issues helpful. llvm/llvm-project#62166 llvm/llvm-project#59966 llvm/llvm-project#59292