dolfin team mailing list archive

["Matthew Knepley" <knepley@xxxxxxxxx>]

On Tue, Jul 29, 2008 at 3:58 AM, Johannes Ring <johannr@xxxxxxxxx> wrote:
> On Tue, July 29, 2008 10:18, Ilmar Wilbers wrote:
>> Are there any C++ experts that can highlight this problem? The order of
>> the arguments and the filename given to the compiler, that is? It would
>> be simple enough to change the order to fix this, but I'm always curious
>> as to why something like that would work.
>
> I have no idea what the problem might be, but I changed the order of the
> arguments and the filename now.

The problem is the convention on linker arguments. If you require symbols from
another file (.o or library), that library must come AFTER the
original file on the
link line. Thus the tst .o must come before the library it needs.

  Matt

> Johannes
>
>> Ilmar Wilbers wrote:
>>> OK, I'm sorry for spamming, but I'm getting a bit frustrated, I think it
>>> is time to go home.
>>>
>>> But could someone please explain me this:
>>> Running python
>>> scons/simula-scons/simula_scons/pkgconfiggenerators/umfpack.py results
>>> in
>>> the following commands being run:
>>> g++ -I../../SuiteSparse/UMFPACK/Include -I../../SuiteSparse/AMD/Include
>>> -I../../SuiteSparse/UFconfig umfpack_config_test_include.cpp
>>> -L/usr/lib/atlas -lblas -L../../SuiteSparse/UMFPACK/Lib -lumfpack
>>> -L../../SuiteSparse/AMD/Lib -lamd
>>> g++ -I../../SuiteSparse/UMFPACK/Include -I../../SuiteSparse/AMD/Include
>>> -I../../SuiteSparse/UFconfig -c umfpack_config_test_lib.cpp
>>> g++ -L/usr/lib/atlas -lblas -L../../SuiteSparse/UMFPACK/Lib -lumfpack
>>> -L../../SuiteSparse/AMD/Lib -lamd umfpack_config_test_lib.o
>>>
>>> The first two are always successfull, whereas the last ones causes the
>>> linking error. But when writing:
>>> g++ umfpack_config_test_lib.o -L/usr/lib/atlas -lblas
>>> -L../../SuiteSparse/UMFPACK/Lib -lumfpack -L../../SuiteSparse/AMD/Lib
>>> -lamd
>>> instead of
>>> g++ -L/usr/lib/atlas -lblas -L../../SuiteSparse/UMFPACK/Lib -lumfpack
>>> -L../../SuiteSparse/AMD/Lib -lamd umfpack_config_test_lib.o
>>> that is, moving umfpack_config_test_lib.o directly after g++, it works.
>>>
>>> Could someone please explain this to me?
>>>
>>> ilmar
>>>
>>>
>>>
>>>> i get the exact same error when using the umfpack i downloaded
>>>> manually... i don't get it.
>>>>
>>>> ilmar
>>>>
>>>> Ilmar Wilbers wrote:
>>>>
>>>>> it seems the problem has been there earlier. it is always good fun
>>>>> when
>>>>> you are googling for a solution and it points back to the dolfin-dev
>>>>> mailinglist
>>>>> http://www.mail-archive.com/dolfin-dev@xxxxxxxxxx/msg02297.html
>>>>>
>>>>> i tried johannes' suggestion, but i still get the linking error
>>>>>
>>>>> ilmar
>>>>>
>>>>> Ilmar Wilbers wrote:
>>>>>
>>>>>
>>>>>> well, i am currently updating
>>>>>> http://www.fenics.org/wiki/A_detailed_guide_to_installing_DOLFIN
>>>>>> it is for older systems, or systems without package managers. i have
>>>>>> had
>>>>>> some questions from people who use some linux distros that are not
>>>>>> quite
>>>>>> as common.
>>>>>>
>>>>>> here, the umfpack from petsc is used.
>>>>>>
>>>>>> ilmar
>>>>>>
>>>>>> Garth N. Wells wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Ilmar Wilbers wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> I cannot figure this one out. To me, it seems that petsc doesn't
>>>>>>>> build
>>>>>>>> umfpack so that we can use it with dolfin. I am trying to update
>>>>>>>> the
>>>>>>>> wiki
>>>>>>>> with the detailed instructions. The nice feature of using the
>>>>>>>> umfpack
>>>>>>>> that
>>>>>>>> comoes with petsc is that one doesn't need to download and
>>>>>>>> configure/
>>>>>>>> make
>>>>>>>> three different packages (umfpack/ amd/ ufconfig).
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> But UMFPACK comes as a package for all mainstream Linux
>>>>>>> distributions
>>>>>>> and for OSX through fink, so why do you want to build it?
>>>>>>>
>>>>>>> A more worthwhile pursuit would be getting PETSc to use the
>>>>>>> installed
>>>>>>> UMFPACK. I had a quick go at this, but didn't pursue it.
>>>>>>>
>>>>>>> Garth
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Will leave this untill someone can tell we what I am doing wrong.
>>>>>>>>
>>>>>>>> ilmar
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> I am trying to use the umfpack that came with petssc. Petsc is
>>>>>>>>> configured
>>>>>>>>> as follows:
>>>>>>>>> ./config/configure.py --with-mpi-dir=$INSTALL_PATH
>>>>>>>>> --with-clanguage=cxx
>>>>>>>>> --download-hypre=yes --enable-hypre=1 --download-umfpack=yes
>>>>>>>>> --enable-umfpack=1 --enable-shared=1
>>>>>>>>>
>>>>>>>>> What options do I need to give to scons? I tried setting the
>>>>>>>>> variable
>>>>>>>>> UMFPACK_DIR to
>>>>>>>>> $PETSC_DIR/externalpackages/UMFPACKv4.3/linux-gnu-cxx-debug/UMFPACK
>>>>>>>>>
>>>>>>>>> I also tried to add
>>>>>>>>> $PETSC_DIR/externalpackages/UMFPACKv4.3/linux-gnu-cxx-debug/UMFPACK/Lib
>>>>>>>>> to
>>>>>>>>> LD_LIBRARY_PATH, still without success (Anders thought this wasn't
>>>>>>>>> necessary as petsc was configured with enable-shared). I keep
>>>>>>>>> getting a
>>>>>>>>> linking error when running the package config generator:
>>>>>>>>> umfpack_config_test_lib.o: In function `main':
>>>>>>>>> umfpack_config_test_lib.cpp:(.text+0x59): undefined reference to
>>>>>>>>> `umfpack_di_symbolic(int, int, int const*, int const*, double
>>>>>>>>> const*,
>>>>>>>>> void**, double const*, double*)'
>>>>>>>>> umfpack_config_test_lib.cpp:(.text+0x91): undefined reference to
>>>>>>>>> `umfpack_di_numeric(int const*, int const*, double const*, void*,
>>>>>>>>> void**,
>>>>>>>>> double const*, double*)'
>>>>>>>>> umfpack_config_test_lib.cpp:(.text+0x9c): undefined reference to
>>>>>>>>> `umfpack_di_free_symbolic(void**)'
>>>>>>>>> umfpack_config_test_lib.cpp:(.text+0xe5): undefined reference to
>>>>>>>>> `umfpack_di_solve(int, int const*, int const*, double const*,
>>>>>>>>> double*,
>>>>>>>>> double const*, void*, double const*, double*)'
>>>>>>>>> umfpack_config_test_lib.cpp:(.text+0xf0): undefined reference to
>>>>>>>>> `umfpack_di_free_numeric(void**)'
>>>>>>>>> collect2: ld returned 1 exit status
>>>>>>>>>
>>>>>>>>> Running 'ar t' on libumfpack.a indicates that it is available. Any
>>>>>>>>> hints?
>>>>>>>>>
>>>>>>>>> ilmar
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> DOLFIN-dev mailing list
>>>>>>>>> DOLFIN-dev@xxxxxxxxxx
>>>>>>>>> http://www.fenics.org/mailman/listinfo/dolfin-dev
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> DOLFIN-dev mailing list
>>>>>>>> DOLFIN-dev@xxxxxxxxxx
>>>>>>>> http://www.fenics.org/mailman/listinfo/dolfin-dev
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>> _______________________________________________
>>>>>> DOLFIN-dev mailing list
>>>>>> DOLFIN-dev@xxxxxxxxxx
>>>>>> http://www.fenics.org/mailman/listinfo/dolfin-dev
>>>>>>
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> DOLFIN-dev mailing list
>>>>> DOLFIN-dev@xxxxxxxxxx
>>>>> http://www.fenics.org/mailman/listinfo/dolfin-dev
>>>>>
>>>>>
>>>> _______________________________________________
>>>> DOLFIN-dev mailing list
>>>> DOLFIN-dev@xxxxxxxxxx
>>>> http://www.fenics.org/mailman/listinfo/dolfin-dev
>>>>
>>>>
>>>
>>>
>>>
>> _______________________________________________
>> DOLFIN-dev mailing list
>> DOLFIN-dev@xxxxxxxxxx
>> http://www.fenics.org/mailman/listinfo/dolfin-dev
>>
>
>
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/dolfin-dev
>



-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which
their experiments lead.
-- Norbert Wiener