dolfin team mailing list archive

["Dag Lindbo" <dag@xxxxxxxx>]

Thanks a lot! Is there _any_ way to not have to resdesign my code? E.g.
use libtool as in 0.6.2x (the same code works in the 0.6.2 setting)? The
example I gave i _very_ simplified (my solvers include many more forms in
many more classes). /Dag


> ok, *now* I know what the problem is.
>
> You will get the same error if you replace LSM_grad.h with the
> following code:
>
>   #ifndef __FOO_H
>   #define __FOO_H
>
>   class Foo
>   {
>   public:
>
>     int foo();
>
>   };
>
>   int Foo::foo() { return 0; }
>
>   #endif
>
> If, on the other hand, you define foo() directly in the class
> definition:
>
>   #ifndef __FOO_H
>   #define __FOO_H
>
>   class Foo
>   {
>   public:
>
>     int foo() { return 0; }
>
>   };
>
>   #endif
>
> then everything will compile. (You also need to change Class1 -->
> Class2 in Class2.cpp).
>
> I few fixes were made to FFC to get around some problems with SWIG not
> being able to handle nested classes. Some function definitions were
> then moved outside the classes and as a result we get this problem.
>
> We are working on a new specification for the code that is being
> generated by FFC (UFC - Unified Form-assembly Code). The plan is to
> support this in the next version of FFC. Then this won't be a problem.
>
> In the meantime, just include the form-file in one place, declare the
> form object and send it around to each class that needs it (if
> possible).
>
> /Anders
>
>
>
> On Mon, Oct 30, 2006 at 10:57:53AM +0100, Garth N. Wells wrote:
>>
>>
>> Anders Logg wrote:
>> > I think I found the problem. Look in your file Class2.cpp:
>> >
>> >   #include "Class1.hpp"
>> >
>> >   using namespace dolfin;
>> >
>> >   Class1::Class1()
>> >   {}
>> >
>> > Notice something wrong? :-)
>> >
>>
>> I saw this too, but is doesn't help. You can get rid of Class2
>> completely and the problem remains. The code in LSM_grad.h still gets
>> compiled into Class1.o and main.o.
>>
>> Garth
>>
>> > /Anders
>> >
>> >
>> > On Mon, Oct 30, 2006 at 10:44:09AM +0100, Garth N. Wells wrote:
>> >>
>> >> Dag Lindbo wrote:
>> >> ...
>> >>
>> >>>>> I'm no C++ boffin, but it seems to me the the linker (g++) is
>> getting
>> >>>>> confused over the fact there is code in the form headers that has
>> been
>> >>>>> compiled multiple times (once for each class that uses the
>> particular
>> >>>>> form)  . Did libtool do a better job at figuring this out? How do
>> I use
>> >>>>> libtool?
>> >>>>>
>> >>>> Can you give a stripped down example where it goes wrong?
>> >>> The attached files are _very_ simple. Just two classes (that do
>> nothing)
>> >>> and a main (that does nothing). /Dag
>> >>>
>> >> The problem seems to stem from LSM_grad.h containing definitions
>> >> and not just declarations. The definitions are compiled each time
>> they
>> >> appear. I'm not sure how to get around it. Note that if you put the
>> >> definitions for Class1 and Class2 into the header files and remove
>> >> Class1.cpp and Class2.cpp, everything works.
>> >>
>> >> Garth
>> >>
>> >>
>> >>>> Garth
>> >>>>
>> >>>>> /Dag
>> >>>>>
>> >>>>>> Garth
>> >>>>>>
>> >>>>>>> Thanks a lot!
>> >>>>>>> Dag Lindbo
>> >>>>>>>
>> >>>>>>> _______________________________________________
>> >>>>>>> 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
>