You are not logged in.
Two days ago I did a complete system upgrade and upgrade glibc and gcc to latest version:
glibc (2.23-1 -> 2.23-2)
gcc-multilib (5.3.0-5 -> 6.1.1-1)
gcc-libs-multilib (5.3.0-5 -> 6.1.1-1)
Since then I have not been able to build some packages from the AUR. In particular I am talking about FLANN and OpenNI but I am sure I would get the same result with many others as well.
I am getting linking errors like the following:
In file included from /home/arch/user/build/pcl-1.7/deps/test/flann/src/flann-1.8.4-src/src/cpp/flann/algorithms/all_indices.h:36:0,
from /home/arch/user/build/pcl-1.7/deps/test/flann/src/flann-1.8.4-src/src/cpp/flann/flann.hpp:45,
from /home/arch/user/build/pcl-1.7/deps/test/flann/src/flann-1.8.4-src/src/cpp/flann/flann.h:466,
from /home/arch/user/build/pcl-1.7/deps/test/flann/src/flann-1.8.4-src/src/cpp/flann/flann.cpp:31:
/home/arch/user/build/pcl-1.7/deps/test/flann/src/flann-1.8.4-src/src/cpp/flann/algorithms/kdtree_index.h: In instantiation of ‘void flann::KDTreeIndex<Distance>::addPointToTree(flann::KDTreeIndex<Distance>::NodePtr, int) [with Distance = flann::KL_Divergence<double>; flann::KDTreeIndex<Distance>::NodePtr = flann::KDTreeIndex<flann::KL_Divergence<double> >::Node*]’:
/home/arch/user/build/pcl-1.7/deps/test/flann/src/flann-1.8.4-src/src/cpp/flann/algorithms/kdtree_index.h:154:35: required from ‘void flann::KDTreeIndex<Distance>::addPoints(const flann::Matrix<typename Distance::ElementType>&, float) [with Distance = flann::KL_Divergence<double>; typename Distance::ElementType = double]’
/home/arch/user/build/pcl-1.7/deps/test/flann/src/flann-1.8.4-src/src/cpp/flann/flann.cpp:884:1: required from here
/home/arch/user/build/pcl-1.7/deps/test/flann/src/flann-1.8.4-src/src/cpp/flann/algorithms/kdtree_index.h:666:39: error: call of overloaded ‘abs(flann::KDTreeIndex<flann::KL_Divergence<double> >::ElementType)’ is ambiguous
ElementType span = abs(point[i]-leaf_point[i]);
~~~^~~~~~~~~~~~~~~~~~~~~~~~
In file included from /usr/include/c++/6.1.1/cstdlib:75:0,
from /usr/include/c++/6.1.1/bits/stl_algo.h:59,
from /usr/include/c++/6.1.1/algorithm:62,
from /home/arch/user/build/pcl-1.7/deps/test/flann/src/flann-1.8.4-src/src/cpp/flann/util/result_set.h:34,
from /home/arch/user/build/pcl-1.7/deps/test/flann/src/flann-1.8.4-src/src/cpp/flann/algorithms/nn_index.h:39,
from /home/arch/user/build/pcl-1.7/deps/test/flann/src/flann-1.8.4-src/src/cpp/flann/algorithms/all_indices.h:35,
from /home/arch/user/build/pcl-1.7/deps/test/flann/src/flann-1.8.4-src/src/cpp/flann/flann.hpp:45,
from /home/arch/user/build/pcl-1.7/deps/test/flann/src/flann-1.8.4-src/src/cpp/flann/flann.h:466,
from /home/arch/user/build/pcl-1.7/deps/test/flann/src/flann-1.8.4-src/src/cpp/flann/flann.cpp:31:
/usr/include/stdlib.h:774:12: note: candidate: int abs(int)
extern int abs (int __x) __THROW __attribute__ ((__const__)) __wur;
^~~
In file included from /usr/include/c++/6.1.1/bits/stl_algo.h:59:0,
from /usr/include/c++/6.1.1/algorithm:62,
from /home/arch/user/build/pcl-1.7/deps/test/flann/src/flann-1.8.4-src/src/cpp/flann/util/result_set.h:34,
from /home/arch/user/build/pcl-1.7/deps/test/flann/src/flann-1.8.4-src/src/cpp/flann/algorithms/nn_index.h:39,
from /home/arch/user/build/pcl-1.7/deps/test/flann/src/flann-1.8.4-src/src/cpp/flann/algorithms/all_indices.h:35,
from /home/arch/user/build/pcl-1.7/deps/test/flann/src/flann-1.8.4-src/src/cpp/flann/flann.hpp:45,
from /home/arch/user/build/pcl-1.7/deps/test/flann/src/flann-1.8.4-src/src/cpp/flann/flann.h:466,
from /home/arch/user/build/pcl-1.7/deps/test/flann/src/flann-1.8.4-src/src/cpp/flann/flann.cpp:31:
/usr/include/c++/6.1.1/cstdlib:185:3: note: candidate: __int128 std::abs(__int128)
abs(__GLIBCXX_TYPE_INT_N_0 __x) { return __x >= 0 ? __x : -__x; }
^~~
/usr/include/c++/6.1.1/cstdlib:180:3: note: candidate: long long int std::abs(long long int)
abs(long long __x) { return __builtin_llabs (__x); }
^~~
/usr/include/c++/6.1.1/cstdlib:172:3: note: candidate: long int std::abs(long int)
abs(long __i) { return __builtin_labs(__i); }
First thought was to compile with -std=gnu++98 flag, as gcc 6 defaults to -std=gnu++14 (as pointed here: https://gcc.gnu.org/gcc-6/changes.html). After getting the same result, I kept reading and found information about a change in the C++ glibc ABI (https://gcc.gnu.org/onlinedocs/libstdc+ … l_abi.html and https://www.archlinux.org/news/c-abi-change/), i therefore tried -D_GLIBCXX_USE_CXX11_ABI=0 macro and -fabi-version as well. Did not work either.
I am running out of ideas. Perhaps I would need to link to a previous version of glibc? is that even possible? Hope that someone that has faced this problem before can give me some advice.
Thank you beforehand,
Ferran
Last edited by poinu (2016-05-12 10:04:39)
Offline
Yup, same problem here with building nvidia-340xx-dkms module. I'm back to gcc 5.3 for now which does work with new glibc 2.23-2
Research | Trial | Make Mistakes | Ask questions | Learn | Repeat
Offline
The code needs to be ported to make it compile with GCC6, see https://gcc.gnu.org/gcc-6/porting_to.html.
You can usually find patches in Fedora scm, see eg. http://pkgs.fedoraproject.org/cgit/rpms … gcc6.patch
Offline
I thought about downgrading gcc, but as the last option, I was really looking for a nicer solution...
Then, if I understood properly, you said it won't be possible to compile not c++14 code with gcc 6 and posterior versions? I wonder what happens then with old code that is no longer maintained, it's a lot of work to patch everything! (Thank you for pointing me to the Fedora patches, I didn't know that).
Just to understand it properly, what is the reasoning behind this issue? What makes gcc 6 incompatible with the other ABI? As far as I know you could use both in gcc 5.
Offline
You can still compile non C++14 code with -std=gnu++98. This particular issue has nothing to do with C++14 or with the ABI, this is a change in the gcc standard library (the compiler).
Offline
Then it's not a glibc problem but gcc-libs, right? Is it possible to have multiple gcc-libs and specify the one to use in linking time?
Offline
Just use the patch posted above...
Offline
Allan,
Will you be updating the gcc related Arch packages with this or other solution?
Research | Trial | Make Mistakes | Ask questions | Learn | Repeat
Offline
Allan,
Will you be updating the gcc related Arch packages with this or other solution?
Why would I? gcc is not broken...
Offline
Just use the patch posted above...
It's not like there's going to be a patch for every single piece of software
Offline
There really is... Fedora has already rebuilt their entire repos using gcc-6.
Offline
Well, not really convinced but thanks for the hints, I'll try to figure out!
Offline