Re: [Ekiga-devel-list] Building trunk in home 2

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

Damien Sandras wrote:
> Hi,
>
> Le dimanche 13 avril 2008 à 12:52 +0200, Eugen Dedu a écrit :
> > Hi,
> >
> > I am compiling ptlib, opal and ekiga, all from svn of yesterday.  My
> > final goal (I hope to reach it) is to build very soon (unofficial) 
> > debian packages for them.  Thanks to the wiki page and previous post 
>
> Good news !

I have just sent an email to Kilian Krause to know if he is willing to 
put them in the experimental debian distro (if I succeed to create them).

> > This comes from the file display-core.h:
> > #include <glib.h>
> >
> > //FIXME
> > #include "ptbuildopts.h"
> > #include "ptlib.h"
> >
> > 3. The same compilation error (ptlib.h not found) appears when compiling 
> > files in directories:
> > /home/dedu/softs/ekiga/lib/engine/vidinput, subdirs skel, mlogo, ptlib
> > /home/dedu/softs/ekiga/lib/engine/audioinput, subdirs skel, mlogo, ptlib
> > /home/dedu/softs/ekiga/lib/engine/audiooutput, subdirs skel, mlogo, ptlib
> >
> > As a workaround, I have added -I/home/dedu/softs/ptlib/include at the 
> > end of the line CXXFLAGS=... in the Makefile of these directories.
> >
> > 4. During linking, it uses -lopal and -lpt, but the libraries in pt and 
> > opal have other (long) names.  To cope with this, I executed:
> > snoopy:~/softs/opal/lib$ ln -s libopal_linux_x86_64_r_s.a libopal.a
> > snoopy:~/softs/ptlib/lib$ ln -s libpt_linux_x86_64_r_s.a libpt.a
>
> Are you sure you did a make install in DESTDIR ?
> It looks like you did not run it.

No, I didn't executed it.  I thought that make install just moves them 
in the corresponding directory, but now I know that I am wrong (it 
creates links too).

So I changed prefix to `pwd`/../bins and executed make install for ptlib 
and opal.  .h and .so are put inside.

However, all the compilation errors about ptlib.h remain (points 2 and 
3).  The directory for ptlib is not included in the compilation command 
line of display-core.cpp:

 g++ -DHAVE_CONFIG_H -I. -I../../../.. -I../../../../lib/gmconf 
-I../../../../lib/engine/include -I../../../../lib/engine/framework 
-I../../../../lib/engine/display/skel -I/usr/include/sigc++-2.0 
-I/usr/lib/sigc++-2.0/include -pthread -I/usr/include/glib-2.0 
-I/usr/lib/glib-2.0/include -g -O2 -Wall -Wextra -Winit-self 
-Wswitch-default -Wswitch-enum -Wstrict-aliasing=2 -Wfloat-equal 
-Wshadow -MT display-core.lo -MD -MP -MF .deps/display-core.Tpo -c 
../../../../lib/engine/display/skel/display-core.cpp  -fPIC -DPIC -o 
.libs/display-core.o

> [...]
>
> > 8. The config assistant appears, but a few seconds later the program 
> > receives seg fault.  Here is the backtrace with gdb:
> > Program received signal SIGSEGV, Segmentation fault.
> > [Switching to Thread 0x2b600e2c6120 (LWP 5105)]
> > 0x00002b6007ee0090 in strlen () from /lib/libc.so.6
> > (gdb) bt
> > #0  0x00002b6007ee0090 in strlen () from /lib/libc.so.6
> > #1  0x00000000007e1cd7 in motion_detection_cb (data=0x14ae7b0)
> >      at /usr/include/c++/4.2/bits/char_traits.h:258
> > #2  0x00002b60068c581b in ?? () from /usr/lib/libglib-2.0.so.0
> > #3  0x00002b60068c50f2 in g_main_context_dispatch () from 
> > /usr/lib/libglib-2.0.so.0
> > #4  0x00002b60068c8396 in ?? () from /usr/lib/libglib-2.0.so.0
> > #5  0x00002b60068c8657 in g_main_loop_run ()
> > from /usr/lib/libglib-2.0.so.0
> > #6  0x00002b6004bfdb63 in gtk_main ()
> > from /usr/lib/libgtk-x11-2.0.so.0
> > #7  0x00000000007e08c8 in main (argc=<value optimized out>,
> >      argv=<value optimized out>, envp=<value optimized out>) at 
> > gui/main.cpp:4488
>
> Yannick reported me that one too. That's weird.
>
> I will have a look now.

Thanks.

--
Eugen Dedu