[Rd] Sun Forte 9 / configure compatability problem with 2.0/1.9.x (PR#7278)

[m.pacey at lancaster.ac.uk]

Full_Name: Mike Pacey
Version: 2.0, 1.9.x
OS: Solaris 8
Submission from: (NULL) (194.80.32.8)



Symptoms:
--------------

It seems the latest version of the Sun Compiler Suite (Forte 9) has
compatability issues with R's configure script. Starting with a fairly vanilla
configure (I'm using 1.9.1 here, but I've replicated the problem on 1.9.0 and
2.0.0):

% export CC=cc
% export F77=f95
% export CXX=CC
% ./configure
[snip]
checking for dummy main to link with Fortran libraries... unknown
configure: error: linking to Fortran libraries from C fails

config.log shows the following error:

Undefined                       first referenced
 symbol                             in file
omp_set_nested                     
/usr/local/packages/SUNWspro-9/SUNWspro/lib/v8plus/libfsu
.so
__mt_get_thread_num_               
/usr/local/packages/SUNWspro-9/SUNWspro/lib/v8plus/libfai
2.so
__mt_MasterFunction_               
/usr/local/packages/SUNWspro-9/SUNWspro/lib/v8plus/libfai
.so
omp_set_num_threads                
/usr/local/packages/SUNWspro-9/SUNWspro/lib/v8plus/libfsu
.so
__omp_in_parallel_                 
/usr/local/packages/SUNWspro-9/SUNWspro/lib/v8plus/libfai
2.so
omp_set_dynamic                    
/usr/local/packages/SUNWspro-9/SUNWspro/lib/v8plus/libfsu
.so
__omp_get_num_threads_             
/usr/local/packages/SUNWspro-9/SUNWspro/lib/v8plus/libfai
2.so
ld: fatal: Symbol referencing errors. No output written to conftest
configure:25232: $? = 1


Cause:
---------

The sections of the configure script before the linker failure seem to be
compiling a dummy fortran program in verbose mode in order to ream off the
relevant fortran libs and object files so that cc can replicate them during
linking.

The fortran compiler in Forte 9 now includes the directive "-lompstubs", which
for some reason is placed out of order for the linker. The forte compiler works
around this by flanking the lib call with -zallextract and -zdefaultextract,
effectively forcing the linker to extract all symbols in the ompstubs library so
that they're available for later libraries. The configure script is ignoring the
-z extraction directives, resulting in an out-of-order sequence of libs, and a
subsequent failure to resolve the symbols listed above.

Solution:
------------

As a temporary workaround, adding "-xopenmp=stubs" to LDFLAGS seems to work.

For a more permanent solution, I think the -z extraction directives need to be
preserved.