Bug 433870 - freefem++'s configure mpic++ test fails to build on ppc64
freefem++'s configure mpic++ test fails to build on ppc64
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: freefem++ (Show other bugs)
rawhide
ppc64 Linux
low Severity low
: ---
: ---
Assigned To: Dominik 'Rathann' Mierzejewski
Fedora Extras Quality Assurance
http://koji.fedoraproject.org/koji/ta...
: Reopened
Depends On:
Blocks: FE-ExcludeArch-ppc64/F-ExcludeArch-ppc64
  Show dependency treegraph
 
Reported: 2008-02-21 16:07 EST by Dominik 'Rathann' Mierzejewski
Modified: 2008-02-22 07:38 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-02-22 07:38:20 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
build.log from koji (146.86 KB, text/plain)
2008-02-21 16:07 EST, Dominik 'Rathann' Mierzejewski
no flags Details

  None (edit)
Description Dominik 'Rathann' Mierzejewski 2008-02-21 16:07:06 EST
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.
Comment 1 Dominik 'Rathann' Mierzejewski 2008-02-21 16:07:06 EST
Created attachment 295557 [details]
build.log from koji
Comment 2 Jakub Jelinek 2008-02-22 04:13:22 EST
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.
Comment 3 Dominik 'Rathann' Mierzejewski 2008-02-22 07:08:00 EST
Thank you, I missed the -mcpu=common part. Now that I know what's wrong, it's
easy to fix.
Comment 4 Dominik 'Rathann' Mierzejewski 2008-02-22 07:38:20 EST
And fixed, by removing --enable-generic from configure call.

Note You need to log in before you can comment on or make changes to this bug.