Re: [Ekiga-devel-list] Build failure on lucid + experimental + sid

[Eugen Dedu <Eugen Dedu pu-pm univ-fcomte fr>]

On 24/04/10 23:42, C.J. Adams-Collier wrote:
> On Sat, 2010-04-24 at 08:58 +0200, Eugen Dedu wrote:
> > C.J. Adams-Collier wrote:
> > > On Fri, 2010-04-23 at 18:08 +0200, Eugen Dedu wrote:
> > > > The safest solution is that I find out what -l flags exactly are needed
> > > > for ekiga.  They should be used anyway, sooner or later.  Could you
> > > > please make a patch?
> > >
> > > Sure.  Where should I put those -l arguments?  debian/rules?
> >
> > No.  In ekiga code source.  The best is to execute make until the link
> > error.  Afterwards, re-execute the same link command, adding the correct
> > -l command, and see if it is better.  You can also see what library has
> > the symbols not found (man symbol, or look to Internet).
>
> That's a fun idea, but when I run make, it doesn't show the command used
> to do the linking, it just shows:
>
>
>    CXXLD  libekiga.la
> .libs/gmwindow.o: In function `gdk_wmspec_change_state':
> /usr/src/git/gnome/ekiga/lib/../lib/gui/gmwindow.c:698: undefined reference to `XSendEvent'
>
> I'll check configure.ac to see if I can get it to be a bit more
> verbose... ooh!
>
> $ grep long configure.ac
> dnl use "make V=1" if you want to see the long awful lines
>
> looks like we're missing -lX11 -lXext.  These should get added if the
> --enable-shm argument is passed to the configure script.  I've modified
> debian/rules to add that argument to the confflags list.
>
> The configure.ac code doesn't actually add -lXext (or -lX11) to the libs
> list, though, so I've patched configure.ac accordingly.  It's probably
> not the right way to do it, but it gets a bit farther.
>
> Not quite done yet... going to do some more now.

I have modified it and committed, thank you very much!

http://git.gnome.org/browse/ekiga/commit/?h=gnome-2-26&id=17f26fbe3
http://git.gnome.org/browse/ekiga/commit/?id=b5d1d739172

> > > > > Also, I see that you are listed in the uploaders of the
> > > > > debian/control.in file.  I'm making slight modifications to the debian/
> > > > > directory as I try to get the gnome git version package to build.  Is
> > > > > there a list I should send patches to for review?  I've attached the
> > > > > diff in its current (unworking) state.
> > > > Thanks for the help.
> > >
> > > My pleasure ;)
> > >
> > > > If you wish master/trunk, you could use the diff.gz from
> > > > http://snapshots.ekiga.net/snapshots/debian/, which use exactly
> > > > master/trunk for ptlib, opal and ekiga, and uses -snapshot package
> > > > names.  Or you could use the snapshots, even if a bit old.  Please tell
> > > > us if you wish to help and what.
> > >
> > > Sounds good.  I tried to build those, but I think they're slightly out
> > > of sync.  Pre-built .debs will be easier to manage ;)
> > >
> > > > But master/trunk is not stable at the moment, so it is not a good idea
> > > > to push it into debian (even experimental).
> > >
> > > Understood.
> > >
> > > > Finally, could you explain the changes in rules (I do not see any
> > > > usefulness)?
> > >
> > > I wanted to be able to configure the source tree so that I could
> > > manually run make and get more verbose logs.  They're not terribly
> > > useful if nobody will need to perform just the configure stage.