On Feb 16, 2008, at 5:59 AM, grass-dev-request@lists.osgeo.org wrote:
Date: Sat, 16 Feb 2008 13:59:09 +0100
From: "Martin Landa" <landa.martin@gmail.com>
Subject: Re: [GRASS-dev] Building gui/wxpython/vdigit fails on Gentoo
To: "Maris Nartiss" <maris.gis@gmail.com>
Cc: grass-dev@lists.osgeo.org
Message-ID:
<f8fe65c40802160459n6d7c500s4ff2dbd21c96bdcc@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Hi,
2008/2/16, Maris Nartiss <maris.gis@gmail.com>:
I was compiling recent svn trunk (r30180) and vdigit failed to build
(link). As trac issue #38 is closed, I assume wx related stuff
detection now works and this must be my fault. What I did wrong?
[snip]
cannot find -lgdi
collect2: ld returned 1 exit status
make: *** [grass6_wxvdigit.so] Error 1
yes, this is the last step you need to do manually. In wxPython code
is used wx.PsedoDC class which is not part of wxWidgets itself (should
be included in 2.9). So you need to link against C++ wxPython shared
library which is not defined in $WXWIDGETSLIB. On Debian this library
is located in /usr/lib/python2.4/site-packages/wx-2.8-gtk2-unicode/wx/_gdi_.so.
So I am not sure how to solve this issue in Makefile. Now you need to
create a symlink, e.g.
2008/2/16, Michael Barton <michael.barton@asu.edu>:
This is confusing to me. wx.PseudoDC has been a part of wxPython code
for quite some time. We're using it as a basis for the main map display.
right, it is the reason why I am using PseudoDC class in digitizer.
Since C++ PseudoDC class is not part of wxWidgets (should be in 2.9)
but only of wxPython it causes some problems in compilation process.
You need to define also includes/libs for wxPython (C++ code).
Also, since you use $GISBASE, I assume that you mean that the driver
must be compiled AFTER running make and make install. Correct?
Yes, I will change README notes to something more reasonable.
2008/2/16, Michael Barton <michael.barton@asu.edu>:
This is confusing to me. wx.PseudoDC has been a part of wxPython code
for quite some time. We're using it as a basis for the main map display.
right, it is the reason why I am using PseudoDC class in digitizer.
Since C++ PseudoDC class is not part of wxWidgets (should be in 2.9)
but only of wxPython it causes some problems in compilation process.
You need to define also includes/libs for wxPython (C++ code).
So we make a link to the wxPython includes and libs so that C++ can find the PseudoDC pieces it needs?
Michael
Also, since you use $GISBASE, I assume that you mean that the driver
must be compiled AFTER running make and make install. Correct?
Yes, I will change README notes to something more reasonable.
2008/2/16, Michael Barton <michael.barton@asu.edu>:
> 2008/2/16, Michael Barton <michael.barton@asu.edu>:
>> This is confusing to me. wx.PseudoDC has been a part of wxPython code
>> for quite some time. We're using it as a basis for the main map
>> display.
>
> right, it is the reason why I am using PseudoDC class in digitizer.
> Since C++ PseudoDC class is not part of wxWidgets (should be in 2.9)
> but only of wxPython it causes some problems in compilation process.
> You need to define also includes/libs for wxPython (C++ code).
So we make a link to the wxPython includes and libs so that C++ can
find the PseudoDC pieces it needs?
yes, since PseudoDC is not (yet) part of wxWidgets it is required (at
least for pseudodc.h and given shared library (_gdi_.so)).
> >> This is confusing to me. wx.PseudoDC has been a part of wxPython code
> >> for quite some time. We're using it as a basis for the main map
> >> display.
> >
> > right, it is the reason why I am using PseudoDC class in digitizer.
> > Since C++ PseudoDC class is not part of wxWidgets (should be in 2.9)
> > but only of wxPython it causes some problems in compilation process.
> > You need to define also includes/libs for wxPython (C++ code).
>
> So we make a link to the wxPython includes and libs so that C++ can
> find the PseudoDC pieces it needs?
yes, since PseudoDC is not (yet) part of wxWidgets it is required (at
least for pseudodc.h and given shared library (_gdi_.so)).
anyway usage of wxPseudoDC class can causes problems during
compilation process. If we don't find reasonably good approach I will
take a look how to eliminate wxPseudoDC in vdigit C++ code (use wxDC
instead). I would prefer to use wxPseudoDC.
anyway usage of wxPseudoDC class can causes problems during
compilation process. If we don't find reasonably good approach I will
take a look how to eliminate wxPseudoDC in vdigit C++ code (use wxDC
instead). I would prefer to use wxPseudoDC.
wx 3.0 is due out soon* so a solution is already in the pipeline and
will arrive before we /really/ need it (6.4.0).
The new GUI is clearly indicated as a work in progress- we can put in
the announcement that users who want to try wxGUI should study the
README file and expect some bumps. The work-around for wx2.8 is just a
one liner not some major recompile or installation.
Thus for my 2c, if you prefer to use wxPseudoDC then stay with it, and
focus on the long term goal of 6.4.0. Why sacrifice your valuable
energy & a better code-path to get around short term (small) problems
which are already fixed upstream?
____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs
still the work-around for 2.8 isn't so bad, just one symlink.
Hamish
____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs
anyway usage of wxPseudoDC class can causes problems during
compilation process. If we don't find reasonably good approach I will
take a look how to eliminate wxPseudoDC in vdigit C++ code (use wxDC
instead). I would prefer to use wxPseudoDC.
wx 3.0 is due out soon* so a solution is already in the pipeline and
will arrive before we /really/ need it (6.4.0).
The new GUI is clearly indicated as a work in progress- we can put in
the announcement that users who want to try wxGUI should study the
README file and expect some bumps. The work-around for wx2.8 is just a
one liner not some major recompile or installation.
Thus for my 2c, if you prefer to use wxPseudoDC then stay with it, and
focus on the long term goal of 6.4.0. Why sacrifice your valuable
energy & a better code-path to get around short term (small) problems
which are already fixed upstream?
____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs
> anyway usage of wxPseudoDC class can causes problems during
> compilation process. If we don't find reasonably good approach I will
> take a look how to eliminate wxPseudoDC in vdigit C++ code (use wxDC
> instead). I would prefer to use wxPseudoDC.
Personally, I would suggest avoiding it. Python extension modules
(_module_.so) aren't intended to be used outside of Python. I don't
know whether using them as normal shared libraries is going to cause
problems.
wx 3.0 is due out soon* so a solution is already in the pipeline and
will arrive before we /really/ need it (6.4.0).
Meanwhile, every Linux distribution is still shipping 2.6. FWIW,
Gentoo only added an ebuild for 2.8 a fortnight ago (2008/01/29).
At this rate, it looks like some distribution vendors *might* actually
be providing 2.8 by the time that 7.x is ready for end users. OTOH,
3.0 might not be in actual use before the end of the decade.