LinuxMCE Forums

General => Developers => Topic started by: Zaerc on August 31, 2007, 10:48:11 pm

Title: Building from the source tarball
Post by: Zaerc on August 31, 2007, 10:48:11 pm
I'm just throwing this out in case somebody may find it useful, here is what I did so far:


Code: [Select]
tar xvf  LinuxMCE_0704_Source.tar.bz2
cd LinuxMCE-1.1-SRC/src
cp -a /usr/pluto/lib/* lib/

sed -e 's/Mozilla_Plugin/Plug_And_Play_Plugin/g' -i Makefile_all
sed -e 's/\r$//' -e 's/^LDLIBS = -lpthread $/&-lhttp_fetcher/' MessageSend/Makefile.MessageSend >MessageSend/Makefile

find . -iname Makefile -exec sed -e 's/<-mkr_t_compile_defines->/-DKDE_LMCE -DDEBUG -DTHREAD_LOG -DLOG_ALL_QUERIES -I\/opt\/libxine1-pluto\/include -I\/opt\/libsdl1.2-1.2.7+1.2.8cvs20041007\/include -I\/opt\/libsdl1.2-1.2.7+1.2.8cvs20041007\/include\/SD/' -i '{}' \;
find . -iname Makefile -exec sed -e 's/<-mkr_t_compile_libs->/-L\/opt\/libxine1-pluto\/lib -L\/opt\/libsdl1.2-1.2.7+1.2.8cvs20041007\/lib/' -i '{}' \;

make -f Makefile_all 2>&1|tee make.log


This seems to build at least the basics for me.  Next you can go into the directory of what you want to build and do make clean all ("so" or "bin" can be used instead of "all" as well) there.

For example additional shared objects like the "Ruby_Generic_Serial_Device" (Generic_Serial_Device) and "VDRPlugin" could be build like this:
Code: [Select]
make clean so -C Generic_Serial_Device 2>&1|tee make-Generic_Serial_Device.log
make clean so -C VDRPlugin 2>&1|tee make-VDRPlugin.log


The resulting binaries and libraries are placed in the bin/ and lib/ directories, these can be copied to the corresponding directories under /usr/pluto/ but you might want to make a backup of those directories first. 

And that's about as far as I got for now, how about you?

-----

EDIT: corrected the directory to change into

EDIT: replaced the finds with exports as indicated by Paul.

EDIT: updated now that things appear to be working.

Title: Re: Building from the source tarball
Post by: clehmann on September 01, 2007, 05:33:38 pm
Hmm, I didn't even get this far...

It fails trying to link the orbiter:
Code: [Select]
/home/clehmann/builds/LinuxMCE-1.1-SRC/src/Orbiter/../CreateDevice/UserUtils.cpp:108: undefined reference to `db_wrapper_fetch_row(DB_RES*)'

This symbol looks like it's supposed to come from libplusto_main.so, but when I look at the symbols using nm:

Code: [Select]
clehmann@cascade:~/builds/LinuxMCE-1.1-SRC/src$ nm lib/libpluto_main.so
nm: /usr/pluto/lib/libpluto_main.so: no symbols

So I copy libpluto_main.so that just got built from pluto_main to the lib folder, and everything links just fine.

I'm trying to add support for svn mythtv, so I build the MythTV_Plugin.so by changing to the  MythTV_Plugin and doing a make so. I then copy the MythTV_Plugin.so /usr/pluto/bin and restart the DCERouter, but it won't load due to unresolved symbols:

Code: [Select]
/usr/pluto/bin/DCERouter: symbol lookup error: ./MythTV_PlugIn.so: undefined symbol: _Z20db_wrapper_fetch_rowP6DB_RES

Finally, I copy my new libpluto_main.so to /usr/pluto/lib and try and start the DCERouter again, but it just segfaults.
Code: [Select]
OG: ========== NEW LOG SECTION ==========
1       09/01/07 10:17:17       DCERouter (server)      Starting... 10
1       09/01/07 10:17:17       DCERouter (server)      Starting... 10
LOG: Sat Sep  1 10:17:17 CDT 2007 Starting
/usr/pluto/bin/Spawn_DCERouter.sh: line 69: 21171 Segmentation fault      (core dumped) /usr/pluto/bin/UpdateEntArea -h localhost > >(tee -a /var/log/pluto/updateea.log)

Any ideas?
Title: Re: Building from the source tarball
Post by: Zaerc on September 01, 2007, 06:51:46 pm
Strange, I don't recall having to move libraries around, maybe I forgot a step.  Did you copy the libraries from /usr/pluto/lib over first?

My lib/libpluto_main.so has no symbols either, so I guess they get stripped during the build.  When examining your example a little closer I notice:

Quote
clehmann@cascade:~/builds/LinuxMCE-1.1-SRC/src$ nm lib/libpluto_main.so
nm: /usr/pluto/lib/libpluto_main.so: no symbols

That seems very strange to me unless you have linked to the lib directory instead of copying it.

It was my original intention to look at those mythtv wrappers as well, so I'll try what you did and see what happens here.

EDIT:

After doing the make in the top level directory, MythTV_PlugIn.so is already there in the bin/ directory.  I'll see what happens when I copy it over the existing one lateron.
Title: Re: Building from the source tarball
Post by: clehmann on September 02, 2007, 01:00:47 am
Strange, I don't recall having to move libraries around, maybe I forgot a step.  Did you copy the libraries from /usr/pluto/lib over first?
Ok, i tried it again with a fresh source tree and everything built ok.  I was working with a source tree that I manually built a few parts of (basically manually following the script in the Ubuntu_Helpers folder), so I'm not sure what happened there.

I still can't load the MythTV_plugin.so though (neither the one from the bin dir or the MythTV_Plugin folder), DCERouter quits with the same undefined symbol. 

That seems very strange to me unless you have linked to the lib directory instead of copying it.
Yeah sorry,  I copied the nm and just changed that text to try and avoid confusion, but neither of the files has any symbols.


It was my original intention to look at those mythtv wrappers as well, so I'll try what you did and see what happens here.

Let me know if you can actually get it to run your .so, I'm pretty sure I've got the changes to make it work with the new protocol (not that they're that hard to figure out) I just can't test it :-\
Title: Re: Building from the source tarball
Post by: Zaerc on September 02, 2007, 04:51:24 am
Seems like I'm getting just about the same results as you, in the end I just copied the whole contents of the bin/ and lib/ directories over to /usr/pluto/... again, still no luck:

Code: [Select]
# tail -f /var/log/pluto/DCERouter.log
2       09/02/07 03:04:42       /usr/pluto/bin/Spawn_DCERouter.sh  (server)    Writing Version: 2.0.0.44
1       09/02/07 03:04:42       /usr/pluto/bin/Spawn_DCERouter.sh (server)     Starting DCERouter
========== NEW LOG SECTION ==========
1       09/02/07 03:04:42       DCERouter (server)      Starting... 1
Sun Sep  2 03:04:42 CEST 2007 Starting
Return code: 139
3       09/02/07 03:04:42       DCERouter (server)      Device died... count=1/200 dev=DCERouter
Sun Sep  2 03:04:42 CEST 2007 died

Code: [Select]
# screen -r 18073.DCERouter
---------------

/usr/pluto/bin/Spawn_DCERouter.sh: line 69:  9976 Segmentation fault      (core dumped) /usr/pluto/bin/Spawn_Wrapper.sh /usr/pluto/bin/DCERouter -h localhost -l "$LogFile"
LOG: Return code: 139
3       09/02/07 03:08:31       DCERouter (server)      Device died... count=42/200 dev=DCERouter
3       09/02/07 03:08:31       DCERouter (server)      Device died... count=42/200 dev=DCERouter
LOG: Sun Sep  2 03:08:31 CEST 2007 died

I can't find the core file, and running it from gdb doesn't tell me much either:
Code: [Select]
# gdb /usr/pluto/bin/DCERouter
...
(gdb) run -h localhost -l /tmp/DCERouter.log
Starting program: /usr/pluto/bin/DCERouter -h localhost -l /tmp/DCERouter.log
[Thread debugging using libthread_db enabled]
[New Thread -1227815216 (LWP 13550)]
Copyright (C) 2004 Pluto, Inc., a Florida Corporation
...
See the Pluto Public License for more details.
---------------

[New Thread -1227818096 (LWP 13582)]
[New Thread -1236210800 (LWP 13583)]
[Thread -1236210800 (LWP 13583) exited]
[New Thread -1236210800 (LWP 13586)]
[New Thread -1244603504 (LWP 13587)]
[New Thread -1252996208 (LWP 13588)]
[New Thread -1261388912 (LWP 13589)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1227815216 (LWP 13550)]
0x080d651d in DB_Wrapper::Socket::send (this=0x2000, tlv=@0xbf94f6c4)
    at ../db_wrapper/Socket.cpp:72
72              write(m_sock,  buf, length);
(gdb) c
Continuing.

Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.
(gdb)

So I guess we're stuck already :-[, time to do some more digging around...

EDIT:

I found the core files:
Code: [Select]
# gdb /usr/pluto/bin/DCERouter /home/coredump/1/core_DCERouter_1188696448_11.13550
...
Core was generated by `/usr/pluto/bin/DCERouter -h localhost -l /tmp/DCERouter.log'.
Program terminated with signal 11, Segmentation fault.
#0  0x080d651d in ClientSocket (this=0x2000, unix_socket=@0xbf94f6c4)
    at ../db_wrapper/ClientSocket.cpp:18
18            throw SocketException ( "Could not bind to port." );
(gdb) bt
#0  0x080d651d in ClientSocket (this=0x2000, unix_socket=@0xbf94f6c4)
    at ../db_wrapper/ClientSocket.cpp:18
#1  0x080d5a9c in std::_Rb_tree<std::string, std::pair<std::string const, std::string>, std::_Select1st<std::pair<std::string const, std::string> >, std::less<std::string>, std::allocator<std::pair<std::string const, std::string> > >::insert_unique (this=0xbf94f6c4, __position={_M_node = 0x80d9684}, __v=@0x80e64c0)
    at /usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../include/c++/4.1.2/bits/stl_tree.h:949
#2  0x080d3ecb in DCE::MessageXML::GenerateXML (this=0x80eaca0, bAddHeaders=15)
    at ../DCE/MessageXML.cpp:196
#3  0x080d528a in std::_Rb_tree<long, std::pair<long const, unsigned long>, std::_Select1st<std::pair<long const, unsigned long> >, std::less<long>, std::allocator<std::pair<long const, unsigned long> > >::clear (this=0x80eaca0)
    at /usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../include/c++/4.1.2/bits/stl_tree.h:693
#4  0x080cb793 in std::__uninitialized_copy_aux<__gnu_cxx::__normal_iterator<DCE::CommandGroup_Command**, std::vector<DCE::CommandGroup_Command*, std::allocator<DCE::CommandGroup_Command*> > >, __gnu_cxx::__normal_iterator<DCE::CommandGroup_Command**, std::vector<DCE::CommandGroup_Command*, std::allocator<DCE::CommandGroup_Command*> > > > (__first={_M_current = 0xbf94fab8}, __last=
      {_M_current = 0x0}, __result={_M_current = 0x0})
    at /usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../include/c++/4.1.2/bits/stl_uninitialized.h:74
#5  0x0807feba in DCE::Router::Configure (this=0x80e91b8) at DCERouter.cpp:2433
#6  0x08098ad0 in Router (this=0x80e91b8, PK_Device=0, PK_Installation=0,
    BasePath=@0xbf95005c, DBHost=@0xbf950060, DBUser=@0xbf950064,
    DBPassword=@0xbf950068, DBName=@0xbf95006c, DBPort=3306, ListenPort=3450)
    at DCERouter.cpp:150
#7  0x0807c4a2 in __static_initialization_and_destruction_0 (
    __initialize_p=-1226141708, __priority=-1080754000)
    at /usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../include/c++/4.1.2/iostream:76
#8  0xb6d81ebc in ?? ()
#9  0xb7feece0 in ?? ()
#10 0x080d67b0 in DB_Wrapper::Socket::connect (this=0x807b886,
    unix_socket=@0x5) at ../db_wrapper/Socket.cpp:121
#11 0x0807a7b1 in std::vector<CriteriaNesting*, std::allocator<CriteriaNesting*> >::begin (this=Cannot access memory at address 0xc
)
    at /usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../include/c++/4.1.2/bits/stl_vector.h:332
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) quit

Seems like it has a bit of trouble with networking...
Title: Re: Building from the source tarball
Post by: clehmann on September 02, 2007, 04:41:47 pm
Cool, thanks, glad to see it's not just me.

I'm seeing a bit of a different backtrace than you:

Code: [Select]
clehmann@cascade:~/builds/LinuxMCE-1.1-SRC/src/DCERouter$ sudo gdb /usr/pluto/bin/DCERouter
GNU gdb 6.6-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
(gdb) r
Starting program: /usr/pluto/bin/DCERouter
[Thread debugging using libthread_db enabled]
[New Thread -1227950384 (LWP 25467)]
Copyright (C) 2004 Pluto, Inc., a Florida Corporation
www.plutohome.com
Phone: +1 (877) 758-8648
This program is distributed according to the terms of the Pluto Public License, available at:
http://plutohome.com/index.php?section=public_license
This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY;
without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
See the Pluto Public License for more details.
---------------

[New Thread -1227953264 (LWP 25473)]
[Thread -1227953264 (LWP 25473) exited]
[New Thread -1227953264 (LWP 25474)]
[New Thread -1236345968 (LWP 25477)]
[New Thread -1244738672 (LWP 25478)]
[New Thread -1253131376 (LWP 25479)]
[New Thread -1261524080 (LWP 25480)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1227950384 (LWP 25467)]
0x00000018 in ?? ()
(gdb) bt
#0  0x00000018 in ?? ()
#1  0xb7d08bb7 in mysql_send_query () from /usr/lib/libmysqlclient_r.so.15
#2  0xb7d08c50 in mysql_real_query () from /usr/lib/libmysqlclient_r.so.15
#3  0xb7ce08c5 in mysql_query () from /usr/lib/libmysqlclient_r.so.15
#4  0x080cd62e in DBHelper::threaded_db_wrapper_query (this=0x80ff4e0, query=@0xbfb08e58, bIgnoreErrors=false, Retry=false) at ../PlutoUtils/DBHelper.h:211
#5  0x0807fbd2 in DCE::Router::Configure (this=0x80e9130) at DCERouter.cpp:2419
#6  0x0809a6d6 in Router (this=0x80e9130, PK_Device=0, PK_Installation=0, BasePath=@0xbfb093fc, DBHost=@0xbfb09400, DBUser=@0xbfb09404, DBPassword=@0xbfb09408, DBName=@0xbfb0940c, DBPort=3306, ListenPort=3450) at DCERouter.cpp:282
#7  0x0807be82 in main (argc=1, argv=0xbfb094d4) at Main.cpp:184
(gdb)                                   
Title: Re: Building from the source tarball
Post by: Zaerc on September 02, 2007, 05:16:57 pm
Well you were running the program without arguments in the debugger, you could try: "r -h localhost -l /tmp/DCERouter.log" instead, or even better use a core file as produced in the real situation.  When using a core file, it's a good idea to go into LinuxMCE-1.1-SRC/src/DCERouter and do it from there so that the debugger can find the source files.
Title: Re: Building from the source tarball
Post by: Zaerc on September 02, 2007, 07:24:45 pm
I have been digging a little further, and tried to build the "mce-launcher", which failed because it tries to link to Gnome libraries.  Combined with this problem: Compiling LinuxMCE version of MythTV (http://forum.linuxmce.org/index.php?topic=2249.0), I'm starting to think that these are not the sources used to build 1.1-0704 at all.  ???
Title: Re: Building from the source tarball
Post by: webpaul1 on September 03, 2007, 10:17:18 am
I'll look into more.  But in case this helps, what I do to compile is untar the file to /home/source.  Then cp /usr/pluto/lib/* /home/source/src/lib/

Then: export SNR_CPPFLAGS = "-DKDE_LMCE -DDEBUG -DTHREAD_LOG -DLOG_ALL_QUERIES -I/opt/libxine1-pluto/include -I/opt/libsdl1.2-1.2.7+1.2.8cvs20041007/include -I/opt/libsdl1.2-1.2.7+1.2.8cvs20041007/include/SD"
export SNR_LDFLAGS = "-L/opt/libxine1-pluto/lib -L/opt/libsdl1.2-1.2.7+1.2.8cvs20041007/lib"

then cd to one of the binary directories, like cd /home/source/src/App_Server, and run: make clean bin
or cd to one of the plugins, like cd /home/source/src/Media_Plugin, and run: make clean so

Then I edit the files locally and recompile as needed.  To test it, I either (a) copy the output to /usr/pluto/bin (backup the original file first), (b) make a symlinc in /usr/pluto/bin point ot my output directory, or (c) kill the screen session that's running the device and run it manually from the source directory with: [binary name] -d [device id] -r dcerouter

I'll work on coming up with a clean set of instructions to build all the code and packages from that tar ball.  It is the correct set of sources afaik.
Title: Re: Building from the source tarball
Post by: dopey on September 03, 2007, 11:27:02 am
But in case this helps, what I do to compile is untar the file to /home/source.  Then cp /usr/pluto/lib/* /home/source/src/lib/

Hmm, so as it stands we still need the the Pluto libraries pre-compiled? In other words, there is no way to completely compile LinuxMCE from scratch?

It is the correct set of sources afaik.

This is really confusing with my problem that Zaerc sited. As I mentioned in the post, I confirmed that I did compile and run the MythTV from that source tar ball... Are there any patches that need to be applied to MythTV beforehand, or do you not use that source for MythTV for the MythTV packages? I've been going over it many times in my head and I can't think of anything that I could have missed...
Title: Re: Building from the source tarball
Post by: Zaerc on September 03, 2007, 12:44:53 pm
Well, nobody said it would be easy... ;)

Thanks for the pointers Paul, much appreciated.  Seems those exports make my find/sed commands unnecessary.  I'll update the top of this thread accordingly when I'm done messing around.

dopey: I think in the end that all the libraries will be rebuild, so using the existing libraries temporarily is probably a bootstrap to avoid some dependency conflicts. 
Title: Re: Building from the source tarball
Post by: dopey on September 04, 2007, 03:28:46 am
Yes, that would work for x86 builds, but it would make it impossible to get it to work on other platforms. Of course I know more work would likely need to be done to do that... especially the PS3 and other big endian platforms...

I want to be clear. I'm in no way complaining, just trying to get a feel for the way thing currently stand.
Title: Re: Building from the source tarball
Post by: Zaerc on September 04, 2007, 03:39:30 pm
Well, I'd be happy to get it to build on x86 for starters, sorting out all the build dependencies and building everything in the right order is step 2 as far as I'm concerned.

The logs are only slightly different this time, here they are for completeness:
Code: [Select]
# tail -f /var/log/pluto/DCERouter.log
2       09/04/07 14:16:07       /usr/pluto/bin/Spawn_DCERouter.sh  (server)    Writing Version: 2.0.0.44
1       09/04/07 14:16:07       /usr/pluto/bin/Spawn_DCERouter.sh (server)     Starting DCERouter
========== NEW LOG SECTION ==========
1       09/04/07 14:16:07       DCERouter (server)      Starting... 1
Tue Sep  4 14:16:07 CEST 2007 Starting
10      09/04/07 14:16:08.666           Running as device: 2 installation: 666 using path: /usr/pluto/ <0xb6c5e6d0>
10      09/04/07 14:16:08.678           AlarmManager::AlarmManager 0x81033c8 <0xb6c5e6d0>
Return code: 139
3       09/04/07 14:16:08       DCERouter (server)      Device died... count=1/200 dev=DCERouter
Tue Sep  4 14:16:08 CEST 2007 died

Code: [Select]
# screen -r 24292
LOG: Tue Sep  4 14:24:06 CEST 2007 Starting
Copyright (C) 2004 Pluto, Inc., a Florida Corporation
...
See the Pluto Public License for more details.
---------------

/usr/pluto/bin/Spawn_DCERouter.sh: line 69:  3640 Segmentation fault      (core dumped) /usr/pluto/bin/Spawn_Wrapper.sh /usr/pluto/bin/DCERouter -h localhost -l "$LogFile"
LOG: Return code: 139
3       09/04/07 14:24:06       DCERouter (server)      Device died... count=88/200 dev=DCERouter
3       09/04/07 14:24:06       DCERouter (server)      Device died... count=88/200 dev=DCERouter
LOG: Tue Sep  4 14:24:06 CEST 2007 died

Code: [Select]
# gdb DCERouter /home/coredump/1/core_DCERouter_1188908723_11.10086
...
Core was generated by `/usr/pluto/bin/DCERouter -h localhost -l /var/log/pluto/DCERouter.log'.
Program terminated with signal 11, Segmentation fault.
#0  0x080d8ff5 in DB_Wrapper::Socket::send (this=0x2000, tlv=@0xbfa93fa4)
    at ../db_wrapper/Socket.cpp:72
72              write(m_sock,  buf, length);
(gdb) bt
#0  0x080d8ff5 in DB_Wrapper::Socket::send (this=0x2000, tlv=@0xbfa93fa4)
    at ../db_wrapper/Socket.cpp:72
#1  0x080d8574 in DB_Wrapper::ClientSocket::send (this=0x2000, tlv=@0xbfa93fa4)
    at ../db_wrapper/ClientSocket.cpp:26
#2  0x080d69a3 in DB_LINK::send_tlv (this=0x80edd40, tlv=@0xbfa93fa4)
    at ../db_wrapper/db_wrapper.cpp:123
#3  0x080d7d62 in db_wrapper_error (db_link=0x80edd40)
    at ../db_wrapper/db_wrapper.cpp:226
#4  0x080cdd92 in DBHelper::threaded_db_wrapper_query (this=0x80ed500,
    query=@0xbfa943c8, bIgnoreErrors=false, Retry=false)
    at ../PlutoUtils/DBHelper.h:216
#5  0x080802e2 in DCE::Router::Configure (this=0x80ec1b8) at DCERouter.cpp:2419
#6  0x0809add6 in Router (this=0x80ec1b8, PK_Device=0, PK_Installation=0,
    BasePath=@0xbfa9496c, DBHost=@0xbfa94970, DBUser=@0xbfa94974,
    DBPassword=@0xbfa94978, DBName=@0xbfa9497c, DBPort=3306, ListenPort=3450)
    at DCERouter.cpp:282
#7  0x0807c592 in main (argc=5, argv=0xbfa94a44) at Main.cpp:184
(gdb) quit

Looks like it gets a little further now but still having network problems in the same corner.  I wonder what I'm doing wrong here, anyway time for some more digging lateron...

BTW, I think I was looking in the wrong directory for the launch-manager, should of been "src/lmce_launch_manager/" instead of "src/mce-launcher/". :P

EDIT:

Managed to build "MessageSend" as well, instead of sedding it out of the top level makefile (I had to install "http_fetcher-1.1.0" from source as well):
Code: [Select]
sed -e 's/\r$//' -e 's/^LDLIBS = -lpthread $/&-lhttp_fetcher/' MessageSend/Makefile.MessageSend >MessageSend/Makefile

Not that it made any difference as far as I can tell.

Looking at the source now, but I don't really see anything out of the ordinary so I guess I have to set a breakpoint and see how the parameters are filled.  It's pretty desperate but I don't have any other ideas at the moment.

Title: Re: Building from the source tarball
Post by: Zaerc on September 06, 2007, 01:10:14 pm
Here is the output of my latest debugging session (I removed a lot of uninteresting lines), using a breakpoint to examine the variables:
Code: [Select]
# gdb DCERouter
(gdb) break ../db_wrapper/Socket.cpp:72
(gdb) run -h localhost -l /tmp/DCERouter.log
(gdb) print buf
$1 = 0x80ecbe8 "\004"
(gdb) print length
$2 = 15
(gdb) print buf[0]
$3 = 4 '\004'
(gdb) print buf[1]
$4 = 0 '\0'
(gdb) print buf[2]
$5 = 0 '\0'
(gdb) print buf[3]
$6 = 0 '\0'
(gdb) print buf[4]
$7 = 7 '\a'
(gdb) print buf[5]
$8 = 0 '\0'
(gdb) print buf[6]
$9 = 0 '\0'
(gdb) print buf[7]
$10 = 0 '\0'
(gdb) print buf[8]
$11 = 80 'P'
(gdb) print buf[9]
$12 = 65 'A'
(gdb) print buf[10]
$13 = 89 'Y'
(gdb) print buf[11]
$14 = 76 'L'
(gdb) print buf[12]
$15 = 79 'O'
(gdb) print buf[13]
$16 = 65 'A'
(gdb) print buf[14]
$17 = 68 'D'
(gdb) print buf[15]
$18 = 69 'E'
(gdb) print buf[16]
$19 = 0 '\0'
(gdb) print m_sock
Cannot access memory at address 0x2000
(gdb) print tlv.type
$20 = TLV::typeFunction_Error
(gdb) print tlv.length
$21 = 7
(gdb) print tlv.value
$22 = 0x8103ad0 "PAYLOAD�\020"
(gdb) step

Program received signal SIGSEGV, Segmentation fault.
0x080d8ff5 in DB_Wrapper::Socket::send (this=0x2000, tlv=@0xbfae7ec4)
    at ../db_wrapper/Socket.cpp:72
72              write(m_sock,  buf, length);
(gdb) continue
Continuing.

Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.
(gdb) quit

This part seems to be the problem I think:
(gdb) print m_sock
Cannot access memory at address 0x2000

I'm guessing it's not linked together properly, then again I haven't programmed c++ in ages, and hardly ever needed to use the debugger...


EDIT:

Eureka!  Turns out a homebrew DCERouter doesn't like the original plugins (and vice versa).  Now I just need to retrace my steps so I can update the top of the thread. 8)

Title: Re: Building from the source tarball
Post by: PeteK on September 10, 2007, 06:14:23 am
Just wanted to say thanks for digging into this and posting it Zaerc.  This is really helping me get moving on the Insteon stuff.  I know it's a pain to post every little thing (and you're certainly one to point that out  ;) ) but LMCE seems to be getting on its feet as a multi-developer project, slowly.  You're definitely a big part of that.

 
Title: Re: Building from the source tarball
Post by: djrobx on September 10, 2007, 09:02:51 am
Just wanted to add to this thread with a small issue I ran into trying to add a DCE device.  When I did GenDCE, it made me my new template, but I could not compile the DCE library because some new commands had been added to the database (I'm assuming post 0704, my machine downloaded an update) that were not in pluto_main.  The solution was to install sql2cpp and run that.   That causes it to recreate the headers in pluto_main.


Title: Re: Building from the source tarball
Post by: Zaerc on October 22, 2007, 05:38:04 am
Well it's been a long day, but I've managed to build the DCERouter and plugins from scratch.  So it should be possible to compile the tarball without copying the existing libraries over first. 

Whenever the building stopped I just ran make in the directory of the library that failed to link, maybe they can be added to the makefile (or be built in advance):
Code: [Select]
make -C pluto_telecom
make -C Disk_Drive_Functions
make -C MessageTranslation
make -C SDL_Helpers
make -C mysql_wrapper

For some reason I also needed to make a minor adjustment to one of the files to avoid some linker trouble:
Code: [Select]
patch -Np1 <<"EOF"
--- src/Xine_Player/JpegEncoderDecoder.cpp.orig 2007-07-30 16:47:06.000000000 +0200
+++ src/Xine_Player/JpegEncoderDecoder.cpp      2007-10-22 01:40:31.000000000 +0200
@@ -29,7 +29,9 @@
 #include <stdlib.h>
 #include <stdio.h>
 
+extern "C" {
 #include <jpeglib.h>
+}
 
 #include <string.h>
 
EOF

I've build them on a "clean" system which is roughly based on LFS-6.2, it has well over 600 software packages installed from the source.  So I can't be to specific about the external dependencies just yet, but I can always list them all in case anyone is interested.  I did had to add a few missing packages (which had I never needed before) and I probably need more to get things like Asterisk etcetera off the ground.  The environment I built on also has no /opt/libsdl1.2-1.2.7+1.2.8cvs20041007  and /opt/libxine1-pluto directories but more recent versions of sdl and xine-lib installed.

All in all it went smoother then I expected so I'm curious to see what things broke.  That is after I set up a (minimal) database of course:
Code: [Select]
# /usr/pluto/bin/DCERouter -h localhost -l /tmp/DCERouter.log
Copyright (C) 2004 Pluto, Inc., a Florida Corporation
www.plutohome.com
Phone: +1 (877) 758-8648
This program is distributed according to the terms of the Pluto Public License, available at:
http://plutohome.com/index.php?section=public_license
This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY;
without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
See the Pluto Public License for more details.
---------------

Cannot perform query: [select `Device`.* from Device where FK_DeviceTemplate=1] Failed to get error message
Sorry...   I cannot figure out what my device ID is automatically.  To do this there must be only
1 record in the database for a device with the device template of 1 (DCE Router).  There are 0
You will need to specify the device id or the installation id on the command line.

So far so good, I got a lot further then I expected when I started out this afternoon.  :)


Title: Re: Building from the source tarball
Post by: kir on October 23, 2007, 08:40:33 am
Can you please show me the following output of your DCERouter Makefile grep:
grep FLAGS Makefile

I just want to confirm if you have them right, the part that related to db access :)
Title: Re: Building from the source tarball
Post by: Zaerc on October 23, 2007, 04:38:51 pm
Can you please show me the following output of your DCERouter Makefile grep:
grep FLAGS Makefile

I just want to confirm if you have them right, the part that related to db access :)

Sure no problem, I haven't made any modifications to it other then the SNR-find/sed commands listed in the top of this thread:
Code: [Select]
# grep FLAGS DCERouter/Makefile
SNR_CPPFLAGS ?= -DKDE_LMCE -DDEBUG -DTHREAD_LOG -DLOG_ALL_QUERIES -I/opt/libxine1-pluto/include -I/opt/libsdl1.2-1.2.7+1.2.8cvs20041007/include -I/opt/libsdl1.2-1.2.7+1.2.8cvs20041007/include/SD
CXXFLAGS = -Wall -ggdb3 -DxAUDIDEMO -fmessage-length=0
CPPFLAGS = -I$(ROOT)/ -I$(ROOT)/DCE -D_REENTRANT -D_GNU_SOURCE $(SNR_CPPFLAGS) -DUSE_LZO_DATAGRID -I/usr/include/libxml2/
LDFLAGS = -L$(ROOT)/lib -lxml2
CPPFLAGS += -I/usr/include/mysql
LDFLAGS += -lmysqlclient_r
CPPFLAGS += -DUSE_MYSQL_WRAPPER
        $(CXX) -o $@ $(call cpath,$(sources:.cpp=.o)) $(LDFLAGS) $(LDLIBS)

The machine I'm building on also doubles as a diskless media director (when booted off the network), and I managed to reconfigure the actual core to use my home-brew DCERouter instead.  Configured the home-brew DCERouter to use the database on the actual core and it seems to be working fine as a drop in replacement.

Next I would like to try and set up a (minimal) database and get the pluto-admin site going.  Unfortunately I'm not that familiar with PHP (or adodb) and I have yet to figure out where to set/change the database settings (host/user/pass/db) of the web-admin.  It sure would be nice having a working skeleton to graft some muscles and organs onto. 


Title: Re: Building from the source tarball
Post by: kir on October 23, 2007, 05:36:49 pm
I think you should edit Makefile and either exclude or comment flags CPPFLAGS += -DUSE_MYSQL_WRAPPER  --- the mysql_wrapper shouldn't be used. Probably your DB access issue comes from this flag. The same is correct for any module you are building.
Title: Re: Building from the source tarball
Post by: Zaerc on October 23, 2007, 07:58:16 pm
Thanks for the suggestion, but the problem was more that there is no filled database on the local machine to access, sorry if I wasn't clear on that.  It seems to work fine when pointed at the existing DB on the actual core (as a drop-in replacement for the core's DCERouter with some additional reconfiguration).

I did a quick search for USE_MYSQL_WRAPPER, and it looks like that define is only actually used in db_wrapper.h:
Code: [Select]
# find . -name \*.cpp -o -name \*.h -exec grep 'USE_MYSQL_WRAPPER' '{}' /dev/null ';'
./db_wrapper/db_wrapper.h:#ifdef USE_MYSQL_WRAPPER
./db_wrapper/db_wrapper.h:#else // USE_MYSQL_WRAPPER
./db_wrapper/db_wrapper.h:#endif        // USE_MYSQL_WRAPPER

I'll keep it in mind if I run into other DB connection trouble.  At the moment I'm more looking into setting up a new minimal DB (and hopefully getting the web-admin going).  I'll prolly end up using a DB backup of a clean install and removing the (root) password from the local database server, but any pointers would be greatly apreciated.