Description of problem: When building freefem++-2.23, its configure fails to detect mpic++ because the testcode fails to compile. Version-Release number of selected component (if applicable): gcc-4.3.0-0.10 How reproducible: Always Steps to Reproduce: 1. koji build --scratch --arch=ppc64 dist-f9 cvs://cvs.fedoraproject.org/cvs/pkgs?rpms/freefem++/devel#HEAD Actual results: configure:10009: checking for mpic++ configure:10034: mpic++ -o conftest -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mminimal-toc -DNDEBUG -O3 -mcpu=common -DDRAWING -DBAMG_LONG_LONG -DNCHECKPTR conftest.cpp -lpthread >&5 {standard input}: Assembler messages: {standard input}:1967: Error: Unrecognized opcode: `sldi' {standard input}:1985: Error: Unrecognized opcode: `sldi' {standard input}:2094: Error: Unrecognized opcode: `sldi' {standard input}:2104: Error: Unrecognized opcode: `sldi' {standard input}:2363: Error: Unrecognized opcode: `sldi' {standard input}:2382: Error: Unrecognized opcode: `sldi' {standard input}:2404: Error: Unrecognized opcode: `sldi' {standard input}:6050: Error: Unrecognized opcode: `sldi' {standard input}:6071: Error: Unrecognized opcode: `sldi' mpic++: No such file or directory configure:10040: $? = 1 configure: failed program was: | | #include <mpi.h> | #include <stdio.h> | int main(int argc,char **argv){ | char name[BUFSIZ]; | int length; | | MPI_Init(&argc, &argv); | MPI_Get_processor_name(name, &length); | printf("%s: hello world\n", name); | MPI_Finalize(); | return 0; | } configure:10057: result: no Expected results: configure:10057: result: yes Partial build.log (up to and including %configure part) attached.
Created attachment 295557 [details] build.log from koji
That's freemem++ crap. It has this garbage in acoptim.m4: # Generic code if test "$enable_debug" != yes \ -a "$enable_optim" != no \ -a "$enable_generic" = yes then CHECK_COMPILE_FLAG(C,-mcpu=common,CFLAGS) CHECK_COMPILE_FLAG(C++,-mcpu=common,CXXFLAGS) CHECK_COMPILE_FLAG(Fortran 77,-mcpu=common,FFLAGS) fi This is a bug for multiple reasons: 1) -mcpu is target dependent flag on some arches, but has different meanings between targets. On some targets it affects only tuning, on other arches it affects also the instruction set. Furthermore, the arguments to -mcpu= are very much target dependent, common is not a generic magic word. E.g. on i?86/x86_64, there is -mtune=generic which tells to tune for most common CPU set, etc. On ppc/ppc64, -mcpu=common is an ISA switch, not just tuning, and common is a 32-bit instruction set that doesn't include almost any 64-bit instructions, so -m64 -mcpu=common doesn't make any sense. You should just nuke this crap and make sure $RPM_OPT_FLAGS are included in CFLAGS/CXXFLAGS/FFLAGS when building.
Thank you, I missed the -mcpu=common part. Now that I know what's wrong, it's easy to fix.
And fixed, by removing --enable-generic from configure call.