[CMake] rdynamic and fpp flags failing

[Server Levent Yilmaz]

On Fri, May 16, 2008 at 5:59 PM, Brad King <brad.king at kitware.com> wrote:

>
> CMake has not been taught about this compiler before.  I've just
> committed some changes to support the Portland Group Fortran compiler in
> CMake CVS.


Thanks Brad, with the HEAD version the project configures and builds fine.

However the executables are invalid. The reason, which took me a while to
figure out, is the use of shared libraries, which as I mentioned, is not
allowed in the Catamount system. The front-end wrappers unfortunately do not
automatically detect a possible misuse and proceed with linkage to any
shared library which happens to be present on the linker command line. It
turns out that the culprit was find_package(BLAS) in my CMakeLists.txt which
detects a shared library (correct one for the front ends, invalid for
Catamount).
How can I implement, locally at least, workarounds for such issues? (such as
say, prohibit finding and building shared library targets all together for
this particular system only)

On a further note, in case you may want to expand definitions for this
compiler, here are my suggestiong for a set of PGI flags for various build
types (from user's guide - http://www.pgroup.com/doc/pgiug.pdf)

Fortran_FLAGS = -Mpreprocess -Kieee -fpic
Fortran_FLAGS_DEBUG = -g -O0 -Mbounds
Fortran_FLAGS_MINSIZEREL = -O2 -s
Fortran_FLAGS_RELEASE = -fast -O3 -Mipa=fast
Fortran_FLAGS_RELWITHDEB = -O2 -gopt

Also, one particular weirdness using this compiler, as compared to Intel or
GNU compiler, is that CMake is somehow unable to copy the generated module
files to ${CMAKE_Fortran_MODULE_DIRECTORY}. It might be possible that the
related  flag is incompatible. It should be -module <dir> for the PGI
compiler, as opposed to -M<dir> for GNU.

cheers,
Levent

-- 
Server Levent Yilmaz
Mechanical Engineering
University of Pittsburgh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20080517/2032966d/attachment.htm>