[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[netCDF #PQU-107704]: Building NetCDF-cxx4 4.2.1 with PGI and mvapich2



Hi Chris,

Thanks for your bug report and workaround!

I've created a Jira issue tracking report with the details you provided, as 
well as a link
to the patch for the generated libtool that you created as a workaround:

  https://bugtracking.unidata.ucar.edu/browse/NCXXF-11

For now, I hope that will help other users  find your solution in case they who 
encounter 
the same problem.

--Russ

> There appears to be some kind of problem in the NetCDF-cxx4 build system when 
> using PGI and mvapich2 to link against a NetCDF 4.3.0 that was built with 
> --enable-parallel-test.  I am using the latest stable release (4.2.1) of 
> NetCDF-cxx4, PGI versions 12.5-0 and/or 13.2-0, and mvapich2 version 1.8.  I 
> can configure and build NetCDF-cxx4 using a NetCDF that was built either with 
> or without parallel support using the Intel compilers.  And I can configure 
> and build NetCDF-cxx4 with PGI for a non-parallel build.  To be specific, the 
> problem is that the build refuses to produce a shared library for NetCDF-cxx4 
> when using mpicxx (MPI wrapper for pgCC) for the C++ compiler.
> 
> The problem seems to be that, for whatever reason, it does not know how to 
> correctly recognize/test for shared library.  The libtool that is generated 
> won't create the shared library for NetCDF-cxx4 but the "configure" and 
> "make" steps do run fine and produce a static library.  The "make check" then 
> fails because it tries to link to a non-existent shared library.
> 
> I have been able to work around this problem for now by applying the 
> following patch to the libtool that is generated when configuring 
> NetCDF-cxx4, but am wondering if there might be some underlying problem that 
> needs fixing.  Applying that patch allows "make" and "make check" to work 
> without generating errors.
> 
> While I did do quite a lot of searching for other reports of this problem I 
> did not find anything.  Any advice or comments regarding the appropriateness 
> of my libtool patch or a better solution would be much appreciated.
> 
> 
> --- build/netcdf-cxx4-mvapich2/4.2.1/pgi/12.5-0/mvapich2/1.8/libtool  
> 2014-01-10 20:01:32.000000000 +0000
> +++ build/netcdf-cxx4/4.2.1/pgi/12.5-0/libtool        2014-01-10 
> 20:19:33.000000000 +0000
> @@ -332,7 +332,7 @@
> export_dynamic_flag_spec="\${wl}--export-dynamic"
> 
> # Compiler flag to generate shared objects directly from archives.
> -whole_archive_flag_spec="\${wl}--whole-archive\$convenience 
> \${wl}--no-whole-archive"
> +whole_archive_flag_spec="\${wl}--whole-archive\`for conv in 
> \$convenience\\\"\\\"; do test  -n \\\"\$conv\\\" && 
> new_convenience=\\\"\$new_convenience,\$conv\\\"; done; func_echo_all 
> \\\"\$new_convenience\\\"\` \${wl}--no-whole-archive"
> 
> # Whether the compiler copes with passing no objects directly.
> compiler_needs_object="no"
> @@ -10113,10 +10113,10 @@
> no_builtin_flag=""
> 
> # Additional compiler flags for building library objects.
> -pic_flag=" -DPIC"
> +pic_flag=" -fpic -DPIC"
> 
> # How to pass a linker flag through the compiler.
> -wl=""
> +wl="-Wl,"
> 
> # Compiler flag to prevent dynamic linking.
> link_static_flag=""
> @@ -10131,10 +10131,10 @@
> allow_libtool_libs_with_static_runtimes=no
> 
> # Compiler flag to allow reflexive dlopens.
> -export_dynamic_flag_spec=""
> +export_dynamic_flag_spec="\${wl}--export-dynamic"
> 
> # Compiler flag to generate shared objects directly from archives.
> -whole_archive_flag_spec=""
> +whole_archive_flag_spec="\${wl}--whole-archive\`for conv in 
> \$convenience\\\"\\\"; do test  -n \\\"\$conv\\\" && 
> new_convenience=\\\"\$new_convenience,\$conv\\\"; done; func_echo_all 
> \\\"\$new_convenience\\\"\` \${wl}--no-whole-archive"
> 
> # Whether the compiler copes with passing no objects directly.
> compiler_needs_object="no"
> @@ -10146,8 +10146,8 @@
> old_archive_from_expsyms_cmds=""
> 
> # Commands used to build a shared archive.
> -archive_cmds=""
> -archive_expsym_cmds=""
> +archive_cmds="\$CC -shared \$pic_flag \$predep_objects \$libobjs \$deplibs 
> \$postdep_objects \$compiler_flags \${wl}-soname \${wl}\$soname -o \$lib"
> +archive_expsym_cmds="\$CC -shared \$pic_flag \$predep_objects \$libobjs 
> \$deplibs \$postdep_objects \$compiler_flags \${wl}-soname \${wl}\$soname 
> \${wl}-retain-symbols-file \${wl}\$export_symbols -o \$lib"
> 
> # Commands used to build a loadable module if different from building
> # a shared archive.
> @@ -10165,7 +10165,7 @@
> 
> # Flag to hardcode $libdir into a binary during linking.
> # This must work even if $libdir does not exist
> -hardcode_libdir_flag_spec=""
> +hardcode_libdir_flag_spec="\${wl}--rpath \${wl}\$libdir"
> 
> # Whether we need a single "-rpath" flag with a separated argument.
> hardcode_libdir_separator=""
> @@ -10222,7 +10222,7 @@
> file_list_spec=""
> 
> # How to hardcode a shared library path into an executable.
> -hardcode_action=unsupported
> +hardcode_action=immediate
> 
> # The directories searched by this compiler when creating a shared library.
> compiler_lib_search_dirs=""
> 
> ## End of patch
> 
> 
> 
> Thank you for your consideration,
> 
> 
> Chris
> -----------------------------------------------------------------------------------------------------------
> Christopher W. Harrop                               email: address@hidden
> Global Systems Division                                                       
>    voice: (303) 497-6808
> NOAA Earth System Research Laboratory                               fax: 
> (303) 497-7259
> 325 Broadway R/GSD2
> Boulder, CO 80303
> 
> 
> 
Russ Rew                                         UCAR Unidata Program
address@hidden                      http://www.unidata.ucar.edu



Ticket Details
===================
Ticket ID: PQU-107704
Department: Support netCDF
Priority: High
Status: Closed


NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.