dolfin team mailing list archive

[Johannes Ring <johannr@xxxxxxxxx>]

On Tue, Aug 24, 2010 at 1:38 PM, Anders Logg <logg@xxxxxxxxx> wrote:
> Johannes Ring skrev 2010-08-24 13.33:
>>
>> On Tue, Aug 24, 2010 at 1:27 PM, Anders Logg<logg@xxxxxxxxx>  wrote:
>>>
>>> Johannes Ring skrev 2010-08-24 11.02:
>>>>
>>>> On Tue, Aug 24, 2010 at 9:32 AM, Anders Logg<logg@xxxxxxxxx>    wrote:
>>>>>
>>>>> On Tue, Aug 24, 2010 at 09:24:51AM +0200, Johannes Ring wrote:
>>>>>>
>>>>>> On Tue, Aug 24, 2010 at 9:06 AM, Anders Logg<logg@xxxxxxxxx>    wrote:
>>>>>>>
>>>>>>> On Tue, Aug 24, 2010 at 08:56:10AM +0200, Johannes Ring wrote:
>>>>>>>>
>>>>>>>> On Tue, Aug 24, 2010 at 1:40 AM, Harish Narayanan
>>>>>>>> <harish.mlists@xxxxxxxxx>    wrote:
>>>>>>>>>
>>>>>>>>> On 8/24/10 4:14 AM, Anders Logg wrote:
>>>>>>>>>>
>>>>>>>>>> All packages except Trilinos work up to the point of linking now
>>>>>>>>>> where
>>>>>>>>>> I get errors pointing to undefined symbols: _camd_realloc,
>>>>>>>>>> _ccolamd_l_recommended, etc.
>>>>>>>>>>
>>>>>>>>>> I assume these are in AMD. The AMD libraries are added (in
>>>>>>>>>> FindCHOLMOD) but for some reason libcholmod.a appears after
>>>>>>>>>> libamd.a
>>>>>>>>>> on the link line. I can't figure out where that order comes from
>>>>>>>>>> or
>>>>>>>>>> how to change it.
>>>>>>>>>>
>>>>>>>>>> Any ideas?
>>>>>>>>>
>>>>>>>>> Johannes can fix this. We've been through *all* this before.
>>>>>>>>
>>>>>>>> Well, in cholmod.py in simula-scons we had this link line:
>>>>>>>>
>>>>>>>>   -L/some/path -lcholmod -lamd -lcamd -lcolamd -lccolamd -llapack
>>>>>>>> -lblas
>>>>>>>>
>>>>>>>> On darwin we had "-framework vecLib" instead of "-llapack -lblas".
>>>>>>>>
>>>>>>>> If CHOLDMOD was built with METIS (as Dorsal does) we also added
>>>>>>>> "-lmetis".
>>>>>>>
>>>>>>> Can you see if you can get this to work in CMake?
>>>>>>
>>>>>> Yes, I will look at it. I'm building it on Snow Leopard now.
>>>>>>
>>>>>> Johannes
>>>>>
>>>>> Great. Thanks.
>>>>
>>>> I have now tried to add a test program to FindCHOLMOD.cmake that
>>>> should fail if it is not linked correctly. It is not tested on Mac yet
>>>> as I have had some problems with MacPorts (I think I'll have to
>>>> reinstall it completely).
>>>>
>>>> Johannes
>>>
>>> The test breaks for me with the following error:
>>>
>>> Run Build Command:/usr/bin/make "cmTryCompileExec/fast"
>>> /usr/bin/make -f CMakeFiles/cmTryCompileExec.dir/build.make
>>> CMakeFiles/cmTryCompileExec.dir/build
>>> /opt/local/bin/cmake -E cmake_progress_report
>>>
>>> /Users/logg/Work/FEniCS/src/dolfin/dorsal_build_dir/CMakeFiles/CMakeTmp/CMakeFiles
>>> 1
>>> Building CXX object CMakeFiles/cmTryCompileExec.dir/src.cxx.o
>>> /usr/bin/mpic++    -DBOOST_UBLAS_NDEBUG  -DCHOLMOD_TEST_RUNS
>>> -I/opt/local/include/ufsparse   -o
>>> CMakeFiles/cmTryCompileExec.dir/src.cxx.o
>>> -c
>>>
>>> /Users/logg/Work/FEniCS/src/dolfin/dorsal_build_dir/CMakeFiles/CMakeTmp/src.cxx
>>>
>>> /Users/logg/Work/FEniCS/src/dolfin/dorsal_build_dir/CMakeFiles/CMakeTmp/src.cxx:1:
>>> error: expected constructor, destructor, or type conversion at end of
>>> input
>>> make[1]: *** [CMakeFiles/cmTryCompileExec.dir/src.cxx.o] Error 1
>>> make: *** [cmTryCompileExec/fast] Error 2
>>
>> I also got that but then it disappeared. I think it was because I
>> cleaned up my build tree. Have you tried that?
>>
>> Johannes
>
> Yes, if by that you mean deleting dorsal_build_dir.

Yes, that's what I meant. However, that wasn't the reason it suddenly
worked for me. I now see that I get the same error as you unless I'm
adding the flag --debug-trycompile when running cmake. It's kinda
strange that it works with this flag but not without it. I will look
into it.

Johannes