Maybe I'm not as good as I thought. Qpegps doesn't seem to be able to talk to
gpsd very well (i.e. at all).
I can nc to port 2947 and see the RAW gps stream just fine, and when I use
qpegps it starts up and connects to the daemon, but I get "GPS" in green
letters for just a few seconds, followed by "ERR" in red letters. It does it
for both localhost connections to gpsd and connections across the network (I
have a building mount GPS here at work on the network)..
This is a showstopper, obviously.
qmakespec: I don't know if I have a "good" one. I'm using the one from opie
in the linux-g++ directory. When I run qmake, it complains:
Some of the required modules (network large-config) are not available.
So, I just comment these out in qpegps.pro and qmake runs fine. Then, when I
compile, I get this:
g++ -c -pipe -Wall -W -O2 -DQT_NO_DEBUG -I/opt/opie/include
-I/opt/qt-2.3.5/include -I/opt/opie/mkspecs/linux-g++ -o mapinfo.o
/opt/opie/include/qpe/fileselector.h: In member function `void
/opt/opie/include/qpe/fileselector.h:108: `const DocLnk*
FileSelector::selected()' is private
mapinfo.cpp:217: within this context
make: *** [mapinfo.o] Error 1
I've mentioned this before. I don't know when selected() became private, but
it prevents compilation. The replacement method is
const DocLnk selectedDocument(), which I'm having a bit of trouble
implementing (poor C knowledge on my part).
Then I need to do a whole lot of dancing around the libraries and Makefile
LIBS options to get it to build. This is _probably_ just my dorked up
development enviro. Anyway, I can finally get it built and linked, but I
keep arriving back at the GPS -ERR- message in the Data Status box on the GPS
On Thursday 05 June 2003 14:27, John Gorkos spake thusly:
> Got it to compile under Familiar .7pre.
> Here's how I did it.
> I've got my development set up under /opt, so I have /opt/qt-2.3.5 and
> /opt/opie. Then I mount my Ipaq / via NFS to /mnt/nfs, and sym-link the qt
> libraries off the ipaq into the lib directory of /opt/opie and
> I'm using the 2.95.3 cross compiler from
> http://openzaurus.org/official/toolchain/cross-2.95.3-oz-1.2.tar.bz2 that's
> in /usr/local.
> I set up my devel enviro with QPEDIR and QTDIR and OPIEDIR as needed, put
> /usr/local/arm/2.95.3/bin in my path, and make the following alteration to
> the qpegps Makefile:
> LIBS = $(SUBLIBS) -Wl,-rpath,$(QTDIR)/lib:/opt/usr/lib:/opt/lib
> -L$(QPEDIR)/lib -L$(QTDIR)/lib -L/opt/lib -L/opt/usr/lib $(LIBS_EXTRA)
> -lqte -lqpe
> Finally, I change the symbolic links in the cross-compiler tree
> (/usr/local/arm/2.95.3/arm-linux/lib) to use the libc.so.6 and libdl.so.2
> on the Ipaq instead of the ones in the the cross tree. And whammo, it
> compiles and RUNS without segfaulting on my Ipaq.
> There are still a lot of "why" questions in my mind, but the bottom line is
> that this DOES work, but it seems to completely break the concept of
> complete binary compatibility between the Z and familiar. Ralf, I can
> email you a compiled executable if you'd like to try running my version on
> your Z.
> On Wednesday 04 June 2003 22:53, Ralf Haselmeier spake thusly:
> > ---------- Forwarded Message ----------
> > Here's what I've found so far:
> > "qpegps" runs fine under Familiar 0.6.1 on my iPAQ 3835, running any
> > version of Opie (from the one shipped with 0.6.1 to the .99pre
> > versions).
> > I've tracked the problem with the segfault in qpegps to the point
> > where I believe it is some form of data corruption in the switching of
> > libc libraries.
> > Basically qpegps does all the correct setup and calls Qtopia's gui
> > loop. Just after calling it there is a segfault that occurs inside of
> > glibc, the failure seems like it is the result of freeing memory that
> > is not owned.
> > Since I can't find any problem in qpegps and it works fine on the
> > desktop and with older Familiars I believe the problem is that some
> > entrypoint has changed in the newer glibc.
> > I'm currently running the same Familiar 0.7rc2 + Opie 0.99pre2 on a
> > similar iPAQ 3835. At this time I've not been able to complete a
> > pre0.7 versioned toolchain that works with Opie. It seems that the
> > jump from 2.95 to 3.2 of gcc changes all the library formats and that
> > all the QTE/QPE libraries precompiled for Opie have not been done with
> > the newer gcc.
> > I'm working on getting all the libraries required to build Qtopia for
> > a working cross compiler toolchain for Opie based Familiar pre0.7.
> > I've made it a little harder on myself by trying to solve this problem
> > for the comunity. Once I'm done I hope to have ipkg "devel" files
> > that can be used by other people wanting to cross compile for Familiar
> > (maybe usefull for OZ as well).
> > I too have had a lot occuring recently and have only been able to
> > steel a few evening hours here and there to work on it. If I'm on the
> > right track I would hope to be able to create an ipkg sometime in the
> > next week or two. If I'm on the wrong track, then I'll be starting
> > over again trying to find the problem. On the plus side I'll have
> > unstripped version of all the libraries where the segfault is
> > occuring, so debugging should be a lot more revealing of problems.
> > Robert
quidquid latine dictum sit altum viditur
(anything said in Latin sounds profound)