[aspect-devel] [deal.II] Re: deal.ii problem during aspect compile, static libs

[Thorsten Becker]

Hi Wolfgang,

Thanks much for following up. I think your suggestions are spot on, and
after numerous different attempts, John succeeded just now to compile
everything in shared object mode. For this to work, we had to recompile
everything down to MPICH to not have some static libraries mess up stuff in
the end. This sounds a lot like the problems you describe...

So, yes, messed up mpich install on the cluster was the culprit in the end.

Thanks for your help!

Cheers

T


Thorsten W Becker - USC
http://geodynamics.usc.edu/~becker


On Thu, Jul 10, 2014 at 7:47 PM, Wolfgang Bangerth <bangerth at math.tamu.edu>
wrote:

>
> Thorsten,
> did you make progress on installing everything?
>
>
>
>  Trying to compile shared objects using your approach (or my earlier
>> attempts,
>> I think it was using the right compilers?), brings me back to errors like
>> the
>> one below with trilinos. It does appears that there's something funny
>> with the
>> local mpich2 install and how it calls the linker, but we haven't
>> experienced
>> these problems with other software, I think.
>>
>>
>> Linking CXX shared library libteuchoscore.so
>> /usr/bin/ld: /usr/usc/mpich2/1.5/lib/libmpich.a(allreduce.o): relocation
>> R_X86_64_32 against `.rodata.str1.8' can not be used when making a shared
>> obj
>> ect; recompile with -fPIC
>> /usr/usc/mpich2/1.5/lib/libmpich.a: could not read symbols: Bad value
>> collect2: error: ld returned 1 exit status
>>
>
> This happens when you try to link a shared library (here:
> libteuchoscore.so) and the command line contains not just regular object
> files that have been compiled with -fPIC (a flag you need when you want to
> work with shared libraries) but also object files that have been compiled
> without. In your case, I suspect that the command line contains the flag
>   -lmpich
> which may have been added by mpiCC internally. If there were both
>   /usr/usc/mpich2/1.5/lib/libmpich.so
> and
>   /usr/usc/mpich2/1.5/lib/libmpich.a
> then linking a shared library would imply taking the former but if the
> former does not exist, then this means that the linker will try to take
> apart the static archive (i.e., the libmpich.a file) into its individual
> object files and then link them into libteuchoscore.so -- which will
> produce the error message you see. Can you say which of these files you
> have?
>
>
> I have seen clusters where the MPI installation (or, more generally, all
> compilers) only support static linking. I see why system administrators
> want to do this, but this is a design that is fundamentally broken and only
> supports applications like Citcom that are essentially self contained. All
> more modern pieces of software (including the PETSc branch of Citcom, or
> ASPECT for that matter) will depend on multiple external libraries for
> which installation of static version is exceedingly difficult. If this is
> what the system requires, I have found that the only option is to ask
> system administrators to help with installation of the dependencies.
>
>
> Best
>  Wolfgang
>
> --
> ------------------------------------------------------------------------
> Wolfgang Bangerth               email:            bangerth at math.tamu.edu
>                                 www: http://www.math.tamu.edu/~bangerth/
>
> _______________________________________________
> Aspect-devel mailing list
> Aspect-devel at geodynamics.org
> http://lists.geodynamics.org/cgi-bin/mailman/listinfo/aspect-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.geodynamics.org/pipermail/aspect-devel/attachments/20140711/11408a2e/attachment.html>