[ncl-install] v 5.1.1 on x86_64 with PGI but g++ complains about unrecognized option '-pgf90libs', undefined references

[Marcin Sliwowski]

Mary,

Changing g\+\+ to pgcc in the if statements that applied to my NCL build
with GDAL support in the $NCARG/ni/src/ncl/yMakefile resolved the issue
of g++ getting involved. The entire build was done by pgcc and there
were no undefined references.

Many Thanks,
Marcin



Marcin Sliwowski wrote:
> Mary,
>
> Thank you very much for clearing up that awkward string replacement
> problem and pointing me in the direction of the yMakefile.
>
> I am not building the OPeNDAP enabled version, but I am compiling with,
> the brand new in this version of NCL, GDAL support. By looking at the
> yMakefile in $NCARG/ni/src/ncl/ it seems that building with support for
> GDAL also causes g++ to sneak into the compiling process. I believe this
> is the responsible snippet from the yMakefile that is causing it:
>
> #if defined(BuildDODS) || defined(BuildGDAL)
> #if defined(sun)
> CC_LD = g\+\+ -R/opt/SUNWspro/lib -L/opt/SUNWspro/lib
> CCOPTIONS = $(EXTRA_CCOPTIONS)
> #elif defined(AIX)
> CC_LD = xlC_r
> #elif defined(Darwin)
> CC_LD = g\+\+
> #elif defined(linux)
> CC_LD = g\+\+
> #else
> CC_LD = g\+\+
> #endif
> #endif
>
> I will replace the g\+\+ instances with pgCC, then do a make clean in
> $NCARG followed by a make Everything and let you know how it goes.
>
> Thank You,
> Marcin
>
> Mary Haley wrote:
>   
>> Marcin,
>>
>> There is quite a bit of information here, and we may need to fix one
>> problem at a time.
>>
>> First, the reason you are seeing 'linux' being replaced with '1' is
>> because 'linux' is
>> a predefined macro with the value of '1', and the ymake is "helpfully"
>> converting
>> these for you.
>>
>> Usually, to get around this, you can put single tickmarks around any
>> path that
>> has the word "linux" it in, or else try to avoid using "linux" as part
>> of a path.
>>
>> So, in your config file, wherever you are referencing:
>>
>>    -L/usr/local/hdfeos-2.14.v1/lib/linux -lhdfeos
>>
>> Try:
>>
>>   '-L/usr/local/hdfeos-2.14.v1/lib/linux -lhdfeos'
>>
>> The "g++" gets referenced if you are building an OPeNDAP enabled version
>> of NCL. Is this what you want? We highly recommend not building an
>> OPeNDAP version
>> unless you absolutely need it.
>>
>> If you need OPeNDAP, then you will need to edit the file
>> $NCARG/ni/src/ncl/yMakefile
>> and change the references to "g\+\+" to the appropriate PGI compiler.
>>
>> Try making these changes first, rerun "make Everything", and then let
>> me know what happens.
>> It would be best if you could send me the full "make-output" file so I
>> can see all the options and errors.
>> It's also helpful to send the LINUX config file you used.
>>
>> --Mary
>>
>> On Sep 30, 2009, at 8:16 AM, Marcin Sliwowski wrote:
>>
>>     
>>> Hello Mary Haley and Fellow NCL Compilers,
>>>
>>> Trying to compile NCL v. 5.1.1 on a 64 bit openSuse 11.1 system. The
>>> system has the full suite of Portland Group Compilers, c/c++ and fortran
>>> at v. 8.0-4. Have previously successfully compiled v. 5.0.0 andv.  5.1.0
>>> with these compilers.
>>>
>>> Current problem is a 2 part problem, not leaving out any details:
>>>
>>> The log from 'make Everything' shows the following single error:
>>>
>>> g++: unrecognized option '-pgf90libs'
>>> /usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld:
>>>
>>> cannot find -lhdfeos
>>> collect2: ld returned 1 exit status
>>> make[4]: *** [ncl] Error 1
>>>
>>> Skipping over the first problematic issue that somehow g++ is involved
>>> in the mix even though in $NCARG/config/ I have copied the file
>>> LINUX.64.PGI over the file LINUX, so now the #define of CCompiler and
>>> FCompiler are set to pgcc and pgf90 respectively. I must be doing
>>> something wrong or forgetting to do something.
>>>
>>> The other issue is that ld cannot file the library hdfeos. I have seen
>>> this problem in both of the 2 previous versions of NCL that I have
>>> compiled. To fix this problem I always have to do the following:
>>>
>>> The Makefile in $NCARG/ni/src/ncl seems to mangle up its LIBSEARCH and
>>> LIB_SEARCH paths somehow. In both of those variables the path to the
>>> hdfeos libraries has the string 'linux' replaced with the string '1'.
>>> For example in my case it should be
>>> -L/usr/local/hdfeos-2.14.v1/lib/linux but instead in both of the
>>> variables in the Makefile it is -L/usr/local/hdfeos-2.14.v1/lib/1. I
>>> don't know why the string 'linux' is replaced with the string '1', maybe
>>> it has something to do with the fact that I installed hdfeos under
>>> /usr/local/hdfeos-2.14.v1 instead of the default /usr/local. Does anyone
>>> know why this replacement occurs?
>>>
>>> There is another instance of the string 'linux' being replaced with the
>>> string '1'. In the INC_SEARCH and INCSEARCH variables in the same
>>> Makefile -I/usr/include/linux is replaced with -I/usr/include/1 which
>>> leads to the following error during a subsequent make depend in the
>>> current directory:
>>>
>>> cannot find include file "stddef.h" not in /usr/include/stddef.h
>>> cannot find include file "limits.h"
>>>
>>> I edit the Makefile replace the instances of '1' with 'linux' and then
>>> in that same directory I issue the commands: make includes, make depend
>>> and make all.
>>>
>>> On the "make all" is where I run into the serious trouble that I need
>>> help with. I get a whole slew of errors regarding undefined references,
>>> but before them I get the line: g++: unrecognized option '-pgf90libs'.
>>> Here are the undefined reference errors:
>>>
>>> dspmv.f:(.data+0x18): undefined reference to `pgf90_compiled'
>>> undefined reference to `pgf90io_encode_fmt'
>>> undefined reference to `pgf90io_fmt_write'
>>> undefined reference to `__c_mset8'
>>>
>>> At this point I comment out the current definition of the variable
>>> CTOFLIBS and insert the following in the Makefile:
>>> #CTOFLIBS       = -pgf90libs
>>> CTOFLIBS        = -pgf90libs -lpgc -lpgf90  -lpgf90_rpm1  -lpgf902
>>> -lpgftnrtl -lpghpf
>>>
>>> After this change the make all still states: g++: unrecognized option
>>> '-pgf90libs' and the number of undefined references drops significantly
>>> but the following kind still remain:
>>>
>>> /opt/pgi-8.04/linux86-64/8.0-4/lib/libpgf90.a(ftnexit.o): In function
>>> `f90io_pause':
>>> ftnexit.c:(.text+0x13e): undefined reference to `_mp_bcs_stdio'
>>> ftnexit.c:(.text+0x1d1): undefined reference to `_mp_ecs_stdio'
>>> /opt/pgi-8.04/linux86-64/8.0-4/lib/libpgftnrtl.a(ftncharsup.o): In
>>> function `ftn_str_copy':
>>> /usr/pgrel/extract/x86/8.0/rte/pgftn/hammer/lib-linux86-64/../../port/support/src/ftncharsup.c:83:
>>>
>>> undefined reference to `_mp_malloc'
>>> /usr/pgrel/extract/x86/8.0/rte/pgftn/hammer/lib-linux86-64/../../port/support/src/ftncharsup.c:106:
>>>
>>> undefined reference to `_mp_malloc'
>>> /usr/pgrel/extract/x86/8.0/rte/pgftn/hammer/lib-linux86-64/../../port/support/src/ftncharsup.c:147:
>>>
>>> undefined reference to `_mp_free'
>>> /usr/pgrel/extract/x86/8.0/rte/pgftn/hammer/lib-linux86-64/../../port/support/src/ftncharsup.c:159:
>>>
>>> undefined reference to `_mp_free'
>>>
>>> I am guessing that because g++ somehow gets involved it is not able to
>>> find the libraries that the PGI compilers come with that I am guessing
>>> would provided these methods that are currently undefined. In my
>>> environment I have the following variables exported:
>>>
>>> export CC=pgcc
>>> export CXX=pgCC
>>> export FC=pgf95
>>> export F77=pgf77
>>> export
>>> LD_LIBRARY_PATH=${PORTLAND_COMPILERS}/libso:${PORTLAND_COMPILERS}/lib:${LD_LIBRARY_PATH}
>>>
>>> export
>>> LIBRARY_PATH=${PORTLAND_COMPILERS}/lib:${PORTLAND_COMPILERS}/libso:${LIBRARY_PATH}
>>>
>>>
>>> Any help would be greatly appreciated.
>>>
>>> Thank You,
>>> Marcin
>>>
>>> -- 
>>> Marcin Sliwowski
>>> Systems Programmer
>>> Duke University - Pratt School of Engineering
>>> Office: 919-660-8450
>>>
>>> _______________________________________________
>>> ncl-install mailing list
>>> List instructions, subscriber options, unsubscribe:
>>> http://mailman.ucar.edu/mailman/listinfo/ncl-install
>>>       
>
>
>   


-- 
Marcin Sliwowski
Systems Programmer
Duke University - Pratt School of Engineering
Office: 919-660-8450