dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

I don't think libtool solves the problem (I tried). So I would think
you need make sure you don't create the same form in more than one
place for now. (Until we fix this in the next release.)

/Anders


On Mon, Oct 30, 2006 at 12:17:38PM +0100, Dag Lindbo wrote:
> 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
> >
> 
> 
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/dolfin-dev