parnoldx / nasc

Do maths like a normal person
http://parnoldx.github.io/nasc/
GNU General Public License v3.0
560 stars 37 forks source link

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

Closed Ghoughpteighbteau closed 3 years ago

Ghoughpteighbteau commented 3 years ago

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:

  1. Create an empty folder
  2. Copy the contents to a file called "Dockerfile"
  3. run docker build -t arch-nasc .
  4. run docker run --rm -it arch-nasc
  5. 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.

parnoldx commented 3 years ago

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 commented 3 years ago

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.

parnoldx commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

oops. wrong button.

parnoldx commented 3 years ago

If it still build fine on elementary os yes sure

Ghoughpteighbteau commented 3 years ago

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.

parnoldx commented 3 years ago

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-kn commented 3 years ago

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 commented 3 years ago

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.

parnoldx commented 3 years ago

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-kn commented 3 years ago

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).