[MOAB-dev] linking issues

Thu May 14 10:21:42 CDT 2015

Thanks for the clarification Lorenzo. The MOAB_LIBS_LINK variable only
contains dependencies for compiling C++ based MOAB drivers and so
-lstdc++ is redundant here since the C++ compiler can resolve the
paths correctly. We specifically check for the standard C++ library
only when linking fortran codes. This should be in the FLIBS variable
which we currently don't write out to moab.make. Additionally, for
Intel compilers, using the flag "-cxxlib" during both compile/link
stages will resolve this issue without stdc++. This is available from
current master branch.

I also noticed that you are using MOAB 4.6.3 which is more than a year
old. We've made quite a few modifications to the current release
version MOAB 4.8.1 which contains several fixes for fortran linkage
among other things. Can you upgrade your MOAB installation ? Is there
a reason why you want the older versions specifically ?

Vijay

On Thu, May 14, 2015 at 4:13 AM, Lorenzo Alessio Botti
<bottilorenzo at gmail.com> wrote:
> Dear Vijay,
> in attachment the config.log file.
> I don’t think there’s a failure here. Indeed libMOAB.la is correct and MOAB
> tests compile and run.
>
> The problem is that the path for libstdc++ is not included in the
> MOAB_LIBS_LINK in moab.make. Since I use moab.make to link MOAB to my
> application I need to add it manually
>
> MOAB_LIBS_LINK = ${MOAB_LDFLAGS} -L${MOAB_LIBDIR} -lMOAB  -lm    -lhdf5
> -lgpfs  -lz -ldl /cineca/prod/compilers/gnu/4.9.2/none/lib64/libstdc++.a
>
>
> Is there an other (more correct) way to link MOAB?
>
> Thanks for help.
> Lorenzo
>
>
>
>
> On 12 May 2015, at 21:49, Vijay S. Mahadevan <vijay.m at gmail.com> wrote:
>
> Lorenzo,
>
> In our autoconf configuration, we do find and add -lstdc++ when
> compiling with fortran enabled. But we have not tested with GNU 4.9.2
> AFAIK and so possibly the behavior is slightly different because in
> older versions, libstdc++ is typically available in a system or
> compiler dependent path. I've never had to specify a libtool path to
> libstdc++ before. Can you send us the config.log so that we can
> decipher where this failed ?
>
> You can also take a look at config/compilers.m4 (search for stdc++) to
> see where we add the flag currently and why it might possibly fail the
> checks. If you are comfortable with autoconf, we would also be very
> happy to accept a patch.
>
> Vijay
>
> On Tue, May 12, 2015 at 12:34 PM, Lorenzo Alessio Botti
> <bottilorenzo at gmail.com> wrote:
>
> Hi all,
> I’d like know your opinion on a problem I recently encountered compiling
> moab with intel compilers on a cluster at cineca (an Italian HPC facility)
>
> When compiling my application linked to moab I got the following errors
> /galileo/home/userexternal/lbotti00/moab/lib/libMOAB.a(ReaderWriterSet.o):
> In function `moab::ReaderWriterSet::get_file_extension_reader(std::string
> const&) const':
> ReaderWriterSet.cpp:(.text+0xa22): undefined reference to
> `std::__throw_out_of_range_fmt(char const*, ...)'
> /galileo/home/userexternal/lbotti00/moab/lib/libMOAB.a(ReaderWriterSet.o):
> In function `moab::ReaderWriterSet::get_file_extension_writer(std::string
> const&) const':
> ReaderWriterSet.cpp:(.text+0xb72): undefined reference to
> `std::__throw_out_of_range_fmt(char const*, ...)'
> /galileo/home/userexternal/lbotti00/moab/lib/libMOAB.a(ReaderWriterSet.o):
> In function `moab::ReaderWriterSet::extension_from_filename(std::string
> const&)':
> ReaderWriterSet.cpp:(.text+0xcc7): undefined reference to
> `std::__throw_out_of_range_fmt(char const*, ...)'
> /galileo/home/userexternal/lbotti00/moab/lib/libMOAB.a(ReadABAQUS.o): In
> function `moab::ReadABAQUS::get_keyword()':
> ReadABAQUS.cpp:(.text+0x19c0): undefined reference to
> `std::__throw_out_of_range_fmt(char const*, ...)'
> ReadABAQUS.cpp:(.text+0x19fb): undefined reference to
> `std::__throw_out_of_range_fmt(char const*, ...)'
> /galileo/home/userexternal/lbotti00/moab/lib/libMOAB.a(ReadABAQUS.o):ReadABAQUS.cpp:(.text+0x285d):
> more undefined references to `std::__throw_out_of_range_fmt(char const*,
> ...)' follow
>
> The problem seems to be related with
> /cineca/prod/compilers/gnu/4.9.2/none/lib64/libstdc++.la
> which is present in libMOAB.la but is missing in moab.make (see below)
>
> (libMOAB.la)
>
> # libMOAB.la - a libtool library file
> # Generated by libtool (GNU libtool) 2.4.2
> #
> # Please DO NOT delete this file!
> # It is necessary for linking the library.
>
> # The name that we can dlopen(3).
> dlname=''
>
> # Names of this library.
> library_names=''
>
> # The name of the static archive.
> old_library='libMOAB.a'
>
> # Linker flags that can not go in dependency_libs.
> inherited_linker_flags=''
>
> # Libraries that this one depends upon.
> dependency_libs=' -L/galileo/home/userexternal/lbotti00/hdf5-1.8.10/hdf5/lib
> /galileo/home/userexternal/lbotti00/hdf5-1.8.10/hdf5/lib/libhdf5.la -lgpfs
> -lz /cineca/prod/compilers/gnu/4.9.2/none/lib64/libstdc++.la'
>
> # Names of additional weak libraries provided by this library
> weak_library_names=''
>
> # Version information for libMOAB.
> current=0
> age=0
> revision=0
>
> # Is this an already installed library?
> installed=no
>
> # Should we warn about portability when linking against -modules?
> shouldnotlink=no
>
> # Files to dlopen/dlpreopen
> dlopen=''
> dlpreopen=''
>
> # Directory that this library needs to be installed in:
> libdir='/galileo/home/userexternal/lbotti00/moab/lib'
> ~
>
>
>
> (maob.make)
> # The values below are for an un-installed copy of MOAB used directly
> # from its build build directory.  These values will be overridden below
> # for installed copies of MOAB.
> MOAB_LIBDIR = /galileo/home/userexternal/lbotti00/moab-4.6.3/src/.libs
> MOAB_INCLUDES = -I/galileo/home/userexternal/lbotti00/moab-4.6.3/src \
>                -I/galileo/home/userexternal/lbotti00/moab-4.6.3/src \
>                -I/galileo/home/userexternal/lbotti00/moab-4.6.3/src/oldinc
> \
>
> -I/galileo/home/userexternal/lbotti00/moab-4.6.3/src/parallel \
>
> -I/galileo/home/userexternal/lbotti00/moab-4.6.3/src/parallel
>
> MOAB_INCLUDES +=
>
> MOAB_CPPFLAGS =  -DUNORDERED_MAP_NS=std::tr1
> -DHAVE_UNORDERED_MAP=tr1/unordered_map
> -DHAVE_UNORDERED_SET=tr1/unordered_set
> -I/galileo/home/userexternal/lbotti00/hdf5-1.8.10/hdf5/include -isystem
> /galileo/home/userexternal/lbotti00/hdf5-1.8.10/hdf5/include
> -DTEMPLATE_SPECIALIZATION -DTEMPLATE_FUNC_SPECIALIZATION -DHAVE_VSNPRINTF
> -D_FILE_OFFSET_BITS=64   -DUSE_MPI -DHDF5_FILE -DHDF5_PARALLEL
> MOAB_CXXFLAGS =  -Wall -wd981 -wd279 -wd1418 -wd383 -wd1572 -wd2259 -O2
> -DNDEBUG
> MOAB_CFLAGS =  -Wall -wd981 -wd279 -wd1418 -wd383 -wd1572 -O2 -DNDEBUG
> MOAB_FFLAGS =   -O2
> MOAB_FCFLAGS =   -O2
> MOAB_LDFLAGS =
> -L/galileo/home/userexternal/lbotti00/hdf5-1.8.10/hdf5/lib
>
> MOAB_LIBS_LINK = ${MOAB_LDFLAGS} -L${MOAB_LIBDIR} -lMOAB  -lm    -lhdf5
> -lgpfs  -lz -ldl
>
> MOAB_CXX =
> /cineca/prod/compilers/intel/cs-xe-2015/binary/impi_5.0.2/intel64/bin/mpicxx
> MOAB_CC  =
> /cineca/prod/compilers/intel/cs-xe-2015/binary/impi_5.0.2/intel64/bin/mpicc
> MOAB_FC  = ifort
> MOAB_F77  = ifort
>
> # Override MOAB_LIBDIR and MOAB_INCLUDES from above with the correct
> # values for the installed MOAB.
>
> Adding the missing .la fixes the linking issue.
>
> What do you guys think? I’m not an expert of this kind of problems...
>
> Bests
> Lorenzo
>
>
>
>
>