Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
[solved]emerge of sys-devel/binutils-2.29.1-r1 fails on RPi2
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Gentoo on ARM
View previous topic :: View next topic  
Author Message
christoph_peter_s
n00b
n00b


Joined: 30 Nov 2015
Posts: 39

PostPosted: Tue Dec 05, 2017 5:45 pm    Post subject: [solved]emerge of sys-devel/binutils-2.29.1-r1 fails on RPi2 Reply with quote

Dear Gentoo experts,

I have persistent problems during a recent upgrade, as sys-devel/binutils-2.29.1-r1 fails to compile. The machine is a Raspi 2. To track the issue down, I did first mount a heat sink on the CPU. This did not show any difference. So I switched the hardware to an RPi 3. But now change. I have the impression, that it always crashes at the same place...

Code:

/bin/sh ./libtool --tag=CC   --mode=link armv7a-hardfloat-linux-gnueabi-gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Wstack-usage=262144  -O2 -pipe -march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=hard  -Wl,-O1 -Wl,--as-needed -o bfdtest1 bfdtest1.o ../bfd/libbfd.la ../libiberty/libiberty.a  -ldl
libtool: link: armv7a-hardfloat-linux-gnueabi-gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Wstack-usage=262144 -O2 -pipe -march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=hard -Wl,-O1 -o .libs/cxxfilt cxxfilt.o bucomm.o version.o filemode.o  -Wl,--as-needed ../bfd/.libs/libbfd.so -L/var/tmp/portage/sys-devel/binutils-2.29.1-r1/work/build/bfd/../libiberty/pic -liberty -lz ../libiberty/libiberty.a -ldl -Wl,-rpath -Wl,/usr/lib/binutils/armv7a-hardfloat-linux-gnueabi/2.29.1
/bin/sh ./libtool --tag=CC   --mode=link armv7a-hardfloat-linux-gnueabi-gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Wstack-usage=262144  -O2 -pipe -march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=hard  -Wl,-O1 -Wl,--as-needed -o bfdtest2 bfdtest2.o ../bfd/libbfd.la ../libiberty/libiberty.a  -ldl
libtool: link: armv7a-hardfloat-linux-gnueabi-gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Wstack-usage=262144 -O2 -pipe -march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=hard -Wl,-O1 -o .libs/bfdtest1 bfdtest1.o  -Wl,--as-needed ../bfd/.libs/libbfd.so -L/var/tmp/portage/sys-devel/binutils-2.29.1-r1/work/build/bfd/../libiberty/pic -liberty -lz ../libiberty/libiberty.a -ldl -Wl,-rpath -Wl,/usr/lib/binutils/armv7a-hardfloat-linux-gnueabi/2.29.1
libtool: link: armv7a-hardfloat-linux-gnueabi-gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Wstack-usage=262144 -O2 -pipe -march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=hard -Wl,-O1 -o .libs/bfdtest2 bfdtest2.o  -Wl,--as-needed ../bfd/.libs/libbfd.so -L/var/tmp/portage/sys-devel/binutils-2.29.1-r1/work/build/bfd/../libiberty/pic -liberty -lz ../libiberty/libiberty.a -ldl -Wl,-rpath -Wl,/usr/lib/binutils/armv7a-hardfloat-linux-gnueabi/2.29.1
mv -f .deps/readelf.Tpo .deps/readelf.Po
/bin/sh ./libtool --tag=CC   --mode=link armv7a-hardfloat-linux-gnueabi-gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Wstack-usage=262144  -O2 -pipe -march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=hard  -Wl,-O1 -Wl,--as-needed -o readelf readelf.o version.o unwind-ia64.o dwarf.o elfcomm.o  ../libiberty/libiberty.a -lz -ldl
libtool: link: armv7a-hardfloat-linux-gnueabi-gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Wstack-usage=262144 -O2 -pipe -march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=hard -Wl,-O1 -o readelf readelf.o version.o unwind-ia64.o dwarf.o elfcomm.o  -Wl,--as-needed ../libiberty/libiberty.a -lz -ldl
make[4]: Leaving directory '/var/tmp/portage/sys-devel/binutils-2.29.1-r1/work/build/binutils'
make[3]: Leaving directory '/var/tmp/portage/sys-devel/binutils-2.29.1-r1/work/build/binutils'
make[2]: Leaving directory '/var/tmp/portage/sys-devel/binutils-2.29.1-r1/work/build/binutils'
make[1]: Leaving directory '/var/tmp/portage/sys-devel/binutils-2.29.1-r1/work/build'
make: *** [Makefile:850: all] Error 2
 * ERROR: sys-devel/binutils-2.29.1-r1::gentoo failed (compile phase):
 *   emake failed


Then I went back to the RPi2 and tried the following sequence:
Code:
emerge --ask --oneshot sys-devel/gcc
emerge --ask --oneshot sys-devel/libtool
emerge --ask --oneshot sys-devel/llvm
emerge --ask --oneshot sys-devel/binutils


No change. I tried:
Code:
emerge --ask --emptrytree @system

Still no change. I had the impression, that the error message points to issues in the tool chain. I had troubles with the file system some time ago, as it crashed during a reboot. But I am pretty clueless on what's really going on - and on how to fix the issue. I really need Your assistence.

Thank You in advance & Best regards
Peter


PS: here are the informations, which the error message asked for...

emerge --info: http://www.serbe.ch/~peter/gentoo/binutils_info.txt
emerge -pqv: http://www.serbe.ch/~peter/gentoo/binutils_pqv.txt
build log: http://www.serbe.ch/~peter/gentoo/binutils_build.log
ebuild env.: http://www.serbe.ch/~peter/gentoo/binutils_env.txt


Last edited by christoph_peter_s on Sat Dec 09, 2017 8:45 am; edited 3 times in total
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 39261
Location: 56N 3W

PostPosted: Tue Dec 05, 2017 6:02 pm    Post subject: Reply with quote

christoph_peter_s,

There is no error message in your build log fragment. Its at line 2988/3061 of your log.
The log is difficult to read because of all the ANSI escape sequences and the MAKEOPTS="-j3"

If you use wgetpaste to pastebin the log listed in the instructions, it should test be raw text.

I think the error is
Code:
 ^[[01m^[[K/usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/5.4.0/include/g++-v5/backward/hashtable.h:609:31:^[[m^[[K ^[[01;31m^[[Kerror: ^[[m^[[Kno match for call to '^[[01m^[[K(const hasher {aka const __gnu_cxx::hash<long long int>}) (const key_type&)^[[m^[[K'
       { return _M_hash(__key) % __n; }
^[[01;32m^[[K                               ^^[[m^[[K


That's no match for call to ...
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
christoph_peter_s
n00b
n00b


Joined: 30 Nov 2015
Posts: 39

PostPosted: Tue Dec 05, 2017 6:29 pm    Post subject: Reply with quote

Hi Neddy,

I'll try to fix the issue with the characterset of my logs. And yes, I did note the error in hashtable.h - but what is the consequence of this? Did I hit a bug - or is it me, doing something silly?

Best regards
Peter

PS: I will run it on 1 core, so there'll be an update in an hour or so. It is a slow little machine... I hope that I can fix the readability of the logs, too. I switched to an ISO locale.

PS2: OK, now with "-j1" - same error. Does not look like a raspi H/W issue to me...
here's what I got in the console window:

Code:

mv -f .deps/fileread.Tpo .deps/fileread.Po
armv7a-hardfloat-linux-gnueabi-g++ -DHAVE_CONFIG_H -I. -I/var/tmp/portage/sys-devel/binutils-2.29.1-r1/work/binutils-2.29.1/gold  -I/var/tmp/portage/sys-devel/binutils-2.29.1-r1/work/binutils-2.29.1/gold -I/var/tmp/portage/sys-devel/binutils-2.29.1-r1/work/binutils-2.29.1/gold/../include -I/var/tmp/portage/sys-devel/binutils-2.29.1-r1/work/binutils-2.29.1/gold/../elfcpp -DLOCALEDIR="\"/usr/share/binutils-data/armv7a-hardfloat-linux-gnueabi/2.29.1/locale\"" -DBINDIR="\"/usr/armv7a-hardfloat-linux-gnueabi/binutils-bin/2.29.1\"" -DTOOLBINDIR="\"/usr/armv7a-hardfloat-linux-gnueabi/bin\"" -DTOOLLIBDIR="\"/usr/armv7a-hardfloat-linux-gnueabi/lib\""   -W -Wall    -Wstack-usage=262144 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -frandom-seed=gc.o  -O2 -pipe -march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=hard -MT gc.o -MD -MP -MF .deps/gc.Tpo -c -o gc.o /var/tmp/portage/sys-devel/binutils-2.29.1-r1/work/binutils-2.29.1/gold/gc.cc
In file included from /usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/5.4.0/include/g++-v5/ext/hash_map:60:0,
                 from /var/tmp/portage/sys-devel/binutils-2.29.1-r1/work/binutils-2.29.1/gold/system.h:105,
                 from /var/tmp/portage/sys-devel/binutils-2.29.1-r1/work/binutils-2.29.1/gold/gold.h:35,
                 from /var/tmp/portage/sys-devel/binutils-2.29.1-r1/work/binutils-2.29.1/gold/gc.cc:24:
/usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/5.4.0/include/g++-v5/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 future 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]
 #warning \
  ^
mv -f .deps/gc.Tpo .deps/gc.Po
armv7a-hardfloat-linux-gnueabi-g++ -DHAVE_CONFIG_H -I. -I/var/tmp/portage/sys-devel/binutils-2.29.1-r1/work/binutils-2.29.1/gold  -I/var/tmp/portage/sys-devel/binutils-2.29.1-r1/work/binutils-2.29.1/gold -I/var/tmp/portage/sys-devel/binutils-2.29.1-r1/work/binutils-2.29.1/gold/../include -I/var/tmp/portage/sys-devel/binutils-2.29.1-r1/work/binutils-2.29.1/gold/../elfcpp -DLOCALEDIR="\"/usr/share/binutils-data/armv7a-hardfloat-linux-gnueabi/2.29.1/locale\"" -DBINDIR="\"/usr/armv7a-hardfloat-linux-gnueabi/binutils-bin/2.29.1\"" -DTOOLBINDIR="\"/usr/armv7a-hardfloat-linux-gnueabi/bin\"" -DTOOLLIBDIR="\"/usr/armv7a-hardfloat-linux-gnueabi/lib\""   -W -Wall    -Wstack-usage=262144 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -frandom-seed=gdb-index.o  -O2 -pipe -march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=hard -MT gdb-index.o -MD -MP -MF .deps/gdb-index.Tpo -c -o gdb-index.o /var/tmp/portage/sys-devel/binutils-2.29.1-r1/work/binutils-2.29.1/gold/gdb-index.cc
In file included from /usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/5.4.0/include/g++-v5/ext/hash_map:60:0,
                 from /var/tmp/portage/sys-devel/binutils-2.29.1-r1/work/binutils-2.29.1/gold/system.h:105,
                 from /var/tmp/portage/sys-devel/binutils-2.29.1-r1/work/binutils-2.29.1/gold/gold.h:35,
                 from /var/tmp/portage/sys-devel/binutils-2.29.1-r1/work/binutils-2.29.1/gold/gdb-index.cc:23:
/usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/5.4.0/include/g++-v5/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 future 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]
 #warning \
  ^
In file included from /usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/5.4.0/include/g++-v5/ext/hash_map:64:0,
                 from /var/tmp/portage/sys-devel/binutils-2.29.1-r1/work/binutils-2.29.1/gold/system.h:105,
                 from /var/tmp/portage/sys-devel/binutils-2.29.1-r1/work/binutils-2.29.1/gold/gold.h:35,
                 from /var/tmp/portage/sys-devel/binutils-2.29.1-r1/work/binutils-2.29.1/gold/gdb-index.cc:23:
/usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/5.4.0/include/g++-v5/backward/hashtable.h: In instantiation of '__gnu_cxx::hashtable<_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc>::size_type __gnu_cxx::hashtable<_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc>::_M_bkt_num_key(const key_type&, std::size_t) const [with _Val = std::pair<const long long int, gold::Gdb_index_info_reader::Declaration_pair>; _Key = long long int; _HashFcn = __gnu_cxx::hash<long long int>; _ExtractKey = std::_Select1st<std::pair<const long long int, gold::Gdb_index_info_reader::Declaration_pair> >; _EqualKey = std::equal_to<long long int>; _Alloc = std::allocator<gold::Gdb_index_info_reader::Declaration_pair>; __gnu_cxx::hashtable<_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc>::size_type = unsigned int; __gnu_cxx::hashtable<_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc>::key_type = long long int; std::size_t = unsigned int]':
/usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/5.4.0/include/g++-v5/backward/hashtable.h:601:30:   required from  __gnu_cxx::hashtable<_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc>::size_type __gnu_cxx::hashtable<_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc>::_M_bkt_num_key(const key_type&) const [with _Val = std::pair<const long long int, gold::Gdb_index_info_reader::Declaration_pair>; _Key = long long int; _HashFcn = __gnu_cxx::hash<long long int>; _ExtractKey = std::_Select1st<std::pair<const long long int, gold::Gdb_index_info_reader::Declaration_pair> >; _EqualKey = std::equal_to<long long int>; _Alloc = std::allocator<gold::Gdb_index_info_reader::Declaration_pair>; __gnu_cxx::hashtable<_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc>::size_type = unsigned int; __gnu_cxx::hashtable<_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc>::key_type = long long int]'
/usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/5.4.0/include/g++-v5/backward/hashtable.h:524:32:   required from  __gnu_cxx::hashtable<_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc>::iterator __gnu_cxx::hashtable<_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc>::find(const key_type&) [with _Val = std::pair<const long long int, gold::Gdb_index_info_reader::Declaration_pair>; _Key = long long int; _HashFcn = __gnu_cxx::hash<long long int>; _ExtractKey = std::_Select1st<std::pair<const long long int, gold::Gdb_index_info_reader::Declaration_pair> >; _EqualKey = std::equal_to<long long int>; _Alloc = std::allocator<gold::Gdb_index_info_reader::Declaration_pair>; __gnu_cxx::hashtable<_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc>::iterator = __gnu_cxx::_Hashtable_iterator<std::pair<const long long int, gold::Gdb_index_info_reader::Declaration_pair>, long long int, __gnu_cxx::hash<long long int>, std::_Select1st<std::pair<const long long int, gold::Gdb_index_info_reader::Declaration_pair> >, std::equal_to<long long int>, std::allocator<gold::Gdb_index_info_reader::Declaration_pair> >; __gnu_cxx::hashtable<_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc>::key_type = long long int]'
/usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/5.4.0/include/g++-v5/ext/hash_map:213:32:   required from '__gnu_cxx::hash_map<_Key, _Tp, _HashFn, _EqualKey, _Alloc>::iterator __gnu_cxx::hash_map<_Key, _Tp, _HashFn, _EqualKey, _Alloc>::find(const key_type&) [with _Key = long long int; _Tp = gold::Gdb_index_info_reader::Declaration_pair; _HashFn = __gnu_cxx::hash<long long int>; _EqualKey = std::equal_to<long long int>; _Alloc = std::allocator<gold::Gdb_index_info_reader::Declaration_pair>; __gnu_cxx::hash_map<_Key, _Tp, _HashFn, _EqualKey, _Alloc>::iterator = __gnu_cxx::_Hashtable_iterator<std::pair<const long long int, gold::Gdb_index_info_reader::Declaration_pair>, long long int, __gnu_cxx::hash<long long int>, std::_Select1st<std::pair<const long long int, gold::Gdb_index_info_reader::Declaration_pair> >, std::equal_to<long long int>, std::allocator<gold::Gdb_index_info_reader::Declaration_pair> >; __gnu_cxx::hash_map<_Key, _Tp, _HashFn, _EqualKey, _Alloc>::key_type = long long int]'
/var/tmp/portage/sys-devel/binutils-2.29.1-r1/work/binutils-2.29.1/gold/gdb-index.cc:703:67:   required from here
/usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/5.4.0/include/g++-v5/backward/hashtable.h:609:31: error: no match for call to '(const hasher {aka const __gnu_cxx::hash<long long int>}) (const key_type&)'
       { return _M_hash(__key) % __n; }
                               ^
/usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/5.4.0/include/g++-v5/backward/hashtable.h: In instantiation of '__gnu_cxx::hashtable<_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc>::size_type __gnu_cxx::hashtable<_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc>::_M_bkt_num_key(const key_type&, std::size_t) const [with _Val = std::pair<const long long int, long long int>; _Key = long long int; _HashFcn = __gnu_cxx::hash<long long int>; _ExtractKey = std::_Select1st<std::pair<const long long int, long long int> >; _EqualKey = std::equal_to<long long int>; _Alloc = std::allocator<long long int>; __gnu_cxx::hashtable<_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc>::size_type = unsigned int; __gnu_cxx::hashtable<_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc>::key_type = long long int; std::size_t = unsigned int]':
/usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/5.4.0/include/g++-v5/backward/hashtable.h:601:30:   required from  __gnu_cxx::hashtable<_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc>::size_type __gnu_cxx::hashtable<_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc>::_M_bkt_num_key(const key_type&) const [with _Val = std::pair<const long long int, long long int>; _Key = long long int; _HashFcn = __gnu_cxx::hash<long long int>; _ExtractKey = std::_Select1st<std::pair<const long long int, long long int> >; _EqualKey = std::equal_to<long long int>; _Alloc = std::allocator<long long int>; __gnu_cxx::hashtable<_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc>::size_type = unsigned int; __gnu_cxx::hashtable<_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc>::key_type = long long int]'
/usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/5.4.0/include/g++-v5/backward/hashtable.h:524:32:   required from  __gnu_cxx::hashtable<_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc>::iterator __gnu_cxx::hashtable<_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc>::find(const key_type&) [with _Val = std::pair<const long long int, long long int>; _Key = long long int; _HashFcn = __gnu_cxx::hash<long long int>; _ExtractKey = std::_Select1st<std::pair<const long long int, long long int> >; _EqualKey = std::equal_to<long long int>; _Alloc = std::allocator<long long int>; __gnu_cxx::hashtable<_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc>::iterator = __gnu_cxx::_Hashtable_iterator<std::pair<const long long int, long long int>, long long int, __gnu_cxx::hash<long long int>, std::_Select1st<std::pair<const long long int, long long int> >, std::equal_to<long long int>, std::allocator<long long int> >; __gnu_cxx::hashtable<_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc>::key_type = long long int]'
/usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/5.4.0/include/g++-v5/ext/hash_map:213:32:   required from '__gnu_cxx::hash_map<_Key, _Tp, _HashFn, _EqualKey, _Alloc>::iterator __gnu_cxx::hash_map<_Key, _Tp, _HashFn, _EqualKey, _Alloc>::find(const key_type&) [with _Key = long long int; _Tp = long long int; _HashFn = __gnu_cxx::hash<long long int>; _EqualKey = std::equal_to<long long int>; _Alloc = std::allocator<long long int>; __gnu_cxx::hash_map<_Key, _Tp, _HashFn, _EqualKey, _Alloc>::iterator = __gnu_cxx::_Hashtable_iterator<std::pair<const long long int, long long int>, long long int, __gnu_cxx::hash<long long int>, std::_Select1st<std::pair<const long long int, long long int> >, std::equal_to<long long int>, std::allocator<long long int> >; __gnu_cxx::hash_map<_Key, _Tp, _HashFn, _EqualKey, _Alloc>::key_type = long long int]'
/var/tmp/portage/sys-devel/binutils-2.29.1-r1/work/binutils-2.29.1/gold/gdb-index.cc:1085:73:   required from here
/usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/5.4.0/include/g++-v5/backward/hashtable.h:609:31: error: no match for call to '(const hasher {aka const __gnu_cxx::hash<long long int>}) (const key_type&)'
make[4]: *** [Makefile:918: gdb-index.o] Error 1
make[4]: Leaving directory '/var/tmp/portage/sys-devel/binutils-2.29.1-r1/work/build/gold'
make[3]: *** [Makefile:941: all-recursive] Error 1
make[3]: Leaving directory '/var/tmp/portage/sys-devel/binutils-2.29.1-r1/work/build/gold'
make[2]: *** [Makefile:692: all] Error 2
make[2]: Leaving directory '/var/tmp/portage/sys-devel/binutils-2.29.1-r1/work/build/gold'
make[1]: *** [Makefile:6043: all-gold] Error 2
make[1]: Leaving directory '/var/tmp/portage/sys-devel/binutils-2.29.1-r1/work/build'
make: *** [Makefile:850: all] Error 2
 * ERROR: sys-devel/binutils-2.29.1-r1::gentoo failed (compile phase):
 *   emake failed
 *


I'll update the linked files from my initial post within the next minutes.
Back to top
View user's profile Send private message
xaviermiller
Administrator
Administrator


Joined: 23 Jul 2004
Posts: 7306
Location: ~Brussels - Belgique

PostPosted: Tue Dec 05, 2017 8:29 pm    Post subject: Reply with quote

Moved from Portage & Programming to Gentoo on ARM.
_________________
Kind regards,
Xavier Miller
Back to top
View user's profile Send private message
christoph_peter_s
n00b
n00b


Joined: 30 Nov 2015
Posts: 39

PostPosted: Tue Dec 05, 2017 10:00 pm    Post subject: Reply with quote

I'd like to extend my question: is there any chance, that the compilation would succeed, if I'd upgrade to gcc 6.4.0 (which I expect to become an official update for the ARM branch anyway - sooner or later).

TIA
Peter

PS: yes, I could try this - but the raspi is so slow, that I prefer to ask the question first. It's not that I was totally lazy...
Back to top
View user's profile Send private message
christoph_peter_s
n00b
n00b


Joined: 30 Nov 2015
Posts: 39

PostPosted: Wed Dec 06, 2017 10:06 am    Post subject: Reply with quote

What I tried in the meantime:
clean all the cached package files (I thought something could have been garbled here) - no success
downgrade sys-libs/binutils-libs to match the version of the installed binutils package - no success
I now mask the 2.29 versions of binutils and binutils-libs and reemerge @system with emptytree. If this doesn't solve the issue either, I was completely stuck. I expect my raspi to work on it for the rest of the day... I hope, as allways, but without much confidence.

Best regards
Peter
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 39261
Location: 56N 3W

PostPosted: Wed Dec 06, 2017 10:09 am    Post subject: Reply with quote

christoph_peter_s,

No cross distcc ?
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
christoph_peter_s
n00b
n00b


Joined: 30 Nov 2015
Posts: 39

PostPosted: Wed Dec 06, 2017 10:33 am    Post subject: Reply with quote

Hi Neddy,

no, I haven't worked this out so far. So I compile natively on the raspi itself. I have a prejudice, that the native compile is slow but more reliable. Is this incorrect? Besides the slow SD card limits the compilations speed anyway...

Best regards
Peter


Btw: A big thank You for Your work on the 64bit raspi. I got one here, which will make up my next OpenVPN server. I am fully aware, that Your work is the basis for this option.
Back to top
View user's profile Send private message
christoph_peter_s
n00b
n00b


Joined: 30 Nov 2015
Posts: 39

PostPosted: Thu Dec 07, 2017 10:37 am    Post subject: Reply with quote

The emerge --emptytree @system failed while building sys-devel/binutils-2.28.1 (the one, which is installed) at exactly the same location.
I did emerge binutils on a RPi1 and did compare the related files (archive.cc backward_warning.h gdb-index.cc gold.h hash_map hashtable.h system.h) - but all are indentical. Then I compared the build log, where there are a few differences - but nothing that would point me to something useful. Anyway, maybe it is more useful for the eye of an expert...

These are the lines from the failed build, which differ from the log from the good machine:
Code:

>>> cfg-update-1.8.2-r1: Checksum index is up-to-date ...
...
checking whether a statically linked program can dlopen itself...  * Unable to trace static ELF: ./conftest: ./conftest
no
...
checking tr1/unordered_set usability... no
checking tr1/unordered_set presence... no
checking for tr1/unordered_set... no
checking tr1/unordered_map usability... no
checking tr1/unordered_map presence... no
checking for tr1/unordered_map... no
...
checking whether ::std::tr1::unordered_map::rehash is usable.... no
checking whether std::tr1::hash<off_t> is defined... no
...
In file included from /usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/5.4.0/include/g++-v5/ext/hash_map:60:0,
                 from /var/tmp/portage/sys-devel/binutils-2.29.1-r1/work/binutils-2.29.1/gold/system.h:105,
                 from /var/tmp/portage/sys-devel/binutils-2.29.1-r1/work/binutils-2.29.1/gold/gold.h:35,
                 from /var/tmp/portage/sys-devel/binutils-2.29.1-r1/work/binutils-2.29.1/gold/archive.cc:23:
/usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/5.4.0/include/g++-v5/backward/backward_warning.h:32:2: [Kwarning: #warning This file includes at least one deprecated or antiquated header which may be removed without further notice at a future 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]
 #warning \
  ^
... (warning shows up many times)
...
armv7a-hardfloat-linux-gnueabi-g++ -DHAVE_CONFIG_H -I. -I/var/tmp/portage/sys-devel/binutils-2.29.1-r1/work/binutils-2.29.1/gold  -I/var/tmp/portage/sys-devel/binutils-2.29.1-r1/work/binutils-2.29.1/gold -I/var/tmp/portage/sys-devel/binutils-2.29.1-r1/work/binutils-2.29.1/gold/../include -I/var/tmp/portage/sys-devel/binutils-2.29.1-r1/work/binutils-2.29.1/gold/../elfcpp -DLOCALEDIR="\"/usr/share/binutils-data/armv7a-hardfloat-linux-gnueabi/2.29.1/locale\"" -DBINDIR="\"/usr/armv7a-hardfloat-linux-gnueabi/binutils-bin/2.29.1\"" -DTOOLBINDIR="\"/usr/armv7a-hardfloat-linux-gnueabi/bin\"" -DTOOLLIBDIR="\"/usr/armv7a-hardfloat-linux-gnueabi/lib\""   -W -Wall    -Wstack-usage=262144 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -frandom-seed=gdb-index.o  -O2 -pipe -march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=hard -MT gdb-index.o -MD -MP -MF .deps/gdb-index.Tpo -c -o gdb-index.o /var/tmp/portage/sys-devel/binutils-2.29.1-r1/work/binutils-2.29.1/gold/gdb-index.cc
In file included from /usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/5.4.0/include/g++-v5/ext/hash_map:60:0,
                 from /var/tmp/portage/sys-devel/binutils-2.29.1-r1/work/binutils-2.29.1/gold/system.h:105,
                 from /var/tmp/portage/sys-devel/binutils-2.29.1-r1/work/binutils-2.29.1/gold/gold.h:35,
                 from /var/tmp/portage/sys-devel/binutils-2.29.1-r1/work/binutils-2.29.1/gold/gdb-index.cc:23:
/usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/5.4.0/include/g++-v5/backward/backward_warning.h:32:2: [Kwarning: #warning This file includes at least one deprecated or antiquated header which may be removed without further notice at a future 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]
 #warning \
  ^
In file included from /usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/5.4.0/include/g++-v5/ext/hash_map:64:0,
                 from /var/tmp/portage/sys-devel/binutils-2.29.1-r1/work/binutils-2.29.1/gold/system.h:105,
                 from /var/tmp/portage/sys-devel/binutils-2.29.1-r1/work/binutils-2.29.1/gold/gold.h:35,
                 from /var/tmp/portage/sys-devel/binutils-2.29.1-r1/work/binutils-2.29.1/gold/gdb-index.cc:23:
/usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/5.4.0/include/g++-v5/backward/hashtable.h: In instantiation of '__gnu_cxx::hashtable<_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc>::size_type __gnu_cxx::hashtable<_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc>::_M_bkt_num_key(const key_type&, std::size_t) const [with _Val = std::pair<const long long int, gold::Gdb_index_info_reader::Declaration_pair>; _Key = long long int; _HashFcn = __gnu_cxx::hash<long long int>; _ExtractKey = std::_Select1st<std::pair<const long long int, gold::Gdb_index_info_reader::Declaration_pair> >; _EqualKey = std::equal_to<long long int>; _Alloc = std::allocator<gold::Gdb_index_info_reader::Declaration_pair>; __gnu_cxx::hashtable<_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc>::size_type = unsigned int; __gnu_cxx::hashtable<_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc>::key_type = long long int; std::size_t = unsigned int]':
/usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/5.4.0/include/g++-v5/backward/hashtable.h:601:30:   required from '__gnu_cxx::hashtable<_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc>::size_type __gnu_cxx::hashtable<_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc>::_M_bkt_num_key(const key_type&) const [with _Val = std::pair<const long long int, gold::Gdb_index_info_reader::Declaration_pair>; _Key = long long int; _HashFcn = __gnu_cxx::hash<long long int>; _ExtractKey = std::_Select1st<std::pair<const long long int, gold::Gdb_index_info_reader::Declaration_pair> >; _EqualKey = std::equal_to<long long int>; _Alloc = std::allocator<gold::Gdb_index_info_reader::Declaration_pair>; __gnu_cxx::hashtable<_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc>::size_type = unsigned int; __gnu_cxx::hashtable<_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc>::key_type = long long int]'
/usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/5.4.0/include/g++-v5/backward/hashtable.h:524:32:   required from '__gnu_cxx::hashtable<_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc>::iterator __gnu_cxx::hashtable<_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc>::find(const key_type&) [with _Val = std::pair<const long long int, gold::Gdb_index_info_reader::Declaration_pair>; _Key = long long int; _HashFcn = __gnu_cxx::hash<long long int>; _ExtractKey = std::_Select1st<std::pair<const long long int, gold::Gdb_index_info_reader::Declaration_pair> >; _EqualKey = std::equal_to<long long int>; _Alloc = std::allocator<gold::Gdb_index_info_reader::Declaration_pair>; __gnu_cxx::hashtable<_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc>::iterator = __gnu_cxx::_Hashtable_iterator<std::pair<const long long int, gold::Gdb_index_info_reader::Declaration_pair>, long long int, __gnu_cxx::hash<long long int>, std::_Select1st<std::pair<const long long int, gold::Gdb_index_info_reader::Declaration_pair> >, std::equal_to<long long int>, std::allocator<gold::Gdb_index_info_reader::Declaration_pair> >; __gnu_cxx::hashtable<_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc>::key_type = long long int]'
/usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/5.4.0/include/g++-v5/ext/hash_map:213:32:   required from '__gnu_cxx::hash_map<_Key, _Tp, _HashFn, _EqualKey, _Alloc>::iterator __gnu_cxx::hash_map<_Key, _Tp, _HashFn, _EqualKey, _Alloc>::find(const key_type&) [with _Key = long long int; _Tp = gold::Gdb_index_info_reader::Declaration_pair; _HashFn = __gnu_cxx::hash<long long int>; _EqualKey = std::equal_to<long long int>; _Alloc = std::allocator<gold::Gdb_index_info_reader::Declaration_pair>; __gnu_cxx::hash_map<_Key, _Tp, _HashFn, _EqualKey, _Alloc>::iterator = __gnu_cxx::_Hashtable_iterator<std::pair<const long long int, gold::Gdb_index_info_reader::Declaration_pair>, long long int, __gnu_cxx::hash<long long int>, std::_Select1st<std::pair<const long long int, gold::Gdb_index_info_reader::Declaration_pair> >, std::equal_to<long long int>, std::allocator<gold::Gdb_index_info_reader::Declaration_pair> >; __gnu_cxx::hash_map<_Key, _Tp, _HashFn, _EqualKey, _Alloc>::key_type = long long int]'
/var/tmp/portage/sys-devel/binutils-2.29.1-r1/work/binutils-2.29.1/gold/gdb-index.cc:703:67:   required from here
/usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/5.4.0/include/g++-v5/backward/hashtable.h:609:31: Kerror: no match for call to '(const hasher {aka const __gnu_cxx::hash<long long int>}) (const key_type&)'
       { return _M_hash(__key) % __n; }
                               ^
/usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/5.4.0/include/g++-v5/backward/hashtable.h: In instantiation of '__gnu_cxx::hashtable<_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc>::size_type __gnu_cxx::hashtable<_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc>::_M_bkt_num_key(const key_type&, std::size_t) const [with _Val = std::pair<const long long int, long long int>; _Key = long long int; _HashFcn = __gnu_cxx::hash<long long int>; _ExtractKey = std::_Select1st<std::pair<const long long int, long long int> >; _EqualKey = std::equal_to<long long int>; _Alloc = std::allocator<long long int>; __gnu_cxx::hashtable<_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc>::size_type = unsigned int; __gnu_cxx::hashtable<_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc>::key_type = long long int; std::size_t = unsigned int]':
/usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/5.4.0/include/g++-v5/backward/hashtable.h:601:30:   required from '__gnu_cxx::hashtable<_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc>::size_type __gnu_cxx::hashtable<_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc>::_M_bkt_num_key(const key_type&) const [with _Val = std::pair<const long long int, long long int>; _Key = long long int; _HashFcn = __gnu_cxx::hash<long long int>; _ExtractKey = std::_Select1st<std::pair<const long long int, long long int> >; _EqualKey = std::equal_to<long long int>; _Alloc = std::allocator<long long int>; __gnu_cxx::hashtable<_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc>::size_type = unsigned int; __gnu_cxx::hashtable<_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc>::key_type = long long int]'
/usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/5.4.0/include/g++-v5/backward/hashtable.h:524:32:   required from '__gnu_cxx::hashtable<_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc>::iterator __gnu_cxx::hashtable<_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc>::find(const key_type&) [with _Val = std::pair<const long long int, long long int>; _Key = long long int; _HashFcn = __gnu_cxx::hash<long long int>; _ExtractKey = std::_Select1st<std::pair<const long long int, long long int> >; _EqualKey = std::equal_to<long long int>; _Alloc = std::allocator<long long int>; __gnu_cxx::hashtable<_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc>::iterator = __gnu_cxx::_Hashtable_iterator<std::pair<const long long int, long long int>, long long int, __gnu_cxx::hash<long long int>, std::_Select1st<std::pair<const long long int, long long int> >, std::equal_to<long long int>, std::allocator<long long int> >; __gnu_cxx::hashtable<_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc>::key_type = long long int]'
/usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/5.4.0/include/g++-v5/ext/hash_map:213:32:   required from '__gnu_cxx::hash_map<_Key, _Tp, _HashFn, _EqualKey, _Alloc>::iterator __gnu_cxx::hash_map<_Key, _Tp, _HashFn, _EqualKey, _Alloc>::find(const key_type&) [with _Key = long long int; _Tp = long long int; _HashFn = __gnu_cxx::hash<long long int>; _EqualKey = std::equal_to<long long int>; _Alloc = std::allocator<long long int>; __gnu_cxx::hash_map<_Key, _Tp, _HashFn, _EqualKey, _Alloc>::iterator = __gnu_cxx::_Hashtable_iterator<std::pair<const long long int, long long int>, long long int, __gnu_cxx::hash<long long int>, std::_Select1st<std::pair<const long long int, long long int> >, std::equal_to<long long int>, std::allocator<long long int> >; __gnu_cxx::hash_map<_Key, _Tp, _HashFn, _EqualKey, _Alloc>::key_type = long long int]'
/var/tmp/portage/sys-devel/binutils-2.29.1-r1/work/binutils-2.29.1/gold/gdb-index.cc:1085:73:   required from here
/usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/5.4.0/include/g++-v5/backward/hashtable.h:609:31: error: no match for call to '(const hasher {aka const __gnu_cxx::hash<long long int>}) (const key_type&)'
make[4]: *** [Makefile:918: gdb-index.o] Error 1
make[4]: Leaving directory '/var/tmp/portage/sys-devel/binutils-2.29.1-r1/work/build/gold'
make[3]: *** [Makefile:941: all-recursive] Error 1
make[3]: Leaving directory '/var/tmp/portage/sys-devel/binutils-2.29.1-r1/work/build/gold'
make[2]: *** [Makefile:692: all] Error 2
make[2]: Leaving directory '/var/tmp/portage/sys-devel/binutils-2.29.1-r1/work/build/gold'
make[1]: *** [Makefile:6043: all-gold] Error 2
make[1]: Leaving directory '/var/tmp/portage/sys-devel/binutils-2.29.1-r1/work/build'
make: *** [Makefile:850: all] Error 2
 * ERROR: sys-devel/binutils-2.29.1-r1::gentoo failed (compile phase):
 *   emake failed
 *
 * If you need support, post the output of `emerge --info '=sys-devel/binutils-2.29.1-r1::gentoo'`,
 * the complete build log and the output of `emerge -pqv '=sys-devel/binutils-2.29.1-r1::gentoo'`.
 * The complete build log is located at '/var/tmp/portage/sys-devel/binutils-2.29.1-r1/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/sys-devel/binutils-2.29.1-r1/temp/environment'.
 * Working directory: '/var/tmp/portage/sys-devel/binutils-2.29.1-r1/work/build'
 * S: '/var/tmp/portage/sys-devel/binutils-2.29.1-r1/work/binutils-2.29.1'


Note, that the failing command ...
Code:

armv7a-hardfloat-linux-gnueabi-g++ -DHAVE_CONFIG_H -I. -I/var/tmp/portage/sys-devel/binutils-2.29.1-r1/work/binutils-2.29.1/gold  -I/var/tmp/portage/sys-devel/binutils-2.29.1-r1/work/binutils-2.29.1/gold -I/var/tmp/portage/sys-devel/binutils-2.29.1-r1/work/binutils-2.29.1/gold/../include -I/var/tmp/portage/sys-devel/binutils-2.29.1-r1/work/binutils-2.29.1/gold/../elfcpp -DLOCALEDIR="\"/usr/share/binutils-data/armv7a-hardfloat-linux-gnueabi/2.29.1/locale\"" -DBINDIR="\"/usr/armv7a-hardfloat-linux-gnueabi/binutils-bin/2.29.1\"" -DTOOLBINDIR="\"/usr/armv7a-hardfloat-linux-gnueabi/bin\"" -DTOOLLIBDIR="\"/usr/armv7a-hardfloat-linux-gnueabi/lib\""   -W -Wall    -Wstack-usage=262144 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -frandom-seed=gc.o  -O2 -pipe -march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=hard -MT gc.o -MD -MP -MF .deps/gc.Tpo -c -o gc.o /var/tmp/portage/sys-devel/binutils-2.29.1-r1/work/binutils-2.29.1/gold/gc.cc

... is exactly the same on the good machine except for the changed architecture (armv6j vs. armv7a) and the fpu (vfp vs. vfpv3-d16).
What does look fishy, is that the warnings do not show up on the good machine. But I am completely ignorant on what measures could be taken to fix this. It looks a bit on subtle differences in the behaviour of gcc. But where to continue?

Best regards
Peter

PS: I did run it on a VM on my ARM-based router - and the differences between the build log from there exactly matches the good one from the RPi 1. Except, that the VM uses Python 3.5 vs. 2.7 on the Raspis. OK, so there are differences in tr1 and unordered_hash, something with static elf traceablity and the fishy warnings...
Back to top
View user's profile Send private message
christoph_peter_s
n00b
n00b


Joined: 30 Nov 2015
Posts: 39

PostPosted: Sat Dec 09, 2017 8:44 am    Post subject: success - finally... Reply with quote

Hi there,

the raspi seems to have some issues, too. Maybe the heat sink is too small, don't know exactly. Anyway, the emerge -e @system crashed while compiling gcc (with -j3 option). I switched back to "-j1" and reemerged gcc. Now it looks like it was compiling OK. It definitely made it over the problematic call.

There are only minimal differences in the present build log vs. the log of the failing compile. First there are some differences in whitespace, which I regard as irrelevant. And only a few real differences...

Code:

checking tr1/unordered_set usability... yes
checking tr1/unordered_set presence... yes
checking for tr1/unordered_set... yes
checking tr1/unordered_map usability... yes
checking tr1/unordered_map presence... yes
checking for tr1/unordered_map... yes
...
checking whether ::std::tr1::unordered_map::rehash is usable.... yes
checking whether std::tr1::hash<off_t> is defined... yes


So it looks like constant pursuit did solve the issue.

Best regards
Peter
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 39261
Location: 56N 3W

PostPosted: Sat Dec 09, 2017 11:01 am    Post subject: Reply with quote

christoph_peter_s,

Compiling natively is safe but slow. Not everything cross compiles properly.
I use a USB HDD to avoid building on SD.

I have had a problem with cross distcc and glibc. It builds, then won't boot.
I have no idea why. It seems that not all versions are affected.
cross distcc is great when it works.

gcc with -j3 probably ran out of RAM. Its written in C++ and C++ can require 1G or more to compile in.
Learn to use /etc/portage/env and /etc/portage/package.env so you don't need to remember.
I've seen over 2G swap used with some things in 64 bit.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
christoph_peter_s
n00b
n00b


Joined: 30 Nov 2015
Posts: 39

PostPosted: Sun Dec 10, 2017 10:21 pm    Post subject: Reply with quote

NeddySeagoon wrote:
Compiling natively is safe but slow. Not everything cross compiles properly.


Hi Neddy,

yes, that is one important point. The other is, that I use these raspi's as domain controllers for my home use IT infrastructure. The file servers (on two locations) are big machines with plenty of disk space. But for two persons (even if they have plenty of files on the server) a raspi is fully satisfactory as DC. So the raspis are running 24/7 and they are mostly running idle. I start these upgrading compilations tasks in a screen session - and check what have happened on the next day. What I try to explain is, that I do not suffer from the low speed...

Quote:
I use a USB HDD to avoid building on SD.


You use the USB HDD (an SSD most likely?) for the root filesystem?

Quote:
gcc with -j3 probably ran out of RAM. Its written in C++ and C++ can require 1G or more to compile in.
Learn to use /etc/portage/env and /etc/portage/package.env so you don't need to remember.
I've seen over 2G swap used with some things in 64 bit.


Well, at first I had the impression, that the SoC/CPU was getting too hot. Adding the heat sink seemed to improve the situation a bit. The other two causes are a shortage of RAM (I have a 2GB swap partition as a means of precaution) or a poor power supply (I do not trust this crap. I work as a H/W engineer in the space industry and have a vastly different point of view on H/W as the designers of these power plugs seem to have...).

Anyway, I'll go back to compilation on two cores, and that should fix all my issues.

Best regards
Peter
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 39261
Location: 56N 3W

PostPosted: Sun Dec 10, 2017 10:37 pm    Post subject: Reply with quote

christoph_peter_s,

You certainly need a heatsink
You can still run out of RAM even at -j2.

I use -j5 with the exception of
Code:
# *** list things that need -j2 here ***
app-text/libmwaw MAKEOPTS-j2
dev-libs/boost MAKEOPTS-j2
dev-libs/libixion MAKEOPTS-j2
games-emulation/sdlmame MAKEOPTS-j2
media-sound/mumble MAKEOPTS-j2
media-tv/kodi MAKEOPTS-j2
sys-devel/clang MAKEOPTS-j2
sys-devel/gcc MAKEOPTS-j2


# *** list things that need MAKEOPTS-j1 ... maybe ***

app-office/libreoffice  MAKEOPTS-j1
dev-lang/rust MAKEOPTS-j1 nodistcc
dev-java/icedtea MAKEOPTS-j1 nodistcc
net-libs/webkit-gtk MAKEOPTS-j1
sys-devel/binutils MAKEOPTS-j1
sys-devel/llvm MAKEOPTS-j1

dev-qt/qtwebkit MAKEOPTS-j1  nodistcc

_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
christoph_peter_s
n00b
n00b


Joined: 30 Nov 2015
Posts: 39

PostPosted: Sun Dec 10, 2017 11:14 pm    Post subject: Reply with quote

Hi Neddy,

just to understand You right... is this just a formal list, or can one put this to some suitable place, where the system picks the corresponding "-jx"?
I use Gentoo since a few years. Just since the moment Debian switched to Systemd, which wrecked my file server... :-( . I feel pretty comfortable with Gentoo nowadays. For me it is the system, which allows anything I want my machines to do... hm, I do disgress. Gentoo for sure had its learning curve. But in the end really everything I wanted, came out well. I hope Gentoo keeps supplying this service forever. ;-)
But anyway, Thank You for the list! It will be helpful anyway.

Best regards
Peter


Last edited by christoph_peter_s on Sun Dec 10, 2017 11:31 pm; edited 1 time in total
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 39261
Location: 56N 3W

PostPosted: Sun Dec 10, 2017 11:28 pm    Post subject: Reply with quote

christoph_peter_s,

That file is my /etc/portage/package.env file.

MAKEOPTS-j2, MAKEOPTS-j1, nodistcc, are file names in /etc/portage/env/.

/etc/portage/env/MAKEOPTS-j2 contains
Code:
# use this for things that fail at higher parallel makes that -j2
MAKEOPTS="-j2"


It means I can do a @world update and portage manages the environment on a per package basis for me.
The hard bit is trying the different parallel makes until it works.

I have -j5 in make.conf and -j2 and -j1 used on a per packages basis.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
christoph_peter_s
n00b
n00b


Joined: 30 Nov 2015
Posts: 39

PostPosted: Sun Dec 10, 2017 11:30 pm    Post subject: Reply with quote

Thank You for the free extra lessons. :-)
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Gentoo on ARM All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum