<p dir="ltr">Hi Dirk, </p>
<p dir="ltr">On 11 Jul 2015 11:03 pm, "Dirk Hohndel" <<a href="mailto:dirk@hohndel.org">dirk@hohndel.org</a>> wrote:<br>
><br>
> On Sat, Jul 11, 2015 at 05:11:31PM +1000, Rick Walsh wrote:<br>
> > >><br>
> > >> Umm. Err. What? If the startup used to get you into the infinite recursion<br>
> > >> (that's what happens in the "return path("bimaps/empty.png");"...)<br>
> > >><br>
> > >> Oh, never mind. I bet your libssrfmarble isn't compiled with debugging<br>
> > >> enabled, so the qDebug never gets printed for you.<br>
> > >><br>
> > >> Can you replace the qDebug with<br>
> > >><br>
> > >> fprintf(stderr, "fullpath %s results in %s\n", qPrintable(fullpath),<br>
> > >> qPrintable(result));<br>
> > >><br>
> > >> (completely untested, typos and thinkos included free of charge... but<br>
> > >> something along those lines should work...)<br>
> > ><br>
> > > Now I need a beer and/or coffee.<br>
> > ><br>
> > > So after I actually built Subsurface against the Marble libs modified with<br>
> > > the fprintf(stderr... line., this does do something.<br>
> > ><br>
> > > (gdb) run<br>
> > > Starting program: /home/rick/build/subsurface/build/subsurface<br>
> > > [Thread debugging using libthread_db enabled]<br>
> > > Using host libthread_db library "/lib64/libthread_db.so.1".<br>
> > > fullpath /bitmaps/empty.png results in<br>
> > > tried to open nonexistent file bitmaps/empty.png<br>
> > > fullpath /maps/earth/srtm2/srtm2.dgml results in<br>
> > > tried to open nonexistent file maps/earth/srtm2/srtm2.dgml<br>
> > > Map theme file does not exist: ""<br>
> > > fullpath<br>
> > > /home/rick/build/subsurface/build/marbledata/placemarks/cityplacemarks.kml<br>
> > > results in<br>
> > > tried to open nonexistent file placemarks/cityplacemarks.kml<br>
> > > fullpath<br>
> > > /home/rick/build/subsurface/build/marbledata/placemarks/cityplacemarks.cache<br>
> > > results in<br>
> > > tried to open nonexistent file placemarks/cityplacemarks.cache<br>
> > ><br>
> > > etc.<br>
> > ><br>
> > > It is looking for the files in the wrong place.  marbledata is a symbolic<br>
> > > link to:<br>
> > > /home/rick/build/subsurface/marbledata, when it needs to point to<br>
> > > /home/rick/build/marble-source/data.<br>
><br>
> Strangely, no. I realize this is kinda weird, so let me explain in a<br>
> little more detail.</p>
<p dir="ltr">Yes, I realized just about everything I wrote in that email was wrong.</p>
<p dir="ltr">><br>
> Subsurface doesn't need all the different little icons and kml files that<br>
> Marble wants to show - we have a fairly small set that we want to see.<br>
> Those have been added to the Subsurface sources in marbledata/bitmaps<br>
><br>
> Marble is perfectly happy if any of the placemark data is missing. But<br>
> because of (frankly) bad programming inside Marble, if any of the bitmaps<br>
> in marbledata/bitmaps/ are missing (and we are missing most of them as we<br>
> don't want Marble to show those and clutter the globe) then Marble tries<br>
> to open a file named "" which Qt finds not funny and spews out a warning<br>
> about.<br>
><br>
> So this is what my patch is trying to address. If the file doesn't exist,<br>
> and if it's a bitmap, then return the path to bitmaps/empty.png.<br>
><br>
> So far, so good. For some reason that ended in an infinite recursion for<br>
> you. So that means it couldn't find bitmaps/empty.png either. But<br>
> empty.png should be in /home/rick/build/subsurface/marbledata/bitmaps,<br>
> correct?<br>
><br>
> So what I still don't get is "how could you have gotten that infinite<br>
> recursion?"<br>
><br>
> Sure, it's fixed, but it nags on me that I don't understand how you got<br>
> there.</p>
<p dir="ltr">I think I have some idea.  First couple of lines of output are:</p>
<p dir="ltr">fullpath /bitmaps/default_location.png results in <br>
fullpath /bitmaps/empty.png results in </p>
<p dir="ltr">It was looking for empty.png in /bitmaps instead of /home/rick/build/subsurface/build/marbledata/bitmaps.  Obviously there isn't a directory /bitmaps. So it looked for empty.png and got into a loop.<br><br></p>
<p dir="ltr">><br>
> Please remove the new symlink that you created as that just hides that in<br>
> an installed version of Subsurface a ton of these files wouldn't be there<br>
> as we don't include them.<br>
><br>
> > I think line 157 of CMakeLists.txt is guilty:<br>
> > if(NOT (insource OR insourcedir))<br>
> >     if(NOT NO_MARBLE)<br>
> >         add_custom_target(link_marble_data ALL COMMAND rm -f marbledata &&<br>
> > ln -s ${${PROJECT_NAME}_SOURCE_DIR}/marbledata<br>
> > ${${PROJECT_NAME}_BINARY_DIR}/marbledata)<br>
> >     endif()<br>
> > endif()<br>
> ><br>
> > I'm not sure how to fix this<br>
><br>
> That code is correct. Linking into the Marble sources is just wrong.<br>
><br>
> The only reason we do this is so that you can run an out-of-tree built<br>
> version of Subsurface without needing to install it (which is pretty much<br>
> the only way I ever run Subsurface, unless I test the packages that I<br>
> build in a VM or on a different machine...)<br>
><br>
> /D<br>
</p>