[MOAB-dev] linking issues

Thu May 14 12:05:02 CDT 2015

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
>>>
>>>
>>>
>>>
>>>
>
>