[gcompris-devel] how to use libgnomecanvas and libart in gcompris

[Bruno Coudoin]

Le mardi 25 septembre 2007 à 22:37 +0200, Patrick GOLDBRONN a écrit :
> Second test : perhaps a limitation with attachment ?
> 
> Bruno Coudoin a écrit :
> > Le dimanche 23 septembre 2007 à 21:31 +0200, Patrick GOLDBRONN a écrit :
> >> Hi,
> >>
> >> When I compile gcompris I get some undefined symbol when gcompris load 
> >> libpython.so (from libgnomecanvas and libart)
> >>
> >> To solve, I added ../libibgnomecanvas/libgnomecanvas-2.a and 
> >> ../libart_lgpl/libart_lgpl_2.a in libpython_la_LIBADD in 
> >> src/board/Makefile.am
> >>
> >> I don't know if it is right or if I did another mistake.
> > 
> > I had the same and fixed these in the gcomprixo branch this week end. I
> > just ported my hack back in trunk. Please have a test.
> > 
> > Your fix proposal makes sense but I am not sure it's the good way
> > because we would link staticaly libgnomecanvas with gcompris binary and
> > the libpython binding. That probably works but it's strange.
> 
> Why do that ? dynamic link is for that, no ?

True, but the point was not to link with the libgnomecanvas but our one
instead.

> > I made a hack to force missing symbols to be included in gcompris core.
> > Their is probably a better way but at least, we don't have the code
> > twice. If somebody understand the issue, a clean solution is welcome.
> > 
> > What happens is that we compile statically gcompris and libgnomecanvas
> > but some unused symbols are stripped. But our python binding needs them
> > and we fail to dlopen it.
> 
> Well, when you had a static library, linker takes all symbols it needs
> in it, so (I don't think it takes all). I suppose it works because all
> activities, in C and python, use the same symbols.
> 
> I have change makefile in src to use dynamic link (with libgnomecanvas
> and libart_lgpl). Libtool and automake do that fine. the result gcompris
> executable and libpython.so are dynamicaly linked to this library with
> rpath option, so they use the rigth ones, not another version that could
> be install some where else.
> 
> I have briefly test all activity which seem work :-)

Your proposal makes sense. I don't see where are located this dynamic
library at runtime. Isn't there a risk of confusion with the real one at
runtime.

> My Makefile are joined in tar ball, if you want to test.
> 
> I remove $(top_builddir)/intl, an old directory ?

Yes probably.

> I have also a question : what is libgnomecanvas_2_la_headers in
> src/libgnomecanvas/Makefile.am ? If you want to install header, the
> simpliest is to add this file into libgnomecanvas_2_la_SOURCES, or in
> include_HEADERS (same for other Makefile.am). To build a distribution
> (make dist), headers files are so automaticaly added.

Well it comes from the real libgnomecanvas code. In our case, we don't
want to distribute headers at all.

> I'd like to have a fonctional 'make dist', are you interested ? I could
> try to do it.

What do you mean, we already have one. But if there are missing things
or mistakes, sure I am interested to fix them with your help.

> Another remark (and I stop her ;-) ), INCLUDES is an older variable,
> prefer AM_CPPFLAGS (for pre processing) and AM_CFLAGS for C compilation
> (as CXXFLAGS for C++ and FFLAGS for fortran compilation)

True, need to be fixed.


-- 
Bruno Coudoin
http://gcompris.net Free educational software for kids
http://toulibre.org Logiciel Libre à Toulouse