[Xastir] libgdal is the master here...

[Richard Polivka, N6NKO]

Tom,

I will do a CVS checkout tonight, if possible. I was wondering if this 
will conflict with the name change that was put into CVS earlierto avoid 
the call to libgdal_rtree, or was that backed out?

It is possible that when I pulled GDAL our of the repo, GRASS was pulled 
in as a dependency. Back in college, we were taught to avoid circular 
references just for this reason. It is like working on a funky PLL 
oscillator. You have to install a break somewhere to test it and I guess 
that the bridge file does the same for GRASS/GDAL. I have had many a 
gray hair working on PLL's for 900 MHz trunking radios in a past life.

I have to get ready for Cub Scout Resident Camp next week. My boy is 
really looking forward to this and I am bringing the firewood for our 
campsite. So, it is busy time.

73 from 807,

Richard, N6NKO

Tom Russo wrote:
> On Sun, Jul 01, 2007 at 09:43:11PM -0600, we recorded a bogon-computron collision of the <russo at bogodyn.org> flavor, containing:
>   
>> On Sun, Jul 01, 2007 at 04:44:46PM -0700, we recorded a bogon-computron collision of the <r.polivka at sbcglobal.net> flavor, containing:
>>     
>>> Tom:
>>>
>>> ldd spews for libgdal.so:  libgrass_rtree is linked in.
>>>       
>> No surprise.  Hadda have been where it was coming from.
>>
>>     
>>> ldd spews fro libgrass_rtree: nothing except for libm and libc.
>>>
>>> F7 repo uses gdal-1.4.1, grass-libs-6.2.1
>>>
>>> I will have to concur that gdal was built full up but I do not see a circular reference in place. GRASS will stand free, but GDAL needs GRASS (there is a bad joke in there somewhere). 
>>>       
>> Actually, no.  GRASS absolutely requires GDAL, and will not build without
>> it --- unless it's quite an old version of GRASS for which GDAL was merely
>> optional.  
>>     
>
> How the F7 repository gets around the circular dependency is probably by
> bundling the GRASS libraries with the GDAL package, and then having a 
> GRASS package that requires the GDAL package to work (thereby getting all
> of its own libraries from a separate package).  An icky solution for which
> someone will probably not go to heaven, but one that gets rid of the circular 
> dependency by blurring the boundaries between the two highly interdependent
> pieces of software.
>
>