make all-recursive make[1]: Entering directory `/usr/opt/portage/var/tmp/portage/app-portage/eix-0.10.2/work/eix-0.10.2' Making all in src make[2]: Entering directory `/usr/opt/portage/var/tmp/portage/app-portage/eix-0.10.2/work/eix-0.10.2/src' source='update-eix.cc' object='update-eix.o' libtool=no \ DEPDIR=.deps depmode=sgi /bin/sh ../config/depcomp \ CC -DHAVE_CONFIG_H -I. -I.. -I/opt/portage/usr/include -J2 -O2 -n32 -mips4 -r14000 -float_const -use_readonly_const -TARG:isa=mips4:platform=ip35:processor=r14000 -TENV:zeroinit_in_bss=ON -OPT:fast_io=ON:Olimit=8192:reorg_common=ON:swp=ON -LNO:auto_dist=ON:fusion_peeling_limit=8:gather_scatter=2 -FE:eliminate_duplicate_inline_copies:template_in_elf_section -woff 1174,1183,1185,1552,3968,3970 -c -o update-eix.o update-eix.cc cc-1035 CC: WARNING File = /usr/include/stdint.h, Line = 5 #error directive: This header file is to be used only for c99 mode compilations #error This header file is to be used only for c99 mode compilations ^ cc-1064 CC: WARNING File = ./eixTk/argsreader.h, Line = 72 An identifier is missing in the declaration. const union { ///< Pointer to variable of argument. ^ cc-1021 CC: WARNING File = ./eixTk/argsreader.h, Line = 72 The type qualifiers are meaningless in this declaration. const union { ///< Pointer to variable of argument. ^ cc-1265 CC: ERROR File = ./eixTk/argsreader.h, Line = 42 "integer" is not a nonstatic data member or base class of class "Option". : type(t), longopt(l), shortopt(s), integer(i) ^ cc-1265 CC: ERROR File = ./eixTk/argsreader.h, Line = 46 "boolean" is not a nonstatic data member or base class of class "Option". : type(t), longopt(l), shortopt(s), boolean(b) ^ cc-1265 CC: ERROR File = ./eixTk/argsreader.h, Line = 50 "str" is not a nonstatic data member or base class of class "Option". : type(t), longopt(l), shortopt(s), str(c) ^ cc-1020 CC: ERROR File = ./eixTk/argsreader.h, Line = 55 The identifier "pr" is undefined. { pr.first = c1; pr.second = c2; } ^ cc-1265 CC: ERROR File = ./eixTk/argsreader.h, Line = 58 "strlist" is not a nonstatic data member or base class of class "Option". : type(t), longopt(l), shortopt(s), strlist(c) ^ cc-1265 CC: ERROR File = ./eixTk/argsreader.h, Line = 62 "prlist" is not a nonstatic data member or base class of class "Option". : type(t), longopt(l), shortopt(s), prlist(c) ^ cc-1040 CC: ERROR File = ./eixTk/exceptions.h, Line = 58 An identifier is expected. #define ExBasic(...) ExBasic(__FILE__, __LINE__, __PRETTY_FUNCTION__, __VA_ARGS__) ^ cc-1040 CC: ERROR File = ./eixTk/exceptions.h, Line = 60 An identifier is expected. #define ASSERT(x, ...) do { \ ^ cc-1055 CC: ERROR File = ./cachetable.h, Line = 49 A macro invocation has too many arguments. throw(ExBasic("Unknown cache '%s' for directory '%s'!", cache_name.c_str(), directory)); ^ cc-1020 CC: ERROR File = ./cachetable.h, Line = 49 The identifier "__VA_ARGS__" is undefined. throw(ExBasic("Unknown cache '%s' for directory '%s'!", cache_name.c_str(), directory)); ^ cc-1040 CC: ERROR File = update-eix.cc, Line = 35 An identifier is expected. #define INFO(...) printf(__VA_ARGS__) ^ cc-1055 CC: ERROR File = update-eix.cc, Line = 350 A macro invocation has too many arguments. INFO("Reading Portage settings ..\n"); ^ cc-1020 CC: ERROR File = update-eix.cc, Line = 350 The identifier "__VA_ARGS__" is undefined. INFO("Reading Portage settings ..\n"); ^ cc-1055 CC: ERROR File = update-eix.cc, Line = 387 A macro invocation has too many arguments. INFO("Excluded %s\n", portage_settings["PORTDIR"].c_str()); ^ cc-1055 CC: ERROR File = update-eix.cc, Line = 401 A macro invocation has too many arguments. INFO("Excluded %s\n", portage_settings.overlays[i].c_str()); ^ cc-1055 CC: ERROR File = update-eix.cc, Line = 405 A macro invocation has too many arguments. INFO("Building database (%s) ..\n", outputfile.c_str()); ^ cc-1055 CC: ERROR File = update-eix.cc, Line = 429 A macro invocation has too many arguments. INFO(" Reading %%"); ^ cc-1020 CC: ERROR File = update-eix.cc, Line = 429 The identifier "__VA_ARGS__" is undefined. INFO(" Reading %%"); ^ cc-1055 CC: ERROR File = update-eix.cc, Line = 450 A macro invocation has too many arguments. INFO("Excluding \"%s\" %s (cache: %s)\n", overlay.label.c_str(), cache->getPathHumanReadable().c_str(), cache->getType()); ^ cc-1020 CC: ERROR File = update-eix.cc, Line = 450 The identifier "__VA_ARGS__" is undefined. INFO("Excluding \"%s\" %s (cache: %s)\n", overlay.label.c_str(), cache->getPathHumanReadable().c_str(), cache->getType()); ^ cc-1055 CC: ERROR File = update-eix.cc, Line = 458 A macro invocation has too many arguments. INFO("[%u] \"%s\" %s (cache: %s)\n", uint(key), overlay.label.c_str(), cache->getPathHumanReadable().c_str(), cache->getType()); ^ cc-1020 CC: ERROR File = update-eix.cc, Line = 458 The identifier "__VA_ARGS__" is undefined. INFO("[%u] \"%s\" %s (cache: %s)\n", uint(key), overlay.label.c_str(), cache->getPathHumanReadable().c_str(), cache->getType()); ^ cc-1055 CC: ERROR File = update-eix.cc, Line = 459 A macro invocation has too many arguments. INFO(" Reading "); ^ cc-1055 CC: ERROR File = update-eix.cc, Line = 468 A macro invocation has too many arguments. INFO("\b\b\b\baborted\n"); ^ cc-1055 CC: ERROR File = update-eix.cc, Line = 484 A macro invocation has too many arguments. INFO("\b\b\b\baborted\n"); ^ cc-1055 CC: ERROR File = update-eix.cc, Line = 492 A macro invocation has too many arguments. INFO("Applying masks ..\n"); ^ cc-1020 CC: ERROR File = update-eix.cc, Line = 492 The identifier "__VA_ARGS__" is undefined. INFO("Applying masks ..\n"); ^ cc-1055 CC: ERROR File = update-eix.cc, Line = 508 A macro invocation has too many arguments. ASSERT(database_stream, "Can't open the database file %s for writing (mode = 'wb')", outputfile); ^ cc-1055 CC: ERROR File = update-eix.cc, Line = 508 A macro invocation has too many arguments. ASSERT(database_stream, "Can't open the database file %s for writing (mode = 'wb')", outputfile); ^ cc-1055 CC: ERROR File = update-eix.cc, Line = 519 A macro invocation has too many arguments. INFO("Database contains %u packages in %u categories.\n", ^ 30 errors detected in the compilation of "update-eix.cc". make[2]: *** [update-eix.o] Error 2 make[2]: Leaving directory `/usr/opt/portage/var/tmp/portage/app-portage/eix-0.10.2/work/eix-0.10.2/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/opt/portage/var/tmp/portage/app-portage/eix-0.10.2/work/eix-0.10.2' make: *** [all] Error 2 * * ERROR: app-portage/eix-0.10.2 failed. * Call stack: * ebuild.sh, line 46: Called src_compile * environment, line 2528: Called die * The specific snippet of code: * emake || diefunc "$FUNCNAME" "$LINENO" "$?" "emake failed"; * The die message: * emake failed <stdint.h> can't be used in C++ code, and it looks as if <stdarg.h> (or C++ equivalent?) is needed for VA_ARGS.
I changed the unnamed const union to a named non-const union; this should solve the problems in argsreader.h. Unfortunately, cstdint is currently only in tr1; eix uses this now if available and avoids stdint.h if this does not work (but I don't know what to do if neither works and the uint{8,16,32}_t-types are not provided by some other included lib: These types are definitely needed). Moreover, stdarg.h *was* included in exceptions.h; eix uses now cstdarg instead, but I would be surprised if this solves the "..."-problem, and avoiding VA_ARGS would be rather difficult. Anyway: Does new svn trunk of eix compile for you?
I just removed all __VA_ARGS__ macros (revision 532).
Using revision 535, I get the following: eix version 0.10.4 configured successfully. Good luck with make :) cd . && /bin/sh /usr/opt/portage/var/tmp/portage/app-portage/eix-0.10.3a/work/eix-0.10.3a/config/missing --run autoheader rm -f stamp-h1 touch config.h.in cd . && /bin/sh ./config.status config.h config.status: creating config.h config.status: config.h is unchanged make all-recursive make[1]: Entering directory `/usr/opt/portage/var/tmp/portage/app-portage/eix-0.10.3a/work/eix-0.10.3a' Making all in src make[2]: Entering directory `/usr/opt/portage/var/tmp/portage/app-portage/eix-0.10.3a/work/eix-0.10.3a/src' source='update-eix.cc' object='update-eix.o' libtool=no \ DEPDIR=.deps depmode=sgi /bin/sh ../config/depcomp \ CC -DHAVE_CONFIG_H -I. -I.. -I/opt/portage/usr/include -J2 -O2 -n32 -mips4 -r14000 -float_const -use_readonly_const -TARG:isa=mips4:platform=ip35:processor=r14000 -TENV:zeroinit_in_bss=ON -OPT:fast_io=ON:Olimit=8192:reorg_common=ON:swp=ON -LNO:auto_dist=ON:fusion_peeling_limit=8:gather_scatter=2 -diag_error 1035 -FE:eliminate_duplicate_inline_copies:template_in_elf_section -woff 1174,1183,1185,1552,3968,3970 -c -o update-eix.o update-eix.cc cc-1020 CC: ERROR File = ./eixTk/exceptions.h, Line = 36 The identifier "va_list" is undefined. va_list ap; ^ cc-1065 CC: ERROR File = ./eixTk/exceptions.h, Line = 36 A semicolon is expected at this point. va_list ap; ^ cc-1020 CC: ERROR File = ./eixTk/exceptions.h, Line = 37 The identifier "ap" is undefined. va_start(ap, fmt); ^ cc-1021 CC: WARNING File = ./eixTk/ptr_list.h, Line = 45 The type qualifiers are meaningless in this declaration. const typename base_iterator::reference operator->() const ^ detected during instantiation of class "eix::ptr_iterator<std::list<BasicCache *, std::allocator<BasicCache *>>::iterator>" at line 30 of "./cachetable.h" cc-1021 CC: WARNING File = ./eixTk/ptr_list.h, Line = 45 The type qualifiers are meaningless in this declaration. const typename base_iterator::reference operator->() const ^ detected during instantiation of class "eix::ptr_iterator<std::list<Version *, std::allocator<Version *>>::iterator>" at line 151 of "./portage/package.h" cc-1021 CC: WARNING File = ./eixTk/ptr_list.h, Line = 45 The type qualifiers are meaningless in this declaration. const typename base_iterator::reference operator->() const ^ detected during instantiation of class "eix::ptr_iterator<std::list<Category *, std::allocator<Category *>>::iterator>" at line 493 of "update-eix.cc" cc-1021 CC: WARNING File = ./eixTk/ptr_list.h, Line = 45 The type qualifiers are meaningless in this declaration. const typename base_iterator::reference operator->() const ^ detected during instantiation of class "eix::ptr_iterator<std::list<Package *, std::allocator<Package *>>::iterator>" at line 497 of "update-eix.cc" 3 errors detected in the compilation of "update-eix.cc". make[2]: *** [update-eix.o] Error 2 IRIX' stdarg.h header includes the following: /* Define the va_list type: */ __SGI_LIBC_BEGIN_NAMESPACE_STD #ifndef _VA_LIST_ #define _VA_LIST_ typedef char *va_list; #endif /* !_VA_LIST_ */ __SGI_LIBC_END_NAMESPACE_STD ... so I'm not sure why this isn't working...
I'm now hugely confused! If I paste in: #ifndef _VA_LIST_ #define _VA_LIST_ typedef char *va_list; #endif /* !_VA_LIST_ */ ... so src/eixTk/exceptions.h then it still fails in the same way. However, if I remove the guards and just add: typedef char *va_list; ... then it gets much further! It now fails (sigh) with: source='eixTk/sysutils.cc' object='eixTk/sysutils.o' libtool=no \ DEPDIR=.deps depmode=sgi /bin/sh ../config/depcomp \ CC -DHAVE_CONFIG_H -I. -I.. -I/opt/portage/usr/include -O2 -n32 -mips4 -r14000 -float_const -use_readonly_const -TARG:isa=mips4:platform=ip35:processor=r14000 -TENV:zeroinit_in_bss=ON -OPT:fast_io=ON:Olimit=8192:reorg_common=ON:swp=ON -LNO:auto_dist=ON:fusion_peeling_limit=8:gather_scatter=2 -diag_error 1035 -FE:eliminate_duplicate_inline_copies:template_in_elf_section -woff 1174,1183,1185,1552,3968,3970 -c -o eixTk/sysutils.o eixTk/sysutils.cc cc-1020 CC: ERROR File = eixTk/sysutils.cc, Line = 105 The identifier "LC_ALL" is undefined. string old_lcall = setlocale(LC_ALL, NULL); ^ cc-1020 CC: ERROR File = eixTk/sysutils.cc, Line = 105 The identifier "setlocale" is undefined. string old_lcall = setlocale(LC_ALL, NULL); ^ 2 errors detected in the compilation of "eixTk/sysutils.cc". make[2]: *** [eixTk/sysutils.o] Error 2 make[2]: Leaving directory `/usr/opt/portage/var/tmp/portage/app-portage/eix-0.10.4/work/eix-0.10.4/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/opt/portage/var/tmp/portage/app-portage/eix-0.10.4/work/eix-0.10.4' make: *** [all] Error 2 ... this was fixed by adding "#include <locale.h>" to src/eixTk/sysutils.cc. The next errors are: "cache/generate-cachemap.sh" > "cache/cache-map.cc" source='cache/cache-map.cc' object='cache/cache-map.o' libtool=no \ DEPDIR=.deps depmode=sgi /bin/sh ../config/depcomp \ CC -DHAVE_CONFIG_H -I. -I.. -I/opt/portage/usr/include -O2 -n32 -mips4 -r14000 -float_const -use_readonly_const -TARG:isa=mips4:platform=ip35:processor=r14000 -TENV:zeroinit_in_bss=ON -OPT:fast_io=ON:Olimit=8192:reorg_common=ON:swp=ON -LNO:auto_dist=ON:fusion_peeling_limit=8:gather_scatter=2 -diag_error 1035 -FE:eliminate_duplicate_inline_copies:template_in_elf_section -woff 1174,1183,1185,1552,3968,3970 -c -o cache/cache-map.o cache/cache-map.cc cc-1007 CC: ERROR File = cache/cache-map.cc, Line = 15 The indicated token is not valid in this context. return new $(to_classname metadata); ^ cc-1079 CC: ERROR File = cache/cache-map.cc, Line = 15 A type specifier is expected. return new $(to_classname metadata); ^ cc-1007 CC: ERROR File = cache/cache-map.cc, Line = 18 The indicated token is not valid in this context. return new $(to_classname sqlite); ^ cc-1079 CC: ERROR File = cache/cache-map.cc, Line = 18 A type specifier is expected. return new $(to_classname sqlite); ^ cc-1007 CC: ERROR File = cache/cache-map.cc, Line = 21 The indicated token is not valid in this context. return new $(to_classname cdb); ^ cc-1079 CC: ERROR File = cache/cache-map.cc, Line = 21 A type specifier is expected. return new $(to_classname cdb); ^ cc-1007 CC: ERROR File = cache/cache-map.cc, Line = 24 The indicated token is not valid in this context. return new $(to_classname none); ^ cc-1079 CC: ERROR File = cache/cache-map.cc, Line = 24 A type specifier is expected. return new $(to_classname none); ^ cc-1007 CC: ERROR File = cache/cache-map.cc, Line = 27 The indicated token is not valid in this context. return new $(to_classname ebuild); ^ cc-1079 CC: ERROR File = cache/cache-map.cc, Line = 27 A type specifier is expected. return new $(to_classname ebuild); ^ cc-1007 CC: ERROR File = cache/cache-map.cc, Line = 30 The indicated token is not valid in this context. return new $(to_classname portage-2.0); ^ cc-1079 CC: ERROR File = cache/cache-map.cc, Line = 30 A type specifier is expected. return new $(to_classname portage-2.0); ^ cc-1007 CC: ERROR File = cache/cache-map.cc, Line = 33 The indicated token is not valid in this context. return new $(to_classname portage-2.0.51); ^ cc-1079 CC: ERROR File = cache/cache-map.cc, Line = 33 A type specifier is expected. return new $(to_classname portage-2.0.51); ^ cc-1007 CC: ERROR File = cache/cache-map.cc, Line = 36 The indicated token is not valid in this context. return new $(to_classname flat); ^ cc-1079 CC: ERROR File = cache/cache-map.cc, Line = 36 A type specifier is expected. return new $(to_classname flat); ^ cc-1007 CC: ERROR File = cache/cache-map.cc, Line = 39 The indicated token is not valid in this context. return new $(to_classname portage-2.1); ^ cc-1079 CC: ERROR File = cache/cache-map.cc, Line = 39 A type specifier is expected. return new $(to_classname portage-2.1); ^ cc-1007 CC: ERROR File = cache/cache-map.cc, Line = 42 The indicated token is not valid in this context. return new $(to_classname portage-2.1.0); ^ cc-1079 CC: ERROR File = cache/cache-map.cc, Line = 42 A type specifier is expected. return new $(to_classname portage-2.1.0); ^ cc-1007 CC: ERROR File = cache/cache-map.cc, Line = 45 The indicated token is not valid in this context. return new $(to_classname backport); ^ cc-1079 CC: ERROR File = cache/cache-map.cc, Line = 45 A type specifier is expected. return new $(to_classname backport); ^ cc-1007 CC: ERROR File = cache/cache-map.cc, Line = 48 The indicated token is not valid in this context. return new $(to_classname portage-2.1.2); ^ cc-1079 CC: ERROR File = cache/cache-map.cc, Line = 48 A type specifier is expected. return new $(to_classname portage-2.1.2); ^ cc-1007 CC: ERROR File = cache/cache-map.cc, Line = 51 The indicated token is not valid in this context. return new $(to_classname portage-2.1*); ^ cc-1079 CC: ERROR File = cache/cache-map.cc, Line = 51 A type specifier is expected. return new $(to_classname portage-2.1*); ^ cc-1007 CC: ERROR File = cache/cache-map.cc, Line = 54 The indicated token is not valid in this context. return new $(to_classname none)(true); ^ cc-1079 CC: ERROR File = cache/cache-map.cc, Line = 54 A type specifier is expected. return new $(to_classname none)(true); ^ cc-1007 CC: ERROR File = cache/cache-map.cc, Line = 57 The indicated token is not valid in this context. return new $(to_classname ebuild)(true); ^ cc-1079 CC: ERROR File = cache/cache-map.cc, Line = 57 A type specifier is expected. return new $(to_classname ebuild)(true); ^ 30 errors detected in the compilation of "cache/cache-map.cc". make[2]: *** [cache/cache-map.o] Error 2 make[2]: Leaving directory `/usr/opt/portage/var/tmp/portage/app-portage/eix-0.10.4/work/eix-0.10.4/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/opt/portage/var/tmp/portage/app-portage/eix-0.10.4/work/eix-0.10.4' make: *** [all] Error 2 ... and this I have no idea about! But it feels as if we're getting closer ;)
Looks like your standard shell doesn't handle $() syntax. I've changed the script in question, please retry with current revision (536).
It might be the fault of libtool, but /bin/CC also seems to be hardcoded into the build-process somewhere. Ideally, all tools should be the prefix-portage ones (e.g. ${EPREFIX}/bin/CC). (This only seems to happen for the "C++ prelinker" stage - ${EPREFIX}/usr/bin/CC is used to compile the code - odd) The good news is that eix-0.10.4 now builds on IRIX! Unfortunately, the test-suite fails with: >>> Test phase [check]: app-portage/eix-0.10.4 Making check in src make[1]: Entering directory `/usr/opt/portage/var/tmp/portage/app-portage/eix-0.10.4/work/eix-0.10.4/src' /bin/sh ../libtool --tag=CXX --mode=link CC -J2 -O2 -n32 -mips4 -r14000 -float_const -use_readonly_const -TARG:isa=mips4:platform=ip35:processor=r14000 -TENV:zeroinit_in_bss=ON -OPT:fast_io=ON:Olimit=8192:reorg_common=ON:swp=ON -LNO:auto_dist=ON:fusion_peeling_limit=8:gather_scatter=2 -diag_error 1035 -FE:eliminate_duplicate_inline_copies:template_in_elf_section -woff 1174,1183,1185,1552,3968,3970 -Wl,-v,-s,-x,-n32,-mips4,-rdata_shared,-allow_jump_at_eop,-rpath,/opt/portage/usr/lib:/opt/portage/lib -L/opt/portage/usr/lib -L/opt/portage/lib -Wl,--as-needed -o update-eix update-eix.o varsreader.o database/io.o database/header.o database/package_reader.o portage/conf/portagesettings.o portage/conf/cascadingprofile.o portage/basicversion.o portage/mask.o portage/package.o portage/vardbpkg.o portage/packagetree.o portage/keywords.o portage/set_stability.o eixTk/argsreader.o eixTk/filenames.o eixTk/stringutils.o eixTk/sysutils.o eixTk/utils.o eixrc/eixrc.o global.o global2.o global3.o global4.o cache/common/flat-reader.o cache/common/selectors.o cache/common/unpickle.o cache/base.o cache/cache-map.o cache/cdb/cdb.o cache/ebuild/ebuild.o cache/eixcache/eixcache.o cache/metadata/metadata.o cache/none/none.o cache/port2_0_0/port2_0_0.o cache/port2_1_0/port2_1_0.o cache/port2_1_2/port2_1_2.o cache/sqlite/sqlite.o -lbz2 CC -J2 -O2 -n32 -mips4 -r14000 -float_const -use_readonly_const -TARG:isa=mips4:platform=ip35:processor=r14000 -TENV:zeroinit_in_bss=ON -OPT:fast_io=ON:Olimit=8192:reorg_common=ON:swp=ON -LNO:auto_dist=ON:fusion_peeling_limit=8:gather_scatter=2 -diag_error 1035 -FE:eliminate_duplicate_inline_copies:template_in_elf_section -woff 1174,1183,1185,1552,3968,3970 -Wl,-v -Wl,-s -Wl,-x -Wl,-n32 -Wl,-mips4 -Wl,-rdata_shared -Wl,-allow_jump_at_eop -Wl,-rpath -Wl,/opt/portage/usr/lib:/opt/portage/lib -Wl,--as-needed -o update-eix update-eix.o varsreader.o database/io.o database/header.o database/package_reader.o portage/conf/portagesettings.o portage/conf/cascadingprofile.o portage/basicversion.o portage/mask.o portage/package.o portage/vardbpkg.o portage/packagetree.o portage/keywords.o portage/set_stability.o eixTk/argsreader.o eixTk/filenames.o eixTk/stringutils.o eixTk/sysutils.o eixTk/utils.o eixrc/eixrc.o global.o global2.o global3.o global4.o cache/common/flat-reader.o cache/common/selectors.o cache/common/unpickle.o cache/base.o cache/cache-map.o cache/cdb/cdb.o cache/ebuild/ebuild.o cache/eixcache/eixcache.o cache/metadata/metadata.o cache/none/none.o cache/port2_0_0/port2_0_0.o cache/port2_1_0/port2_1_0.o cache/port2_1_2/port2_1_2.o cache/sqlite/sqlite.o -L/opt/portage/usr/lib -L/opt/portage/lib -lbz2 C++ prelinker: error: std::_List_base<Category*,std::allocator<Category*> >::clear(void) assigned to database/io.o and update-eix.o C++ prelinker: error: bad instantiation request file -- instantiation assigned to more than one file make[1]: *** [update-eix] Error 2 make[1]: Leaving directory `/usr/opt/portage/var/tmp/portage/app-portage/eix-0.10.4/work/eix-0.10.4/src' make: *** [check-recursive] Error 1 * Make check failed. See above for details. (Oh, and "-Wl,--as-needed" is also GNU-specific) ... as does 'ebuild merge': C++ prelinker: error: std::_List_base<Category*,std::allocator<Category*> >::clear(void) assigned to database/io.o and update-eix.o C++ prelinker: error: bad instantiation request file -- instantiation assigned to more than one file make[1]: *** [update-eix] Error 2 make[1]: Leaving directory `/usr/opt/portage/var/tmp/portage/app-portage/eix-0.10.4/work/eix-0.10.4/src' make: *** [install-recursive] Error 1 * ERROR: app-portage/eix-0.10.4 failed: * emake install failed * * Call stack: * ebuild.sh: 49: <call src_install> * environment:2066: emake DESTDIR="${D}" install || die "emake install failed"; *
(oh, and I'm still having to manually add the va_list typedef)
(In reply to comment #7) > (oh, and I'm still having to manually add the va_list typedef) This should be fixed now. > (Oh, and "-Wl,--as-needed" is also GNU-specific) configure tests whether the compiler knows it. Is something wrong with the test? > It might be the fault of libtool, but /bin/CC also seems to be hardcoded > into the build-process somewhere No idea about that one. But if the following is not related to using the wrong linker, the following is severe: > C++ prelinker: error: bad instantiation request file -- > instantiation assigned to more than one file If the IRIX linker is not smart enough (or has no option to make it smart enough) to treat template instatiations automatically, I am afraid that eix (as most other C++ programs) will never work on IRIX...
(In reply to comment #8) > If the IRIX linker is not smart enough (or has no option to make it smart > enough) to treat template instatiations automatically If I understand Sect. "Automatic Instantiation Method" of (remove linebreak): http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=0650&db=bks& fname=/SGI_Developer/CC_PG/ch04.html correctly, the compiler/linker should do this automatically. Maybe the error is caused by some obsolete *.ii files (since these are IRIX specific, "make clean" will probably not erase them, and if I understand correctly, they can be out of date after certain code changes).
(Apologies - I was replying to this last night, and my laptop crashed) The as-needed test is a false-positive: the linker noisily drops the option but does compile, so configure thinks that it has been accepted. This is purely a cosmetic problem unless the lack of an as-needed option triggers an alternative. /bin/CC is ultimately the correct binary to invoke - but in order to inject the correct library and include paths and options, etc., for prefix usage I've created a ${EPREFIX}/usr/bin/CC (etc.) wrapper - and so this really should be the thing being used rather than anything outside of $EPREFIX. However, I have also removed all trace of this, and compilation fails identically with non-wrapped binaries. I'll try using fewer/more $CXXFLAGS, and see if -ptv gives anything useful to try to work out why the automatic instantiation isn't working...
It's fixed! Adding '-ptused' to my $CXXFLAGS allowed eix to compile and install successfully :) (I guess this could be performed in the ebuild with something like 'case ${CHOST} in *-irix*) append-flags -ptused;; esac' - but I'm not sure how CC alone should be altered, by modifying CXXFLAGS directly?) For reference, the remaining warnings during the build - some of which are most likely spurious are: cc-3604 CC: WARNING File = eixTk/argsreader.cc, Line = 136 missing return statement at end of non-void function "ArgumentReader::lookup_longopt" } ^ cc-3604 CC: WARNING File = eixTk/argsreader.cc, Line = 152 missing return statement at end of non-void function "ArgumentReader::lookup_shortopt" } ^ cc-1234 CC: WARNING File = ./output/formatstring.h, Line = 129 Access control is not specified ("private" by default). class MarkedList : std::multimap<std::string, BasicVersion*> ^ ... and the aforementioned: (null): WARNING 1 : Unknown option: -as-needed (ignored). ... from ld. Thanks for all the effort in getting this working!
... although, having said all that, running it results in: $ eix-sync -v /opt/portage/usr/bin/eix-sync[12]: syntax error at line 678 : `((' unexpected ... which is again due to using the system 'sh' rather than the portage 'sh' or 'bash'. I'd imagine that eix should have a run-time dependency on bash, and then the interpreter line should be '#!/bin/env bash'. ('sh' would be better but, by default, the bash ebuild doesn't provide a 'sh' symlink). Correcting that, I get the message about using '-e' for prefix - shouldn't this config file be installed by default? Finally, this eix was built with USE="-sqlite" (because I'm still working on getting sqlite to build), and the output from eix is: $ eix-sync -v * eix-cache doesn't exist. Running update-eix! Reading Portage settings .. Garbage at end of version string: .1 Building database (/opt/portage/var/cache/eix) .. [0] "gentoo_prefix" /usr/opt/portage/portage/ (cache: metadata) Reading 100% Applying masks .. Database contains 0 packages in 151 categories. * Removing old portage-cache in /opt/portage/var/cache/edb/dep * Running emerge --sync >>> Starting svn update... At revision 17040. real 0m33.118s user 0m3.439s sys 0m2.581s * Copying old /opt/portage/var/cache/eix cache to /opt/portage/var/cache/eix.previous * Running update-eix Reading Portage settings .. Garbage at end of version string: .1 Building database (/opt/portage/var/cache/eix) .. [0] "gentoo_prefix" /usr/opt/portage/portage/ (cache: metadata) Reading 100% Applying masks .. Database contains 0 packages in 151 categories. Garbage at end of version string: .1 Diffing databases (0 - 0 packages) $ eix -S bash Garbage at end of version string: .1 No matches found. So there seems to be some problem here - why does the database contain no packages?
(In reply to comment #12)'> $ eix-sync -v > /opt/portage/usr/bin/eix-sync[12]: syntax error at line 678 : `((' > > ... which is again due to using the system 'sh' rather than the portage 'sh' > or 'bash'. I'd imagine that eix should have a run-time dependency on bash, > and then the interpreter line should be '#!/bin/env bash'. No. This was just intentionally changed (and I rewrote large parts of the scripts) to finally get rid of the dependency on this unlucky bash choice. It is better to make the scripts standard conformal. However, since dash has no problems with the scripts, I cannot test why this does not work. I appreciate if you could find out: Obviously the problem is lines 254-256 of update-eix-functions.sh (which is the only place where `((' occurs at all): [ "$(( 0 + 1 ))" = 1 ] && \ expr() { echo "$(( ${1} ${2} ${3} ))" } i.e. an explicit test whether $((...)) works as expected and - if it does - to override the external expr with an internal function; actually expr is called only once in eix-sync (first with COUNT=0): COUNT="`expr ${COUNT} + 1`" I really cannot imagine what might be nonstandard with the above code. The only idea which I have is that perhaps echo "$(( 1 + 0 ))" already leads to an error message in your sh. If this is the case, does replacing line 254 of update-eix-function.sh with ( eval '[ "$(( 1 + 0 ))" = 1 ]' ) >/dev/null 2>&1 && \ solve the problem? > [0] "gentoo_prefix" /usr/opt/portage/portage/ (cache: metadata) So update-eix expects the metadata from /usr/opt/portage/portage/metadata/cache/* Do you actually have this data there? (If just the prefix of the path is wrong, I refer to the discussion of bug 167961. However, if you do not have */metadata/cache/* at all, you must unfortunately use a different cache method. Probably CACHE_METHOD=portage-2.1 is the next method to try if prefix portage builds a corresponding /var/cache/edb/dep/usr/opt/portage/portage/* [you might have to adjust the path or prefix...]).
IRIX /bin/sh is just too old to parse anything of the form of '$(( 1 + 1 ))', whether as an argument of test or passed to echo. (Infact I believe that /bin/sh is (near-)identical to ksh.) I accidentally had '${EPREFIX}/usr/portage' as a symlink to '${EPREFIX}/portage', which I've now corrected. 'eix-sync' says: Building database (/opt/portage/var/cache/eix) .. [0] "gentoo_prefix" /usr/opt/portage/usr/portage/ (cache: metadata) Reading 100% Applying masks .. Database contains 0 packages in 151 categories. Diffing databases (0 - 0 packages) ... and ${EPREFIX}/var/cache/edb/dep/usr/opt/portage/usr/portage does exist, but contains only sys-apps/portage/*. ${EPREFIX}/usr/portage/metadata/ also exists, but contains only timestamp.chk I assume that portage itself should be generating these files, and so this appears to be a portage bug?
Time to kick in. (In reply to comment #13) > (In reply to comment #12)'> $ eix-sync -v > > /opt/portage/usr/bin/eix-sync[12]: syntax error at line 678 : `((' > > > > ... which is again due to using the system 'sh' rather than the portage 'sh' > or 'bash'. I'd imagine that eix should have a run-time dependency on bash, > and then the interpreter line should be '#!/bin/env bash'. > > No. This was just intentionally changed (and I rewrote large parts of the > scripts) to finally get rid of the dependency on this unlucky bash choice. > It is better to make the scripts standard conformal. However, since dash has no > problems with the scripts, I cannot test why this does not work. I appreciate > if you could find out: This is really sad to hear. Please DO use /usr/bin/env to find your shell. Your assumption that /bin/sh is dash (or any other posix shell) is not true on most systems. If you use /bin/sh, you should write bourne shell compatible stuff, which is roughly the stuff which configure uses. You really don't want that, so just refer to a posix shell, or if your world vision is too small, then just rely on the path to find a shell (sh) that matches your expectations. That way Prefix just provides bash and it will all work fine. For prefix this is a severe bug, and we will have to patch this to make it use prefix /bin/sh/bash again.
(In reply to comment #14) > IRIX /bin/sh is just too old to parse anything of the form of > '$(( 1 + 1 ))', whether as an argument of test or passed to echo. For my shell code, it doesn't matter whether the shell does parse this or not - if it does not parse it, my code will not define the function expr, i.e. the external expr is used. I just do not understand why my code does not work (BTW: with ksh in portage, even $((...)) works). What happens if you call "echo "$(( 1 + 1 ))"? I would have expected that it prints then something like "$(( 1 + 1 ))" or something else but not die. (The problem is that I cannot understand why my code *dies*). I checked in a new version, where the test is made in a subshell, maybe this works for you... > ... and ${EPREFIX}/var/cache/edb/dep/usr/opt/portage/usr/portage does exist, > but contains only sys-apps/portage/*. ${EPREFIX}/usr/portage/metadata/ also > exists, but contains only timestamp.chk > > I assume that portage itself should be generating these files, and so this > appears to be a portage bug? From your description, it appears to me that emerge --metadata gets its information (for /var/cache/edb/dep/...) from the metadata subdirectory and your overlays. Since the metadata subdirectory does not exist in your portage tree, this is not a bug in portage. Instead, it is a "bug" (or better say: "missing feature") of your portage tree that the metadata subdirectory is empty. I do not know how this subdirectory is created for the "standard" portage tree. Maybe with emerge --regen? Unfortunately, this takes a *lot* of time. If you cannot "load" the metadata from the tree, I am afraid that you have to use either this emerge --regen or some of the other cache methods "ebuild*" (or even "ebuild") or "none". Unfortunately, all of these are *very* slow. "none" is the fastest of these, but still rather slow, and for packages relying on eclasses some information will be missing or wrong.
(In reply to comment #15) > Your assumption that /bin/sh is dash (or any other posix shell) is not true > on most systems. If you use /bin/sh, you should write bourne shell > compatible stuff, which is roughly the stuff which configure uses. The scripts are supposed to be bourne shell compatible - that's why I made the last uses of $((...)) optional and $(...) obsolete. I really do not understand what could be bourne shell incompatible at the mentioned code. Unfortunately, it is hard to test without the corresponding bourne shell. > then just rely on the path to find a shell (sh) that matches your > expectations. "/usr/bin/env sh" is fine for me - I just do not want to hardcode "bash". So as you say that this will work, I will check in this change.
If there are no more objections from this bug, I will release the new tarball today or tomorrow.
> > I assume that portage itself should be generating these files, and so this > > appears to be a portage bug? > > From your description, it appears to me that emerge --metadata gets its > information (for /var/cache/edb/dep/...) from the metadata subdirectory and > your overlays. Since the metadata subdirectory does not exist in your portage > tree, this is not a bug in portage. Instead, it is a "bug" (or better say: > "missing feature") of your portage tree that the metadata subdirectory is > empty. I do not know how this subdirectory is created for the "standard" > portage tree. Maybe with emerge --regen? Unfortunately, this takes a *lot* of > time. In prefix we cannot generate this meta-data as long as we use SVN for our tree. Since SVN doesn't (re)store creation/modification time, there is no way in which Portage can see if the metadata cache is more recent than the ebuilds. Once once we get an rsync tree, we can run cachegen.py and also add more stuff like GLSAs and alike. Untill then we're stuck with Portage's own metadata caching, which isn't necessarily for the full tree. > If you cannot "load" the metadata from the tree, I am afraid that you have to > use either this emerge --regen or some of the other cache methods "ebuild*" (or > even "ebuild") or "none". Unfortunately, all of these are *very* slow. > "none" is the fastest of these, but still rather slow, and for packages relying > on eclasses some information will be missing or wrong. Unfortunately this is the case.
I've used 'emerge --regen' and even after this eix finds no metadata. Is this to be expected, a portage bug, a eix bug, or just a result of using prefix portage via SVN (and would the developers' HTTPS option help)? (Immediately after 'emerge --regen', ${EPREFIX}/usr/portage/metadata/cache is empty but ${EPREFIX}/var/cache/edb/dep/${EPREFIX}/usr/portage/ has entries for 2670 packages in 92 categories. Still 'update-eix' returns: Reading Portage settings .. Garbage at end of version string: .1 Building database (/opt/portage/var/cache/eix) .. [0] "gentoo_prefix" /usr/opt/portage/usr/portage/ (cache: metadata) Reading 100% Applying masks .. Database contains 0 packages in 151 categories. )
Additional quick note: 'emerge --metadata' also makes no difference. However, my Mac is happily running prefix-portage via SVN, and on this eix works without any problems - so I'm again tending towards thinking that this must be a bug somewhere in portage or eix. (Having said this, the different caching methods of portage are a mystery to me, so I could well be barking up completely the wrong tree...)
To to be sure, did you run update-eix? On a system where I never used eix before I got: (pegasus:portage/app-portage/eix) fabian% eix -I eix Garbage at end of version string: .1 Can't open the database file /ufs/fabian/scratch/programs/gentoo/var/cache/eix for reading (mode = 'rb') Did you forget to create it with 'update-eix'? (pegasus:portage/app-portage/eix) fabian% update-eix Reading Portage settings .. Garbage at end of version string: .1 Building database (/ufs/fabian/scratch/programs/gentoo/var/cache/eix) .. [0] "gentoo_prefix" /net/pegasus.ins.cwi.nl/export/scratch0/fabian/programs/gentoo-prefix/grobian/prefix-tree/ (cache: none) Reading 0%Garbage at end of version string: .01 Garbage at end of version string: .01 13%Garbage at end of version string: .2 Garbage at end of version string: .2 21%Garbage at end of version string: .1 Garbage at end of version string: .2 21%Garbage at end of version string: .2 22%Garbage at end of version string: .01 Garbage at end of version string: .1 30%Garbage at end of version string: .1 45%Garbage at end of version string: .1 80%Garbage at end of version string: .1 Garbage at end of version string: .1 83%Garbage at end of version string: .1 Garbage at end of version string: .1 Garbage at end of version string: .4 Garbage at end of version string: .2 Garbage at end of version string: .1 86%Garbage at end of version string: .2 Garbage at end of version string: .1 94%Garbage at end of version string: .1 Garbage at end of version string: .1 100% [1] "gnustep-prefix" /net/pegasus.ins.cwi.nl/export/scratch0/fabian/programs/gentoo-prefix/grobian/prefix-tree/local/gnustep/prefix-overlay (cache: none) Reading 100% Applying masks .. Database contains 1700 packages in 151 categories. (pegasus:portage/app-portage/eix) fabian% eix -I eix Garbage at end of version string: .1 Garbage at end of version string: .2 [I] app-portage/eix Available versions: (~)0.9.9 (~)0.9.10 (~)0.10.3 {sqlite} Installed versions: 0.10.3(10:51:25 03/01/08)(-sqlite) Homepage: http://eix.sourceforge.net Description: Small utility for searching ebuilds with indexing for fast results (pegasus:portage/app-portage/eix) fabian% The warnings stuff is because eix doesn't deal with inter-revisions, but it seems to function to a certain extent after update-eix for me.
Please try to run update-eix with the portage-2.1 cache method enabled. # PORTDIR_CACHE_METHOD=portage-2.1 update-eix
Interestingly that method sees only 700 packages less (!!!): (pegasus:portage/app-portage/eix) fabian% env PORTDIR_CACHE_METHOD=portage-2.1 update-eix Reading Portage settings .. Garbage at end of version string: .1 Building database (/ufs/fabian/scratch/programs/gentoo/var/cache/eix) .. [0] "" /net/pegasus.ins.cwi.nl/export/scratch0/fabian/programs/gentoo-prefix/grobian/prefix-tree/ in /ufs/fabian/scratch/programs/gentoo (cache: portage-2.1) Reading 0%Garbage at end of version string: .01 Garbage at end of version string: .01 1%Garbage at end of version string: .2 10%Garbage at end of version string: .1 Garbage at end of version string: .2 13%Garbage at end of version string: .01 Garbage at end of version string: .1 Garbage at end of version string: .2 Garbage at end of version string: .1 Garbage at end of version string: .2 13%Garbage at end of version string: .1 21%Garbage at end of version string: .1 Garbage at end of version string: .1 Garbage at end of version string: .2 21%Garbage at end of version string: .2 Garbage at end of version string: .1 Garbage at end of version string: .2 Garbage at end of version string: .01 22%Garbage at end of version string: .1 30%Garbage at end of version string: .1 31%Garbage at end of version string: .1 45%Garbage at end of version string: .1 80%Garbage at end of version string: .1 Garbage at end of version string: .1 83%Garbage at end of version string: .1 Garbage at end of version string: .1 Garbage at end of version string: .1 Garbage at end of version string: .2 Garbage at end of version string: .3 Garbage at end of version string: .4 Garbage at end of version string: .2 Garbage at end of version string: .1 86%Garbage at end of version string: .2 Garbage at end of version string: .1 Garbage at end of version string: .1 94%Garbage at end of version string: .1 Garbage at end of version string: .1 100% [1] "gnustep-prefix" /net/pegasus.ins.cwi.nl/export/scratch0/fabian/programs/gentoo-prefix/grobian/prefix-tree/local/gnustep/prefix-overlay (cache: none) Reading 100% Applying masks .. Database contains 1003 packages in 151 categories.
$ PORTDIR_CACHE_METHOD=portage-2.1 update-eix Reading Portage settings .. Garbage at end of version string: .1 Building database (/opt/portage/var/cache/eix) .. [0] "" /usr/opt/portage/usr/portage/ in /opt/portage (cache: portage-2.1) Reading 0%Garbage at end of version string: .01 Garbage at end of version string: .01 13%Garbage at end of version string: .2 Garbage at end of version string: .2 21%Garbage at end of version string: .1 Garbage at end of version string: .2 21%Garbage at end of version string: .2 22%Garbage at end of version string: .01 Garbage at end of version string: .1 30%Garbage at end of version string: .1 45%Garbage at end of version string: .1 80%Garbage at end of version string: .1 Garbage at end of version string: .1 83%Garbage at end of version string: .1 Garbage at end of version string: .1 Garbage at end of version string: .4 Garbage at end of version string: .2 Garbage at end of version string: .1 86%Garbage at end of version string: .2 Garbage at end of version string: .1 94%Garbage at end of version string: .1 Garbage at end of version string: .1 100% Applying masks .. Database contains 1638 packages in 151 categories. ... so this works! Is there a config option for ${EPREFIX}/etc/eix*.conf that will make this the default? Is there any other way other than an alias (or environment variable) that will keep this working - and is it a good idea to permanently force this?
... however, this doesn't work with 'eix-sync' :( $ PORTDIR_CACHE_METHOD="portage-2.1" eix-sync -v * Removing old portage-cache in /opt/portage/var/cache/edb/dep * Running emerge --sync >>> Starting svn update... U app-portage/eix/eix-0.10.3.ebuild G app-portage/eix/Manifest Updated to revision 17130. real 0m58.396s user 0m4.039s sys 0m5.370s * Copying old /opt/portage/var/cache/eix cache to /opt/portage/var/cache/eix.previous * Running update-eix Reading Portage settings .. Garbage at end of version string: .1 Building database (/opt/portage/var/cache/eix) .. [0] "" /usr/opt/portage/usr/portage/ in /opt/portage (cache: portage-2.1) Reading 100% Applying masks .. Database contains 1 packages in 151 categories. Garbage at end of version string: .1 Diffing databases (1638 - 1 packages) << app-admin/apache-tools (~*2.2.6 ~*2.2.8): Useful Apache tools - htdigest, htpasswd, ab, htdbm ... << xfce-extra/xfwm4-themes (~*4.4.2): Window manager themes ... and this is the result when PORTDIR_CACHE_METHOD (is this actually a portage variable which can live in ${EPREFIX}/etc/make.conf, or something unique to eix?) is exported or merely passed on the command-line. If I then run update-eix in the same way, I get only: Reading Portage settings .. Garbage at end of version string: .1 Building database (/opt/portage/var/cache/eix) .. [0] "" /usr/opt/portage/usr/portage/ in /opt/portage (cache: portage-2.1) Reading 100% Applying masks .. Database contains 1 packages in 151 categories. ... and the same after an 'emerge --metadata'. Infact, the only time this works is after a (very slow) 'emerge --regen' - can anyone else confirm?
(In reply to comment #26) > ... however, this doesn't work with 'eix-sync' :( > * Copying old /opt/portage/var/cache/eix cache to > /opt/portage/var/cache/eix.previous These paths look ok > * Running update-eix > Reading Portage settings .. > Garbage at end of version string: .1 > Building database (/opt/portage/var/cache/eix) .. > [0] "" /usr/opt/portage/usr/portage/ in /opt/portage (cache: portage-2.1) > Reading 100% But this doesn't. Why /usr/opt? So you have a symlink opt -> usr/opt or something? Also, it doesn't find the repo_name file aparently, because it uses an empty string...
(In reply to comment #26) > * Removing old portage-cache in /opt/portage/var/cache/edb/dep So here is the old cache removed. And it is never recreated properly, because emerge --sync does not fetch any metadata. > Infact, the only time this works is after a (very slow) 'emerge --regen' Yes, this was to be expected: Since nothing fetches the full metadata, it has either to be created by portage or by update-eix (with one of the slow cache methods). There is no way around: Somebody has to do the work. Maybe emerge --regen will run faster if /opt/portage/var/cache/edb/dep is not cleaned (use option -R for eix-sync). PORTDIR_CACHE_METHOD is a special variable only for eix. You can set its default in ${EPREFIX}/etc/eixrc
Yeah - because the root partition is only 128Mb, /opt is a symlink to /usr/opt. prefix stuff seems to like the absolute directory rather than the symlink - which is a shame because it's a little less obvious, but in the scheme of things, no great shakes. Sorry if I'm being really slow or dense here - but what I still don't understand, as I've mentioned before, is how my Mac can be syncing from the same prefix SVN repository under the same conditions using the same software - and yet eix just works. There's no need to run 'emerge --regen', the caches are populated form the word go. How is it, if there's no bug involved, that exactly the same software syncing from the same place but on a different architecture suddenly has no metadata, and has to slowly rebuild it on every sync? /me is confused...
What cache method is used by your update-eix on the mac? [0] "something" /this/that in /this/that (cache: IMPORTANT PART)
Should be none as the ebuild sets the default to none via a configure argument, but indeed, please check. On Linux it is/was.
Yeah, on the Mac it says: [0] /opt/gentoo/usr/portage/ (cache: none) ... then finds 1638 packages in 151 categories (which tallies with IRIX after 'emerge --regen')
... and in fact, if PORTDIR_CACHE_METHOD is set to "none" on IRIX, then it also works correctly. Once this is changed, I think we're finally done here :)
As mentioned earlier in this thread, cache method "none" is neither particularly fast, nor does it get all data. For instance, SLOTs or other data with is set only from the eclass (and not in the ebuild) are not found by this method.
0.10.5 was released/synced, does that fix this bug?
IRIX still requires '-ptused' to be added to $CXXFLAGS in order to link successfully... (and could probably do with '-woff 1209,1460,3604' too, in order to remove complaints about constant expressions, functions being redefined as inline, and missing return statements at the end of non-void functions) Finally, as a feature-request, is it possibly to change the package name format rules, to allow packages with trailing numerical suffix, as used in prefix-portage, such as "sys-devel/libperl-5.8.8-r01.1"? (At the moment, eix outputs many 'Garbage at end of version string: .1' mesages)
(In reply to comment #36) > IRIX still requires '-ptused' to be added to $CXXFLAGS in order to link > successfully... > > (and could probably do with '-woff 1209,1460,3604' I guess the prefix ebuild is the proper place for it - it does not seem reasonable to develop corresponding autotools tests unless you know a "standard" way. > rules, to allow packages with trailing numerical suffix, as used in > prefix-portage, such as "sys-devel/libperl-5.8.8-r01.1"? AFAIK there was a GLEP or bug report asking for extension of the -r format. However, to my knowledge there was never an agreement on the format. Suggestions were from -r1-r1 to only 5.8.8-rx.y or even arbitrary recursion like 5.8.8a_pre1-r1.2.3b_alpha_p5-r1.2x_rc1-r2 I am not sure whether it is a good idea to support an inofficial and probably preliminary format until it is clear which one... (such changes are rather cumbersome and will require a new eix database format; I would like to minimize changes of this format, since any change breaks things like update-eix-remote).
(In reply to comment #37) > (In reply to comment #36) > > IRIX still requires '-ptused' to be added to $CXXFLAGS in order to link > > successfully... > > > > (and could probably do with '-woff 1209,1460,3604' > > I guess the prefix ebuild is the proper place for it - it does not seem > reasonable to develop corresponding autotools tests unless you know > a "standard" way. Indeed, we can add this to the CXXFLAGS in the ebuild, quite easily I guess. > > rules, to allow packages with trailing numerical suffix, as used in > > prefix-portage, such as "sys-devel/libperl-5.8.8-r01.1"? > > AFAIK there was a GLEP or bug report asking for extension of the -r > format. However, to my knowledge there was never an agreement on the format. > Suggestions were from -r1-r1 to only 5.8.8-rx.y or even arbitrary recursion > like 5.8.8a_pre1-r1.2.3b_alpha_p5-r1.2x_rc1-r2 > I am not sure whether it is a good idea to support an inofficial and probably > preliminary format until it is clear which one... > (such changes are rather cumbersome and will require a new eix database > format; I would like to minimize changes of this format, since > any change breaks things like update-eix-remote). I agree here that Prefix's inter-revisions are a pure workaround. Technically they are not necessary for the main tree. I think the discussion you refer to here above is a different one, as inter-revisions are nothing more than revisions between revisions with a certain semantic towards the synchronisation process. See also "Ebuild inter-revisions" under http://www.gentoo.org/proj/en/gentoo-alt/prefix/techdocs.xml#doc_chap2 I admit that the warnings are annoying, and the best solution IMO would be to have a patch in Prefix that adds support for these revisions in some way, which will never make it upstream, and which will never be applied in mainline Gentoo. Prefix people could have a different database format for that reason without any problems, if necessary. Anyway, I'm not familiar with the code, neither have I had time and reason to dive into it to see if this can be done, but if anyone submits such a patch I'm happy to apply it in Prefix.
(In reply to comment #37) > See also "Ebuild inter-revisions" That's different. So it is a "supported" format and thus will go into eix. It is now in svn trunk. I hope that I understood correctly that the leading "0" for these subrevisions is non-optional, i.e. 1-r1.1 is not a correct number and will still throw a "trailing garbage .1" message, because it should be named 1-r01.1 instead. This is important, because it involves how revisions are sorted (which was the tricky part of the patch). Usually, -r02 < -r1 < -r2 but -r02.0 > -r2 > r002.99
(In reply to comment #39) > (In reply to comment #37) > > See also "Ebuild inter-revisions" > > That's different. So it is a "supported" format and thus will go into eix. > It is now in svn trunk. Ohw, wow thanks! > I hope that I understood correctly that the leading "0" for these subrevisions > is non-optional, i.e. 1-r1.1 is not a correct number and will still throw a > "trailing garbage .1" message, because it should be named 1-r01.1 instead. Correct. I did this intentionally. Prefix Portage doesn't "understand" 1-r1.1 the way I implemented it. It expects an inter-revision if -r is followed by a 0. That means that -r02 doesn't exist/is valid for me. I can't see how this is useful either, but that's a side issue. > This is important, because it involves how revisions are sorted > (which was the tricky part of the patch). Usually, > -r02 < -r1 < -r2 > but > -r02.0 > -r2 > r002.99 -r002.99 is invalid as far as I am concerned. It probably /is/ accepted by Prefix Portage, but it will treat it as if it were -r02.99 (hence just -r2). The Portage sources also seem to treat -r02 as -r2, so this behaviour is in line.
Not sure where to post this information... The just released eix-0.12.0 will hopefully solve two of the issues here, but this requires two changes in the prefix-ebuild: 1. The ./configure-option --disable-as-needed will skip the false positive test for the --as-needed flag. 2. The new cache method "parse|ebuild*" is hopefully much faster than ebuild* but should give similarly good results. Use ./configure-option "--with-portdir-cache-method=parse|ebuild*" to make it the default for the tree (if it is sufficiently fast in your opinion). If you think that the speed is inacceptable omit the "|ebuild*" part. Anyway, I suggest you wait with changes until eix-0.12.0 is in the x86 portage tree, since I guess that this ebuild will probably also have further changes.
(In reply to comment #41) > Not sure where to post this information... > > The just released eix-0.12.0 will hopefully solve two of the issues here, > but this requires two changes in the prefix-ebuild: > > 1. The ./configure-option --disable-as-needed will skip the false positive > test for the --as-needed flag. I added --disable-as-needed, as the choice whether or not --as-needed should be used is up to the user, not to a configure script. I'll file a bug about this to the eix maintainer to add this in the upstream ebuild too. (reached consensus on #-dev) > 2. The new cache method "parse|ebuild*" is hopefully much faster than ebuild* > but should give similarly good results. Use ./configure-option > "--with-portdir-cache-method=parse|ebuild*" to make it the default for the > tree (if it is sufficiently fast in your opinion). > If you think that the speed is inacceptable omit the "|ebuild*" part. Ok, the install message says that parse|ebuild* is the default now. If so, I can drop the entire configure argument, can I?
All issues appear to have been fixed for IRIX now, see bug #213248 Thanks for all contributions!
(In reply to comment #42) > Ok, the install message says that parse|ebuild* is the default now. It is the default for overlay-directories, not for the portage main-directory. To make it also the default for the latter the ./configure argument is needed.
