I current have eix-0.15.2 installed, but attempting to upgrade to 0.15.3 results in: eix version 0.15.3 configured successfully. Good luck with make :) make make all-recursive make[1]: Entering directory `/usr/opt/portage/var/tmp/portage/app-portage/eix-0.15.3/work/eix-0.15.3' Making all in src make[2]: Entering directory `/usr/opt/portage/var/tmp/portage/app-portage/eix-0.15.3/work/eix-0.15.3/src' source='varsreader.cc' object='varsreader.o' libtool=no \ DEPDIR=.deps depmode=sgi /opt/portage/bin/bash ../config/depcomp \ CC -DHAVE_CONFIG_H -I. -I.. -I/opt/portage/usr/include -DSYSCONFDIR=\"/opt/portage/etc\" -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 varsreader.o varsreader.cc source='database/io.cc' object='database/io.o' libtool=no \ DEPDIR=.deps depmode=sgi /opt/portage/bin/bash ../config/depcomp \ CC -DHAVE_CONFIG_H -I. -I.. -I/opt/portage/usr/include -DSYSCONFDIR=\"/opt/portage/etc\" -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 database/io.o database/io.cc source='database/header.cc' object='database/header.o' libtool=no \ DEPDIR=.deps depmode=sgi /opt/portage/bin/bash ../config/depcomp \ CC -DHAVE_CONFIG_H -I. -I.. -I/opt/portage/usr/include -DSYSCONFDIR=\"/opt/portage/etc\" -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 database/header.o database/header.cc source='database/package_reader.cc' object='database/package_reader.o' libtool=no \ DEPDIR=.deps depmode=sgi /opt/portage/bin/bash ../config/depcomp \ CC -DHAVE_CONFIG_H -I. -I.. -I/opt/portage/usr/include -DSYSCONFDIR=\"/opt/portage/etc\" -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 database/package_reader.o database/package_reader.cc source='portage/conf/portagesettings.cc' object='portage/conf/portagesettings.o' libtool=no \ DEPDIR=.deps depmode=sgi /opt/portage/bin/bash ../config/depcomp \ CC -DHAVE_CONFIG_H -I. -I.. -I/opt/portage/usr/include -DSYSCONFDIR=\"/opt/portage/etc\" -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 portage/conf/portagesettings.o portage/conf/portagesettings.cc cc-1323 CC: ERROR File = portage/conf/portagesettings.cc, Line = 303 No operator "!=" matches these operands. The operand types are: std::vector<std::string, std::allocator<std::string>>::const_reverse_iterator != std::vector<std::string, std::allocator<std::string>>::reverse_iterator. it != overlays.rend(); ++it) ^ 1 error detected in the compilation of "portage/conf/portagesettings.cc". make[2]: *** [portage/conf/portagesettings.o] Error 2 make[2]: Leaving directory `/usr/opt/portage/var/tmp/portage/app-portage/eix-0.15.3/work/eix-0.15.3/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/opt/portage/var/tmp/portage/app-portage/eix-0.15.3/work/eix-0.15.3' make: *** [all] Error 2 * ERROR: app-portage/eix-0.15.3 failed: * emake failed * * Call stack: * ebuild.sh: 49: <call src_compile> * environment:2147: emake || die "emake failed"
please try if the suggestion from bug #255711 works here as well.
Yep - Bug #255711 fixes the IRIX build too. Incidentally, the following warnings were generated: cc-1516 CC: WARNING File = output/formatstring-print.cc, Line = 83 Comparison of an unsigned integer with a negative constant is suspicious. if(full == -1) ^ cc-1516 CC: WARNING File = output/formatstring-print.cc, Line = 92 Comparison of an unsigned integer with a negative constant is suspicious. if((full != -2) && (full != 2)) { ^ cc-1516 CC: WARNING File = output/formatstring-print.cc, Line = 319 Comparison of an unsigned integer with a negative constant is suspicious. if(full == -1) ^ cc-1516 CC: WARNING File = output/formatstring-print.cc, Line = 322 Comparison of an unsigned integer with a negative constant is suspicious. if((full != -2) && (full != 2)) ^
... although adding the "-signed" argument to $CFLAGS and $CXXFLAGS (for MIPSpro/IRIX) removes these warnings without seeming to cause any strange behaviour. Presumably there are no issues with the reduced range of signed char values, given that negative values are being compared against. I'm assuming that this is a GNU-ism? It might be an idea to explicitly state 'signed' where required.
*** This bug has been marked as a duplicate of bug 255711 ***
According to http://www.cppreference.com/wiki/data_types "char" should be equivalent to "signed char". Anyway, I will fix it in eix svn trunk.
Is that reference at all GNU-specific, though? The MIPSpro compiler man page says: -signed Causes values of type char to be treated as if they had type signed char (which can affect the result of integer promotions), but the values of CHAR_MIN and CHAR_MAX are not affected. The default is to treat values of type char as if they had type unsigned char. ... so I guess it's probably best to explicitly cast any char value where this could have an impact.
Actually, this is quite interesting: "8.7 Portability of signed and unsigned types The C and C++ standards allows the character type char to be signed or unsigned, depending on the platform and compiler. Most systems, including x86 GNU/Linux and Microsoft Windows, use signed char, but those based on PowerPC and ARM processors typically use unsigned char.(29) This can lead to unexpected results when porting programs between platforms which have different defaults for the type of char." http://www.network-theory.co.uk/docs/gccintro/gccintro_71.html ... and: "Three types of char are specified: signed, plain, and unsigned. A plain char may be represented as either signed or unsigned, depending upon the implementation, as in prior practice. The type signed char was introduced to make available a one-byte signed integer type on those systems which implement plain char as unsigned. For reasons of symmetry, the keyword signed is allowed as part of the type name of other integral types." "3.9.1 Fundamental types [basic.fundamental] 1 Objects declared as characters char) shall be large enough to store any member of the implementation's basic character set. If a character from this set is stored in a character object, the integral value of that character object is equal to the value of the single character literal form of that character. It is implementation-defined whether a char object can hold negative values. Characters can be explicitly declared unsigned or signed. Plain char, signed char, and unsigned char are three distinct types. A char, a signed char, and an unsigned char occupy the same amount of storage and have the same alignment requirements (basic.types); that is, they have the same object representation. For character types, all bits of the object representation participate in the value representation. For unsigned character types, all possible bit patterns of the value representation represent numbers. These requirements do not hold for other types. In any particular implementation, a plain char object can take on either the same values as a signed char or an unsigned char; which one is implementation-defined." Aren't standards great? :)
Could we have eix 'inherit flag-o-matic' and add a: [[ ${CHOST} = *-irix* ]] && append-flags -signed ... added to src_compile for the eix ebuilds?
does it error on it? I thought it was a warning.
You're right that it is just a warning - but if the author intended that chars be signed by default then there could potentially be all sorts of nastiness happening if this isn't the case :o ... especially that the chars in this case are being explicitly tested against negative values!
(In reply to comment #8) > [[ ${CHOST} = *-irix* ]] && append-flags -signed I do not think that this is necessary: As mentioned above, the issue should be fixed in eix svn trunk, and eix-0.15.4 will soon come out. Please inform me when you still get such warnings: It is certainly better to fix them in the source code than to work around them by compiler hacks.
It's a fair point, absolutely - and I agree. However, since the existing 0.15.3 is broken, does it not make sense to add this hack to the build for 0.15.3 and before, and then not include it for 0.15.4 when released to ensure that the problem really is resolved?
I have to add, that eix-0.15.2 also fails to emerge on amd64. I will open another bug for that.
0.15.4 is in the tree, resolving.
