Opened 5 years ago

Last modified 3 years ago

#1909 reopened bug

Unable to build with Cray C compiler

Reported by: gropp Owned by: apenya
Priority: major Milestone: future
Component: mpich Keywords:
Cc:

Description

I'm testing the fix for #1815, and I'm unable to build MPICH with the Cray compilers (this is not related to the fix for #1815). The first problem was in the F9x module support, which I worked around. The next problem appears to be in the libtool support:

Making all in /u/staff/gropp/mpich-trunk/src/mpl
make[2]: Entering directory `/mnt/abc/u/staff/gropp/mpich-trunk/src/mpl'
  CC       src/mplstr.lo
  CC       src/mpltrmem.lo
  CC       src/mplenv.lo
  CCLD     libmpl.la
CC-2289 craycc: ERROR in command line
  Invalid characters after option '-s' in command line item '-soname'.
make[2]: *** [libmpl.la] Error 1
make[2]: Leaving directory `/mnt/abc/u/staff/gropp/mpich-trunk/src/mpl'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/mnt/abc/u/staff/gropp/mpich-trunk'
make: *** [all] Error 2
gropp@jyc1:~/mpich-trunk>

The configure options are

./configure CC=cc FC=ftn F77=ftn CXX=CC FCFLAGS=-em \
	--prefix=/u/staff/gropp/installs/mpich-devel \
	--with-atomic-primitives=no

(The FCFLAGS is required to get the F9X modules to build).

This is blocking my review of the fix for #1815

Change History (16)

comment:1 Changed 5 years ago by apenya

It looks like the correct option should be -Wl,-soname (I mean, the -Wl flag is missing). Maybe we need again a libtool.m4 patch like in ticket #1870 if we confirm libtool is the culprit assigning bad flags to the linking stage.

comment:2 Changed 5 years ago by apenya

  • Owner set to apenya
  • Status changed from new to assigned

comment:3 Changed 5 years ago by gropp

Let me know if there is a test I should run.

comment:4 Changed 5 years ago by apenya

I received a libtool patch from Steve Oyanagi from Cray. I think now I have the information I needed to patch libtool.m4 like in tt #1870 to generate a correct libtool supporting the Cray compiler.

comment:5 Changed 5 years ago by gropp

Great! Let me know when I can test it.

comment:6 Changed 5 years ago by apenya

  • Resolution set to fixed
  • Status changed from assigned to closed

Currently libtool doesn't know how to set the compilation flags for the cc compiler driver. This is something that Cray and libtool folks will eventually fix.
For now, the Cray's recommended way to compile MPICH on Cray systems is specifying CC=gcc. As this way works fine, I'm closing the ticket.

comment:7 Changed 5 years ago by balaji

  • Resolution fixed deleted
  • Status changed from closed to reopened

"don't use the Cray compiler" is not really a fix.

comment:8 Changed 5 years ago by balaji

  • Milestone changed from mpich-3.1 to future

comment:9 Changed 5 years ago by apenya

As it might not be clear, I just want to emphasize that the error happens when building shared libraries, so if using MPICH before 3.1.x, the --enable-shared flag needs to be added to the configure command in order to reproduce this error.

comment:10 Changed 5 years ago by balaji

I understand the issue. I agree that this problem always existed, it's not new. I also agree that this is a lower-priority item given that even the Cray folks don't have a good solution for this yet.

I'm just saying that this is still not fixed. I have moved this to "future", as it is not critical to fix for the upcoming releases, but I was just arguing that closing the ticket saying that it is fixed is not the right resolution. If you had closed it with the "wontfix" resolution type, that would have been a different story, though I don't think that's the right thing to do in this case either.

comment:11 Changed 5 years ago by apenya

Sorry, my post was not in reply to your previous one. Just including more information for NCSA/Cray/libtool guys after a private e-mail.

comment:12 Changed 5 years ago by apenya

Now that you mention it again, I closed the ticket because the problem was "Unable to build with Cray Fortran compiler", which is actually solved by CC=gcc. If we want to stay tuned for Cray + libtool to fix this, maybe we should create another ticket with a more descriptive subject pointing to this one.

comment:13 Changed 5 years ago by balaji

The point of the ticketing system is to keep track of known/reported issues. If this ticket doesn't address that, feel free to modify the ticket or create another ticket. But I'm vehemently opposed to closing a known issue. The only exception is if we explicitly decide to not fix something. But that's not what your resolution said and that's not what we decided to do.

comment:14 Changed 5 years ago by apenya

  • Summary changed from Unable to build with Cray Fortran compiler to Unable to build with Cray C compiler

I agree. Changing the subject to reflect the issue more accurately.

comment:15 Changed 3 years ago by apenya

Kalyana Chadalavada @ NCSA just forwarded me the following update from Cray:

Eric Bavier: Latest patch sent to the libtool developers:

http://lists.gnu.org/archive/html/libtool/2015-04/msg00003.html

comment:16 Changed 3 years ago by raffenet

I've kind of followed that thread on the libtool list. Seems their linker, like Bluegene, prefers static libraries to dynamic. We'll probably have to make our exceptions for Bluegene into a more general case.

Note: See TracTickets for help on using tickets.