This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
> > Howdy, > > > > During a recent build attempt of software that uses the netcdf > > static libraries, we found that we were unable to build the software > > using the -Bstatic flag. Further investigation seems to point to the > > configure script of the netcdf software finding false positive > > detections of errors when using the -Bstatic flag in the compile step. > > It appears that standard license manager output (like that seen below) > > is being dumped into the test file std err files (conftest.err) and is > > disallowing the use of the -Bstatic flag in the building/linking of the > > netcdf software. > > > > ------------- License Manager Std out ----------------------- > > pgf90 6.2-5 64-bit target on x86-64 Linux > > Copyright 1989-2000, The Portland Group, Inc. All Rights Reserved. > > Copyright 2000-2006, STMicroelectronics, Inc. All Rights Reserved. > > yes > > checking if Fortran "doubleprecision" is C "double"... > > pgcc 6.2-5 64-bit target on x86-64 Linux > > Copyright 1989-2000, The Portland Group, Inc. All Rights Reserved. > > Copyright 2000-2006, STMicroelectronics, Inc. All Rights Reserved. > > -------------------------------------------------------------- > > > > We bypassed this false positive occurrence by forcibly setting the > > static flag variable in the configure file for each of the compilers: > > > > Howdy Carter. > > I don't think the compiler output with the copyright is causing any problems. Lots of compilers do that (but it is annoying to look at!) > > Have you tried building without the static flag set? > > Have you tried setting FCFLAGS and F77FLAGS to -Bstatic? > > Unfortunately our test machine with the portland group compiler has suffered a tragic fate, and is no longer around. I have asked our sysadmin to restore the portland group compilers on one of my test machines, and then I can try the -Bstatic option myself. > > Ed Howdy again Carter, I have looked into the -Bstatic flag for portland group compilers. I don't have a full understanding of it, but it turns off the use of shared libraries by the program, and allows larger fortran arrays, as I understand it. I have gotten the netCDF 3.6.x snapshot to build with portland group, using the -Bstatic flag. The problem (on my machine) was that using that flag seems to put the fortran compiler into 32-bit mode on this 32/64 machine. So I had to use the -m32 option with gcc (i.e. by setting the CFLAGS). The clue was in the config.log file: configure:22961: gcc -c -static conftest.c conftest.c: In function 'sub_': conftest.c:4: warning: incompatible implicit declaration of built-in function 'exit' configure:22964: $? = 0 configure:22967: /opt/pgi/linux86/7.0-2/bin/pgf95 -Bstatic -c conftestf.f conftestf.f: configure:22970: $? = 0 configure:22973: /opt/pgi/linux86/7.0-2/bin/pgf95 -o conftest -Bstatic conftestf.o conftest.o /usr/bin/ld: warning: i386:x86-64 architecture of input file `conftest.o' is incompatible with i386 output As this shows, the configure script is compiling a C (conftest.c) and a fortran file (conftestf.f) and linking them together. But it is finding that the compiled C file is 64-bit and the compiled fortran is 32-bits. I got it to work like this: make distclean && CFLAGS=-m32 FC=/opt/pgi/linux86/7.0-2/bin/pgf95 FFLAGS=-Bstatic F90FLAGS=-Bstatic ./configure --disable-cxx && make check The -m32 option tells the GNU C compiler to produce 32 bit code. I have added this configuration to our nightly snapshot testing, to ensure that we don't break it! Thanks, Ed Ticket Details =================== Ticket ID: AFH-985814 Department: Support netCDF Priority: Normal Status: Closed