Sorry for the delay but I am running into windows/gtk problems. I am
getting linking errors for "_gdk_draw_rgb_32_image" and two other gdk
symbols. I can't seem to find which lib they are in either. I
installed "gtk-dev-2.12.9-win32-2.exe". Do we target a specific
version of gtk? I am thinking I might have to fall back to an older
version.
- Charlie
···
On Fri, May 30, 2008 at 10:06 AM, John Hunter <jdh2358@...149...> wrote:
On Thu, May 29, 2008 at 11:11 PM, Charlie Moad <cwmoad@...149...> wrote:
I went ahead and called it 0.98.0. I am getting a parallels image
updated so I can do the windows builds, but it is getting late. I
will get those cranked out tomorrow. The source and mac builds are up
though. I got two internal compiler errors on the 0.98.0 build, which
I fixed by replacing -O3 with -Os on those two commands only. I also
updated the MANIFEST.in file to include agg24 instead of agg23.
Hey Charlie -- thanks for getting these two releases out. I think we
should probably hide them, though, until the windows binaries are up,
since it will confuse windows users who follow the link to the latest
releases but find no binaries. So if you are more than a few hours
away from putting up the windows installers, let's hide these until
they are ready.
Thanks,
JDH
We are not targeting a specific gtk version and I am not sure that we
need to be supporting gtk in win32 anymore. I used to distribute a
gtk app on win32 that needed mpl (pbrain) but I am not sure anyone is
actively using this anymore (it is part of nipy now). We could do a
test build w/o gtk and see if anyone complains, or simply revert back
to the last gtk version that worked for you.
In any case, I don't think you should burn a lot of time on it. If
you can get a gtk enabled win32 build, great. If not, just disable
gtk support. Our goal is to get rid of as much gui dependent
extension code as possible anyhow. I think we've concluded that we
can't get rid of the tkagg extension, but for the rest of the GUIs we
should be able to use python buffer objects. Perhaps this will
provide some impetus to develop a pure pygtk enabled gtkagg.
JDH
···
On Sat, May 31, 2008 at 9:47 AM, Charlie Moad <cwmoad@...149...> wrote:
Sorry for the delay but I am running into windows/gtk problems. I am
getting linking errors for "_gdk_draw_rgb_32_image" and two other gdk
symbols. I can't seem to find which lib they are in either. I
installed "gtk-dev-2.12.9-win32-2.exe". Do we target a specific
version of gtk? I am thinking I might have to fall back to an older
Rolling gtk and pygtk back to 2.10 worked.
I may be a little rusty on the builds, so please give them a try
before the announcement.
- Charlie
···
On Sat, May 31, 2008 at 12:31 PM, John Hunter <jdh2358@...149...> wrote:
On Sat, May 31, 2008 at 9:47 AM, Charlie Moad <cwmoad@...149...> wrote:
Sorry for the delay but I am running into windows/gtk problems. I am
getting linking errors for "_gdk_draw_rgb_32_image" and two other gdk
symbols. I can't seem to find which lib they are in either. I
installed "gtk-dev-2.12.9-win32-2.exe". Do we target a specific
version of gtk? I am thinking I might have to fall back to an older
We are not targeting a specific gtk version and I am not sure that we
need to be supporting gtk in win32 anymore. I used to distribute a
gtk app on win32 that needed mpl (pbrain) but I am not sure anyone is
actively using this anymore (it is part of nipy now). We could do a
test build w/o gtk and see if anyone complains, or simply revert back
to the last gtk version that worked for you.
In any case, I don't think you should burn a lot of time on it. If
you can get a gtk enabled win32 build, great. If not, just disable
gtk support. Our goal is to get rid of as much gui dependent
extension code as possible anyhow. I think we've concluded that we
can't get rid of the tkagg extension, but for the rest of the GUIs we
should be able to use python buffer objects. Perhaps this will
provide some impetus to develop a pure pygtk enabled gtkagg.
JDH