[MOAB-dev] Redundant -L/usr/lib causing problems

[Jason Kraftcheck]

Jed Brown wrote:
> On Mon, 01 Mar 2010 15:22:59 -0600, Jason Kraftcheck <kraftche at cae.wisc.edu> wrote:
>> After looking at this further, I think that this is not a bug.  The
>> --with-zoltan and --with-parmetis flags are available solely for the purpose
>> of specifying alternate locations in which to look for those libraries.  If
>> they are in the default search path then it should be sufficient to specify
>> *only* '--enable-mbzoltan'.
> 
> This works[1], but it is very confusing for the user to determine which
> options must be specified, which are optional, which need an argument,
> and which must be specified without an argument.  My usual procedure
> with a new library is to run configure --help, then specify
> --with-xxx=/path/to/xxx for each optional package that I have available.
> The current MOAB situation is far more delicate.
> 

I have already checked in a fix that allows them to be specified w/ no
value.  Given that you are already specifying --enable-mbzoltan, specifying
them with no value will have no effect on anything, but it won't print an
error message any more.


> Jed
> 
> [1] Actually, all the tests fail due to symbol versioning errors.
> 
>   /home/jed/build/moab/bompi/parallel/.libs/lt-pcomm_unit: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.14' not found (required by /home/jed/build/moab/bompi/.libs/libMOAB.so.0)
> 
> I can fix this by setting
> 
>   LD_LIBRARY_PATH=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.0
> 
> but no other C++ projects require this hackery.  

I haven't seen this error before.  My first guess is that something on your
system changed with respect to the C++ compiler and you need to re-build MOAB.

> Perhaps this is due to the use of -nostdlib?
> 

We don't use that.  I grepped every file in the MOAB source and build
results.  The only files that contain 'nostdlib' are generated by autotools
(aclocal.m4 and therefore configure).

- jason