hppa1.1-unknown-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I../../.. -I../../../src -O2 -pipe -mschedule=7100LC -march=1.1 -MT port2_1_2.o -MD -MP -MF .deps/port2_1_2.Tpo -c -o port2_1_2.o `test -f 'port2_1_2/port2_1_2.cc' || echo './'`port2_1_2/port2_1_2.cc mv -f .deps/port2_1_0.Tpo .deps/port2_1_0.Po hppa1.1-unknown-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I../../.. -I../../../src -O2 -pipe -mschedule=7100LC -march=1.1 -MT flat-reader.o -MD -MP -MF .deps/flat-reader.Tpo -c -o flat-reader.o `test -f 'cache-utils/flat-reader.cc' || echo './'`cache-utils/flat-reader.cc mv -f .deps/port2_0_0.Tpo .deps/port2_0_0.Po hppa1.1-unknown-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I../../.. -I../../../src -O2 -pipe -mschedule=7100LC -march=1.1 -MT selectors.o -MD -MP -MF .deps/selectors.Tpo -c -o selectors.o `test -f 'cache-utils/selectors.cc' || echo './'`cache-utils/selectors.cc ./cache-utils/unpickle.h: In function 'void uint32_pack(const char*, uint32_t)': ./cache-utils/unpickle.h:62: error: assignment of read-only location ./cache-utils/unpickle.h:63: error: assignment of read-only location ./cache-utils/unpickle.h:64: error: assignment of read-only location ./cache-utils/unpickle.h:65: error: assignment of read-only location ./cache-utils/unpickle.h: In function 'void uint32_unpack(const char*, uint32_t*)': ./cache-utils/unpickle.h:69: error: expected primary-expression before '(' token ./cache-utils/unpickle.h:69: error: expected primary-expression before 'unsigned' ./cache-utils/unpickle.h:70: error: expected primary-expression before '(' token ./cache-utils/unpickle.h:70: error: expected primary-expression before 'unsigned' ./cache-utils/unpickle.h:71: error: expected primary-expression before '(' token ./cache-utils/unpickle.h:71: error: expected primary-expression before 'unsigned' ./cache-utils/unpickle.h:72: error: expected primary-expression before '(' token ./cache-utils/unpickle.h:72: error: expected primary-expression before 'unsigned' make[4]: *** [port2_1_2.o] Error 1 make[4]: *** Waiting for unfinished jobs.... mv -f .deps/selectors.Tpo .deps/selectors.Po mv -f .deps/flat-reader.Tpo .deps/flat-reader.Po make[4]: Leaving directory `/var/tmp/portage/app-portage/eix-0.9.1/work/eix-0.9.1/src/portage/cache' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/var/tmp/portage/app-portage/eix-0.9.1/work/eix-0.9.1/src/portage' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/var/tmp/portage/app-portage/eix-0.9.1/work/eix-0.9.1/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/app-portage/eix-0.9.1/work/eix-0.9.1' make: *** [all] Error 2 !!! ERROR: app-portage/eix-0.9.1 failed. Call stack: ebuild.sh, line 1614: Called dyn_compile ebuild.sh, line 971: Called qa_call 'src_compile' environment, line 1217: Called src_compile eix-0.9.1.ebuild, line 19: Called die !!! emake failed !!! If you need support, post the topmost build error, and the call stack if relevant. !!! A complete build log is located at '/keeps/gentoo/emergelogs/hpvis/app-portage:eix-0.9.1:20070303-141313.log'. emerge --info to follow
Created attachment 111926 [details] emerge --info
Identical compilation failure on 32-bit PPC. Must be big-endian specific. Please rename summary accordingly.
(In reply to comment #2) > Identical compilation failure on 32-bit PPC. > Must be big-endian specific. Could be something entirely different. Why don't you go and attach your `emerge --info` while you are at it? :) > Please rename summary accordingly. Done.
This patch fix the compilation issue. https://www.tuxicoman.be/temp/eix-0.9.1-bigendian.patch However it's not really working yet :) hope eix # update-eix Reading Portage settings .. Received SIGSEGV - you probably found a bug in eix. Please post the output of eix -V along with your bugreport. Sorry for the inconvenience.
Created attachment 112001 [details, diff] Fix for big-endian (scheduled for eix-0.9.2) The attached patch will probably be contained in eix-0.9.2. However, this is certainly not related with the mentioned segfault. For this, I need more information; best starting point would be a backtrace if this is possible on that architecture. From eix instructions: * install gdb (sys-dev/gdb) * compile eix with FEATURES="nostrip" CXXFLAGS="-g -ggdb3" * enter gdb with gdb --args update-eix * type "run" and wait for the segfault to happen * type "bt" to get a backtrace (this helps us a lot)
Recompiling with -O0 -pipe -g -ggdb3 avoid the segfault. This is the output : hope ntp # update-eix Reading Portage settings .. Building database (/var/cache/eix) .. [0] /usr/portage/ (cache: metadata) Reading 100% [1] /usr/local/portage (cache: none) Reading 100% Applying masks .. Database contains 0 packages in 1 categories. That looks plain wrong to me. I'll try again with some more optimization. Portage 2.1.2-r9 (default-linux/hppa/2006.1, gcc-4.1.1, glibc-2.5-r0, 2.6.20.1-hppa parisc)
Created attachment 112304 [details, diff] Patch to test cause for missing categories (In reply to comment #6) > Database contains 0 packages in 1 categories. The reason for this might very well be the same as that for the segfault: update-eix was not able to read/find/store the PORTDIR_CATEGORIES_FILE (and so it could not find any packages within these categories). My impression is that the reason might be a bug in std::unique(), see #146300. What is the output if you apply the attached patch? Is the path printed your actual PORTDIR and is the file profiles/categories in this directory readable by you and contains really the categories?
The patch doesn't help. This is the backtrace with -O1 : (gdb) bt full #0 0x4076a264 in std::ostream::flush () from /usr/lib/gcc/hppa2.0-unknown-linux-gnu/4.1.1/libstdc++.so.6 No symbol table info available. #1 0x40744a88 in std::istream::sentry::sentry () from /usr/lib/gcc/hppa2.0-unknown-linux-gnu/4.1.1/libstdc++.so.6 No symbol table info available. With -O0, it still outputs the same thing.
(In reply to comment #8) > The patch doesn't help. What means "doesn't help"? The point of the second patch was to output additional information to help debugging. I cannot imagine that > With -O0, it still outputs the same thing. even with the patch. The backtrace is useless to me, since it does not show anything related to update-eix: Perhaps you forgot -g -gdb3 or the debugging informations were stripped from the update-eix binary?
Can you please check if this works with 0.9.2?
(In reply to comment #10) > Can you please check if this works with 0.9.2? > 0.9.2 works for ppc
0.9.2 seems to fix the problem. `emerge =eix-0.9.2 && etc-update && update-eix && eix-test-obsolete` runs fine.
