Building from the source tarball

[djrobx]

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.

[Zaerc]

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. 

[kir]

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

[Zaerc]

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. 

[kir]

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.

[Zaerc]

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.