Author Topic: Building from the source tarball  (Read 5619 times)

Zaerc

  • Alumni
  • LinuxMCE God
  • *
  • Posts: 2256
  • Department of Redundancy Department.
    • View Profile
Building from the source tarball
« 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:

  • unpack the sources
  • change directory
  • copy original libraries from the system
  • replace "Mozilla_Plugin" with "Plug_And_Play_Plugin" in Makefile_all
  • generate a Makefile for "MessageSend" from a file already there
  • replace <-mkr_t_compile_defines-> with a more useful default value in the Makefiles
  • replace <-mkr_t_compile_libs-> with a more useful default value in the Makefiles
  • build the DCERouter and some plugins

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.

« Last Edit: September 08, 2007, 03:16:45 pm by Zaerc »
"Change is inevitable. Progress is optional."
-- Anonymous


clehmann

  • Making baby steps
  • Posts: 3
    • View Profile
Re: Building from the source tarball
« Reply #1 on: September 01, 2007, 05:33:38 pm »
Hmm, I didn't even get this far...

It fails trying to link the orbiter:
Code: newbielink:javascript:void(0); [nonactive]
/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: newbielink:javascript:void(0); [nonactive]
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: newbielink:javascript:void(0); [nonactive]
/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: newbielink:javascript:void(0); [nonactive]
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?

Zaerc

  • Alumni
  • LinuxMCE God
  • *
  • Posts: 2256
  • Department of Redundancy Department.
    • View Profile
Re: Building from the source tarball
« Reply #2 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.
« Last Edit: September 01, 2007, 08:14:03 pm by Zaerc »
"Change is inevitable. Progress is optional."
-- Anonymous


clehmann

  • Making baby steps
  • Posts: 3
    • View Profile
Re: Building from the source tarball
« Reply #3 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 :-\
« Last Edit: September 02, 2007, 01:02:33 am by clehmann »

Zaerc

  • Alumni
  • LinuxMCE God
  • *
  • Posts: 2256
  • Department of Redundancy Department.
    • View Profile
Re: Building from the source tarball
« Reply #4 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...
« Last Edit: September 02, 2007, 05:37:11 am by Zaerc »
"Change is inevitable. Progress is optional."
-- Anonymous


clehmann

  • Making baby steps
  • Posts: 3
    • View Profile
Re: Building from the source tarball
« Reply #5 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: newbielink:javascript:void(0); [nonactive]
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)                                   

Zaerc

  • Alumni
  • LinuxMCE God
  • *
  • Posts: 2256
  • Department of Redundancy Department.
    • View Profile
Re: Building from the source tarball
« Reply #6 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.
"Change is inevitable. Progress is optional."
-- Anonymous


Zaerc

  • Alumni
  • LinuxMCE God
  • *
  • Posts: 2256
  • Department of Redundancy Department.
    • View Profile
Re: Building from the source tarball
« Reply #7 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, I'm starting to think that these are not the sources used to build 1.1-0704 at all.  ???
"Change is inevitable. Progress is optional."
-- Anonymous


webpaul1

  • Veteran
  • ***
  • Posts: 140
    • View Profile
Re: Building from the source tarball
« Reply #8 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.

dopey

  • Guru
  • ****
  • Posts: 223
    • View Profile
Re: Building from the source tarball
« Reply #9 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...

Zaerc

  • Alumni
  • LinuxMCE God
  • *
  • Posts: 2256
  • Department of Redundancy Department.
    • View Profile
Re: Building from the source tarball
« Reply #10 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. 
"Change is inevitable. Progress is optional."
-- Anonymous


dopey

  • Guru
  • ****
  • Posts: 223
    • View Profile
Re: Building from the source tarball
« Reply #11 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.

Zaerc

  • Alumni
  • LinuxMCE God
  • *
  • Posts: 2256
  • Department of Redundancy Department.
    • View Profile
Re: Building from the source tarball
« Reply #12 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.

« Last Edit: September 06, 2007, 11:56:59 am by Zaerc »
"Change is inevitable. Progress is optional."
-- Anonymous


Zaerc

  • Alumni
  • LinuxMCE God
  • *
  • Posts: 2256
  • Department of Redundancy Department.
    • View Profile
Re: Building from the source tarball
« Reply #13 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)

« Last Edit: September 06, 2007, 06:16:29 pm by Zaerc »
"Change is inevitable. Progress is optional."
-- Anonymous


PeteK

  • Guru
  • ****
  • Posts: 408
    • View Profile
Re: Building from the source tarball
« Reply #14 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.