Build failure on arch linux. Failed to build Calculator-definitions.cc.o , hashtable error.

Question

Build failure on arch linux. Failed to build Calculator-definitions.cc.o , hashtable error.

Ghoughpteighbteau opened this issue 3 years ago · comments

Describe the bug
Build failure on arch linux

To Reproduce
Steps to reproduce the behavior:
If you have docker, I have a Dockerfile that can reproduce the issue exactly.

FROM archlinux:latest

# Initial package load
RUN pacman -Syu --noconfirm
RUN pacman -S --needed --noconfirm git base-devel sudo fish

# User
RUN useradd -m user\
 && echo "user ALL=(ALL) NOPASSWD:ALL" >/etc/sudoers.d/user
USER user
WORKDIR /home/user

# Test NASC build
RUN sudo pacman -S --noconfirm\
 'gtk3'\
 'libqalculate'\
 'granite'\
 'glib2'\
 'libgee'\
 'gtksourceview3'\
 'libsoup'\
 'webkit2gtk'\
 'intltool'\
 'meson'\
 'vala'
RUN git clone "https://github.com/parnold-x/nasc"
WORKDIR /home/usr/nasc
RUN meson build --prefix=/usr
#RUN ninja -C build install

To use this:

Create an empty folder
Copy the contents to a file called "Dockerfile"
run docker build -t arch-nasc .
run docker run --rm -it arch-nasc
now in the container run ninja -C build install

The output of this produces this error:

FAILED: subprojects/libqalculate/libqalculate/libqalculate.a.p/Calculator-definitions.cc.o
c++ -Isubprojects/libqalculate/libqalculate/libqalculate.a.p -Isubprojects/libqalculate/libqalculate -I../subprojects/libqalculate/libqalculate -Isubprojects/libqalculate -I../subprojects/libq
alculate -Isubprojects/libqalculate/data -I/usr/include/libxml2 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libmount -I/usr/include/blkid -fdiagnostics-color=always -pip
e -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wnon-virtual-dtor -std=c++11 -g -DHAVE_CONFIG_H -fPIC -pthread -MD -MQ subprojects/libqalculate/libqalculate/libqalculate.a.p/Calculator-definitio
ns.cc.o -MF subprojects/libqalculate/libqalculate/libqalculate.a.p/Calculator-definitions.cc.o.d -o subprojects/libqalculate/libqalculate/libqalculate.a.p/Calculator-definitions.cc.o -c ../sub
projects/libqalculate/libqalculate/Calculator-definitions.cc
In file included from /usr/include/c++/10.2.0/ext/hash_map:60,
                 from ../subprojects/libqalculate/libqalculate/Calculator_p.h:30,
                 from ../subprojects/libqalculate/libqalculate/Calculator-definitions.cc:63:
/usr/include/c++/10.2.0/backward/backward_warning.h:32:2: warning: #warning This file includes at least one deprecated or antiquated header which may be removed without further notice at a fut
ure date. Please use a non-deprecated interface with equivalent functionality instead. For a listing of replacement headers and interfaces, consult the file backward_warning.h. To disable this
 warning use -Wno-deprecated. [-Wcpp]
   32 | #warning \
      |  ^~~~~~~
In file included from /usr/include/c++/10.2.0/ext/hash_map:64,
                 from ../subprojects/libqalculate/libqalculate/Calculator_p.h:30,
                 from ../subprojects/libqalculate/libqalculate/Calculator-definitions.cc:63:
/usr/include/c++/10.2.0/backward/hashtable.h: In instantiation of ‘__gnu_cxx::hashtable<_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc>::size_type __gnu_cxx::hashtable<_Val, _Key, _HashF
cn, _ExtractKey, _EqualKey, _Alloc>::_M_bkt_num_key(const key_type&, std::size_t) const [with _Val = std::pair<Unit* const, bool>; _Key = Unit*; _HashFcn = __gnu_cxx::hash<Unit*>; _ExtractKey
= std::_Select1st<std::pair<Unit* const, bool> >; _EqualKey = std::equal_to<Unit*>; _Alloc = std::allocator<bool>; __gnu_cxx::hashtable<_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc>::s
ize_type = long unsigned int; __gnu_cxx::hashtable<_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc>::key_type = Unit*; std::size_t = long unsigned int]’:
/usr/include/c++/10.2.0/backward/hashtable.h:596:30:   required from ‘__gnu_cxx::hashtable<_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc>::size_type __gnu_cxx::hashtable<_Val, _Key, _Ha
shFcn, _ExtractKey, _EqualKey, _Alloc>::_M_bkt_num_key(const key_type&) const [with _Val = std::pair<Unit* const, bool>; _Key = Unit*; _HashFcn = __gnu_cxx::hash<Unit*>; _ExtractKey = std::_Se
lect1st<std::pair<Unit* const, bool> >; _EqualKey = std::equal_to<Unit*>; _Alloc = std::allocator<bool>; __gnu_cxx::hashtable<_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc>::size_type =
 long unsigned int; __gnu_cxx::hashtable<_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc>::key_type = Unit*]’
/usr/include/c++/10.2.0/backward/hashtable.h:519:32:   required from ‘__gnu_cxx::hashtable<_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc>::iterator __gnu_cxx::hashtable<_Val, _Key, _Has
hFcn, _ExtractKey, _EqualKey, _Alloc>::find(const key_type&) [with _Val = std::pair<Unit* const, bool>; _Key = Unit*; _HashFcn = __gnu_cxx::hash<Unit*>; _ExtractKey = std::_Select1st<std::pair
<Unit* const, bool> >; _EqualKey = std::equal_to<Unit*>; _Alloc = std::allocator<bool>; __gnu_cxx::hashtable<_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc>::iterator = __gnu_cxx::hashta
ble<std::pair<Unit* const, bool>, Unit*, __gnu_cxx::hash<Unit*>, std::_Select1st<std::pair<Unit* const, bool> >, std::equal_to<Unit*>, std::allocator<bool> >::iterator; __gnu_cxx::hashtable<_V
al, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc>::key_type = Unit*]’
/usr/include/c++/10.2.0/ext/hash_map:213:26:   required from ‘__gnu_cxx::hash_map<_Key, _Tp, _HashFn, _EqualKey, _Alloc>::iterator __gnu_cxx::hash_map<_Key, _Tp, _HashFn, _EqualKey, _Alloc>::f
ind(const key_type&) [with _Key = Unit*; _Tp = bool; _HashFn = __gnu_cxx::hash<Unit*>; _EqualKey = std::equal_to<Unit*>; _Alloc = std::allocator<bool>; __gnu_cxx::hash_map<_Key, _Tp, _HashFn,
_EqualKey, _Alloc>::iterator = __gnu_cxx::hashtable<std::pair<Unit* const, bool>, Unit*, __gnu_cxx::hash<Unit*>, std::_Select1st<std::pair<Unit* const, bool> >, std::equal_to<Unit*>, std::allo
cator<bool> >::iterator; __gnu_cxx::hash_map<_Key, _Tp, _HashFn, _EqualKey, _Alloc>::key_type = Unit*]’
../subprojects/libqalculate/libqalculate/Calculator-definitions.cc:3432:23:   required from here
/usr/include/c++/10.2.0/backward/hashtable.h:604:23: error: no match for call to ‘(const hasher {aka const __gnu_cxx::hash<Unit*>}) (Unit* const&)’
  604 |       { return _M_hash(__key) % __n; }
      |                ~~~~~~~^~~~~~~

I suspect this may be an error due to an updated library, Maybe a canary for an upcoming problem you will face later? Regardless, I'm clueless how to fix this.

Peter · Answer 1 · Fri Jan 01 2021 03:28:27 GMT+0800 (China Standard Time)

Hi, don't know. I am not into build stuff. Seems to happen when building the subproject https://github.com/Qalculate/libqalculate
Maybe you can try to build it alone if it happens there to.

Ghoughpteighbteau · Answer 2 · Fri Jan 01 2021 03:51:00 GMT+0800 (China Standard Time)

Ah. Oops I should have noticed that. That's a good thing to check.

So I downloaded libqalculate's base repo and it successfully compiled.

I then tried moving into the submodule and building it there and it also successfully built.

So then I went back to nasc and... it failed again. Wut? I don't get it.

Oh by the way looking through the build failure I noticed a second error:

FAILED: subprojects/libqalculate/libqalculate/libqalculate.a.p/BuiltinFunctions-number.cc.o

Seems to be the same basic hasher error.

/usr/include/c++/10.2.0/backward/hashtable.h:604:23: error: no match for call to ‘(const hasher {aka const __gnu_cxx::hash<std::__cxx11::basic_string<char> >}) (const key_type&)’
  604 |       { return _M_hash(__key) % __n; }

So weird.

Peter · Answer 3 · Fri Jan 01 2021 04:20:33 GMT+0800 (China Standard Time)

Mhh, ok. Then it's either the little older state of the subproject or more likely the meson build for libqalculate (upstream uses autotools)

Ghoughpteighbteau · Answer 4 · Fri Jan 01 2021 04:27:47 GMT+0800 (China Standard Time)

Looks like the subproject is on current master of libqalculate, so that should be ok.

Could you do something like depend on an external library if not present?

something like... dep = dependency('foo', fallback : [subproject_name, variable_name]) ?

Ghoughpteighbteau · Answer 5 · Fri Jan 01 2021 04:27:59 GMT+0800 (China Standard Time)

oops. wrong button.

Peter · Answer 6 · Fri Jan 01 2021 06:19:33 GMT+0800 (China Standard Time)

If it still build fine on elementary os yes sure

Ghoughpteighbteau · Answer 7 · Tue Jan 05 2021 03:25:41 GMT+0800 (China Standard Time)

Well. I took a solid stab at it but I really don't know what I'm doing either lol.

Maybe @hanna-kn ? Plz help I no speak meson.

Peter · Answer 8 · Tue Jan 05 2021 21:33:32 GMT+0800 (China Standard Time)

Dude pls don't ping hanna for stuff like this. Like I said libqualculate upstream uses autotools not meson. The meson is only here, so it can be better integrated with this project. Anyway I am open for PRs but closing this as out of scope for this project.

Hanna Knutsson · Answer 9 · Tue Jan 05 2021 23:34:39 GMT+0800 (China Standard Time)

I do not mind providing a quick answer. The issue here seems obvious – HAVE_UNORDERED_MAP is not set. When using autotools, this is set by AC_CHECK_HEADERS([unordered_map]) in configure.ac.

Ghoughpteighbteau · Answer 10 · Wed Jan 06 2021 01:50:56 GMT+0800 (China Standard Time)

Ah I didn't realize libqalculate added those meson.build files specifically for nasc. Sorry, wasn't trying to be rude.

Thanks for the response Hanna. As a sneaky check I went and deleted the #if HAVE_UNORDERED_MAP macros from libqalculate, leaving behind:

#	include <unordered_map>
	using std::unordered_map;

just to assume it was set, and that worked. nasc builds under these conditions. I'm not sure how to exactly set that from in meson. But that was a super helpful clue!

edit:

So if I revert my changes and throw in config_data.set('HAVE_UNORDERED_MAP', '1') in libqalculate's meson.build, that works as well, but that doesn't seem right, I'd presume we need to check if we actually have unordered map somehow? I'm not familiar with how autotools is checking this and the conditions on which it sets those values. Or even if such a setting is reasonable for elementaryOS.

@parnold-x if you'd like me to buzz off, I can just introduce a patch into the AUR PKGFILE.

Peter · Answer 11 · Wed Jan 06 2021 18:31:23 GMT+0800 (China Standard Time)

Thanks Hanna! Just thought to not bother you.
@Ghoughpteighbteau No that's not what I mean't, I personally jut got no time and motivation for this build stuff. I still happy to merge a solution. Not sure what this UNORDERED_MAP thing does. Maybe as build option to pass to meson or as default when it does not matter? To check the build on eOS, you can open a PR and it should build it.

Hanna Knutsson · Answer 12 · Wed Jan 06 2021 18:44:51 GMT+0800 (China Standard Time)

It's should be safe to always set HAVE_UNORDERED_MAP to 1 (unordered_map should be supported on everything but very old systems – hash_map is deprecated since GCC 4.3).