[MOAB-dev] linking issues

Lorenzo Alessio Botti bottilorenzo at gmail.com
Thu May 14 12:28:56 CDT 2015 

Thanks, I was indeed trying to link an HDF5 (1.8.14) library not compiled by me.
So I need to first check how HDF5 was built and then add the corresponding options when I configure moab.

Great, I’ll try that. 
Bests.
Lorenzo


> On 14 May 2015, at 19:05, Vijay S. Mahadevan <vijay.m at gmail.com> wrote:
> 
> Hi Lorenzo,
> 
>> I wrongly assumed that you keep updating the old website with a link to latest stable release.
> 
> Our new website is: http://sigma.mcs.anl.gov, which contains
> information about the entire stack of codes we work here at ANL. The
> old trac pages are unmaintained and need to be taken down. Most of the
> info should now be available at the new website.
> 
>> Are you able to build moab with an HDF5 release newer than 1.8.10? I’m not, see attached config.log.
> 
> We regularly test/run with HDF5 1.8.(10-14) without issues. If you
> compiled HDF5 with szip, then you need add --with-szip=SZIP_DIR option
> to your configuration. SZip is not mandatory but this depends on how
> you configured your HDF5 installation.
> 
> Vijay
> 
> On Thu, May 14, 2015 at 11:59 AM, Lorenzo Alessio Botti
> <bottilorenzo at gmail.com> wrote:
>> WOW, sorry! I checked out the master branch and the linking issue is gone. Sorry for that.
>> I wrongly assumed that you keep updating the old website with a link to latest stable release.
>> 
>> Since we are discussing compilation issues...
>> Are you able to build moab with an HDF5 release newer than 1.8.10? I’m not, see attached config.log.
>> 
>> 
>> Is this an issue related to szip? With 1.8.10 szip dependency can be avoided.
>> Is it mandatory now?
>> 
>> Thanks a lot.
>> Lorenzo
>> 
>> 
>>> On 14 May 2015, at 17:21, Vijay S. Mahadevan <vijay.m at gmail.com> wrote:
>>> 
>>> 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
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>> 
>>

More information about the moab-dev mailing list