gtk fortran winxp undefined reference

[DrOli]

This is my first go at GTK. I have installed GTK 3.6.4 (latest for Win) on WinXP64 box with CodeBlocks 13.12. Both MingW and MingW64 are installed.

I can compile and run two example programs: a "hello world" test and the hello2 target in the test_gtk_fortran_1 suit.

All the other targets in test_gtk_fortran_1 fail for one reason or another. The most common failure is of the type:

..\test_gtk_fortran_1\gtk_src\gtk-hl-container.f90|593|undefined reference to `gtk_notebook_set_group'

and the many variants of this, especially the ones ending with "_utf8".

I have corrected the CodeBlocks project search dir's etc (otherwise the "hello" test fail)

I have searched through many of the gtk....f90 files, and the GTK libs etc. I have seen some discussion of this issue in the past, but almost all of it for Linux, or resolved with a newer version of GTK not available for Win.

I would be grateful for any assistance.

PS. the cairo-test target in the test suite compiles, but on execution throws a Seg Fault on one of the signal event handlers

[vmagnin]

Hi DrOli and welcome to gtk-fortran. I can not help much concerning WinXP but perhaps you can contact other Windows users.
But have you used the Master branch of gtk-fortran (which is for GTK2) or the gtk3 branch ? You should use of course this last one because you have GTK 3.6.4.
I ask the question because I found this in the GTK documentation:
gtk_notebook_set_group has been deprecated since version 2.24 and should not be used in newly-written code. Use gtk_notebook_set_group_name() instead
https://developer.gnome.org/gtk2/stable/GtkNotebook.html#gtk-notebook-set-group

gtk_notebook_set_group does not exist anymore in GTK3:
https://developer.gnome.org/gtk3/3.6/GtkNotebook.html

It makes me think you have build the wrong branch...

[DrOli]

Dear Jerry

Many thanks for the (very) prompt response. Your links were helpful.
Mostly, it just required some "schlocking" through the .f90's to come to
understand how the modules intertwine, how the "version control" (GTK2 vs 3
etc) and the various mechanisms used to "OS control" were implemented.

In the event, I can compile and run (sort of) all the test_gtk_fortran_1
suite (which seems to be most of what the gtk-fortran master includes). It
required a fair bit of fiddling with .f90's to get them "on the same page"
:-).

There are two things holding me back, though:

1. None of the plplot images are showing up in the demo's. Everything else
   is there, tabs, sliders, buttons, etc etc, the machine is calculating the
   plots (e.g. Mandelbrot/Julia etc), but the nothing shows up in the GTK
   window's container where the charts etc should be. plplot compiled fine, it
   links to the f90's but no charts.

I used the debugger to step through to see if I could find the step where
the chart signal/event actually occurs, but I could not suss why there are
no charts in the GUI.

... any hints would be much appreciated.

BTW, what is the benefit of "make/install" the gtk-fortran package? At the
moment, I can simply use/copy the f90's as per normal, without having to
bother with "make" etc steps to "install" gtk-fortran. Am I missing
something here?

2. By far the most important objective for me is to be able create a
   spreadsheet, which looks to be best served by GTKExtra. I see that
   gtk-fortran has some GTKExtra bits, and I have dloaded the latest GTKExtra
   tar.

The extent of my progress is that I can get a couple of the GTKExtra icons
to show up in Glade, but of course they do nothing since I have only added
the xml ... that's about as far as I can figure how to go.

It looks like the GTKExtra people don't have any explicit Fortran efforts,
and apparently absolutely no Windows interest. Do I really need to figure
out how to make/install the GTKExtra package, or can I just use the relevant
f90's, as I had with the tests/demos?

... though presumably there will still be some trick to have Glade "see" the
GTKExtra bits.

I've actually built the beginnings of a Fortran spreadsheet in Windows with
Winteracter (but Winteracter is too limited), and ported that Fortran
spreadsheet to Android with a Java GUI, but that is in it's early days. I
am hoping that the GTK/GTKExtra approach will permit the range functionality
I require (beyond Winteracter) and that it will simultaneously port to
Linux/Android without too much grief.

Sorry if this is asking a lot ... I am happy to give back in some reasonable
way :-)

Cheers

DrOli

-----Original Message-----
From: vmagnin [mailto:notifications@github.com]
Sent: 18 April 2015 16:37
To: jerryd/gtk-fortran
Cc: DrOli
Subject: Re: [gtk-fortran] gtk fortran winxp undefined reference (#84)

Hi DrOli and welcome to gtk-fortran. I can not help much concerning WinXP
but perhaps you can contact other Windows users.
But have you used the Master branch of gtk-fortran (which is for GTK2) or
the gtk3 branch ? You should use of course this last one because you have
GTK 3.6.4.
I ask the question because I found this in the GTK documentation:
gtk_notebook_set_group has been deprecated since version 2.24 and should not
be used in newly-written code.
Use gtk_notebook_set_group_name() instead
https://developer.gnome.org/gtk2/stable/GtkNotebook.html#gtk-notebook-set-gr
oup

gtk_notebook_set_group does not exist anymore in GTK3:
https://developer.gnome.org/gtk3/3.6/GtkNotebook.html

It makes me think you have build the wrong branch...

Reply to this email directly or view
#84 (comment) it
on GitHub.
<https://github.com/notifications/beacon/ALdHiqF6CjI7NSMoRm-9cU73J5v0GWg9ks5
oArfcgaJpZM4EDeJ9.gif>

[vmagnin]

Hi DrOli,
I am happy you have successfully build the project. I will post here on message by question.
Concerning plplot examples, I have the same problem when the window size is smaller than the graph to show. But the plot is shown when I increase the size of the window.

[vmagnin]

The benefit of "make/install" the gtk-fortran package is mainly to avoid to always recompile everything and to have the library accessible from everywhere in the OS. And the library could be distributed in a package (there is one for Arch distributions), and updated for all your projects automatically.
But you can also work your way: it is probably less "clean" but easier. The important thing is that it works !

[vmagnin]

There were some efforts some years ago to use GTKExtra, before it migrates to GTK3, but I think they were not successful:
https://github.com/jerryd/gtk-fortran/search?q=gtkextra&type=Issues&utf8=%E2%9C%93

Now that the migration seems to be OK, it would be interesting to try to use it.

[DrOli]

Cheers for that, and my apologies for my poorly worded enquiry.

Yes, of course, I understand about the "cleanliness" and efficiency of a
"lib" based installation. In fact, if things go well with GTKExtra, I will
be re-writing a number of gtk-fortran f90's and creating libs more suitable
for my needs.

What concerned me, as a newebi to GTK etc, is that perhaps the gtk-fortran
make/install process creates "internal linkages" or other important
mechanisms (separate from creating f90 libs), such integration with GTK or
Glade or whatever.

In addition, since it had a dir for GTKExtra, I was not sure if that would
then produce or be required for important linkages to GTK/Glade for that
package.

I will assume from you answer that it is just the former.

Many thanks

DrOli

-----Original Message-----
From: vmagnin [mailto:notifications@github.com]
Sent: 19 April 2015 05:31
To: jerryd/gtk-fortran
Cc: DrOli
Subject: Re: [gtk-fortran] gtk fortran winxp undefined reference (#84)

The benefit of "make/install" the gtk-fortran package is mainly to avoid to
always recompile everything and to have the library accessible from
everywhere in the OS. And the library could be distributed in a package
(there is one for Arch distributions), and updated for all your projects
automatically.
But you can also work your way: it is probably less "clean" but easier. The
important thing is that it works !

Reply to this email directly or view
#84 (comment) it
on GitHub.
<https://github.com/notifications/beacon/ALdHijG1D5iXVtx9skA4v50P73LX0MK7ks5
oA21NgaJpZM4EDeJ9.gif>

[DrOli]

Cheers for that, yes that had occurred to me as well, and I did try various
resizing, but no joy.

This morning I re-compiled everything from clean, and re-ran everything with
a greater number of sizing permutations (when possible, see below) .. again
no joy.

A few observations/questions, just in case:

1. Two test progs fail with Seg Fault on launch as follows

a) Cairo-Tests.f90: Seg Fault on launch every time

I ran the debugger and a lot of stepping to determine the Seg Fault occurs
on this line inside a loop for counters as shown

    call pending_events()  ... Line 244 in Cairo-Tests.f90  Sig Fault

for i = 5 , j = 3

b) hl_cairo1.f90: Seg Fault on launch ... "sometimes only", no idea why, so
no reliable debugging available (at least not easily)

If the launch succeeds, it appears "stable" on resize etc, but of course, no
plot.

2. The test prog hl_plplot17e: Seg Abort on resize of GTK window

... in all cases without Seg/Abort Fault, debugging etc shows the plotting
calcs are produced, just not rendered

3. Could it be screen resolution? I am running 1440x900

Or cairo specific (e.g. linked to wrong cairo elements etc)?

4. During the build of plplot, it produced (I am assuming) single prec libs,
   such as libplplotf95c.dll, but the test programme CodeBlocks project
   originally arrived with a lib dependence of libplplotf95cd.dll (I am
   assuming that means double prec), etc. To get things to work without the
   several "xxd.dll's", I changed the project dependence to the single prec
   "xx.dll's"

That allows compile and run, but could it have an impact rendering the
plots?

Many thanks

DrO

WinXP64 all latest
CodeBlock 13.12
MingW (win32) latest stable
MingW-64 latest (but have used MingW 32 for everything so far, its not on
any paths, etc)
GTK+ 3.6.4 (win32)
plplot 5.11.0 (created with cmake 3.2.2 for win, though I use it in a shell
directly in the plplot dir's as per online instructions)
gtk-fortran latest (not relying on any of this yet, instead have edited
gtk-fortran f90's that came with test_gtk_fortran_1)
GNUWin/SED installed but not used, as far as I know

-----Original Message-----
From: vmagnin [mailto:notifications@github.com]
Sent: 19 April 2015 05:19
To: jerryd/gtk-fortran
Cc: DrOli
Subject: Re: [gtk-fortran] gtk fortran winxp undefined reference (#84)

Hi DrOli,
I am happy you have successfully build the project. I will post here on
message by question.
Concerning plplot examples, I have the same problem when the window size is
smaller than the graph to show. But the plot is shown when I increase the
size of the window.

Reply to this email directly or view
#84 (comment) it
on GitHub.
<https://github.com/notifications/beacon/ALdHitckZfdEdUisf7EDiAuwVicSW_rDks5
oA2qRgaJpZM4EDeJ9.gif>

[DrOli]

Many thanks for that, I had a look at those discussions. Alas, as is
virtually always the case, the discussions are almost exclusively wrt Linux.

The GTKExtra dload package itself is purely in Linux "mode". The
make/config/instal bits are explicitly Linux dir structure and rely bash
bits that I am not sure how to implement (nor what they will actually
produce) on Win.

I have spent a little time in "bash Hell" when I created a ToolChain that
compiles Fortran for Android, but mostly my experience is limited.

I am perfectly happy to invest some time in this, but frankly my
inexperience leaves without even a starting point (on the win side).

I tried to use the subscribe etc process to contact the GTKExtra people, but
haven't been able to contact anyone there.

If there were some instructions such as for plplot on this page
(http://sourceforge.net/p/plplot/wiki/Configure_PLplot_for_MinGW_CLI/) for
GTKExtra on Win, or at least some basic explanation of what needs to
compiled, how, and where it needs to end up (especially for Glade
integration) ... that might be enough to start experimenting with a Win
GTKExtra.

I am very grateful for all the time you and your peers have contributed to
the gtk-fortran effort, and feel a bit bad about asking for help ... but any
hints at all would be much appreciated.

In return, I can offer to produce some docs and updated gtk-fortran f90's
that work in Win with current releases, and some docs on the install etc
process at the end of it ... perhaps as reasonable, if as yet the only, doc
for those interested in Glade/GTK/Fortran on Windows.

Cheers

DrOli

-----Original Message-----
From: vmagnin [mailto:notifications@github.com]
Sent: 19 April 2015 05:41
To: jerryd/gtk-fortran
Cc: DrOli
Subject: Re: [gtk-fortran] gtk fortran winxp undefined reference (#84)

There were some efforts some years ago to use GTKExtra, before it migrates
to GTK3, but I think they were not successful:
https://github.com/jerryd/gtk-fortran/search?q=gtkextra
<https://github.com/jerryd/gtk-fortran/search?q=gtkextra&type=Issues&utf8=%E
2%9C%93> &type=Issues&utf8=%E2%9C%93

Now that the migration seems to be OK, it would be interesting to try to use
it.

Reply to this email directly or view
#84 (comment) it
on GitHub.
<https://github.com/notifications/beacon/ALdHivKtzkOxVQ7hWX6B52mIS5dVZKzdks5
oA2-ggaJpZM4EDeJ9.gif>

[vmagnin]

Sorry, I had misunderstood your questions.
Concerning CMake, the main contributor is James TAPPIN. As far as I know, CMake is looking for the path of the various tools and libraries needed for the build, then compiles everything and put the gtk-fortran library in the right place in the OS filesystem.

Concerning GTKExtra, I had forgotten there was a graphics/gtk_extra dir in the project. I think it was contributed by Jens HUNGER. But I do not think that CMake is building it. It was just an attempt to use GTKExtra. And you can try to contact Jens to know more about it.

[vmagnin]

Concerning the seg faults under Windows, it is possible that GTK 3.6.4 for Windows is quite buggy. Under Linux, GTK3 is now in 3.14 or 3.16 version. So, Windows versions are not as well maintained as Linux ones... 3.6.4 dates back to January 2013.

[vmagnin]

Any contribution, code or doc, concerning gtk-fortran in Windows would be welcome and appreciated !

[DrOli]

Just a quick update/question: In one of my earlier submissions I indicated that while the fortran-gtk samples compile without issue, and apparently all of the "GTK bits" work (i.e. dialogues etc pop up, buttons, sliders, etc work) ... the plplot bits were not showing up, at all. It's certainly doing all the calc's for the plots, and stepping through with the debugger it certainly seems to call all the s/r's etc, but the GTK regions/containers where the plots should show up remain "blank".

Resizing the screen makes no difference to the (non) plot, but does cause some of the fortran-gtk examples to crash (seg fault).

This occurs with both 32 and 64 bit WinXP machines with different graphics cards/resolutions.

Compiling and running the pure plplot examples in isolation produces the plots as expected on the same machines ... whoo hoo :-)

Thus GTK is working for GTK bits, plplot works in isolation, but the fortran-gtk-plplot combined examples fail to plot (anything, ever), and some have seg faults.

This suggests that there is something curious about how the fortran-gtk examples interleave with plplot

Any hints/suggestions at all would be greatly appreciated. Indeed I would be happy to focus my attention on just one of the fortran-gtk-plplot examples, perhaps the hl_plplot8e.f90 example, to see if we can get at least one working (that example does not show the plots, but at least it is "stable"/no seg faults, and all the GTK bits seem to be working).

Once again many thanks for your assistance.

DrO

PS. I appreciate this may be more of a question for the plplot-gang, but is there some way to tell plplot to use a particular driver programmatically, rather than being asked for device number/keyword all the time?

PPS. Purely as curiosity, and only if it is convenient, as I am learning, I am hearing that (at least on other platforms), there is some manner of "exodus" from GTK to QT ... any thoughts?

WinXP64 (or 32), all latest
MingW(32) latest, gcc 4.81
GTK 3.6.4
PLPlot 5.11

[DrOli]

oops, dreadfully sorry I clicked the "close and comment" button thinking it meant "validation" and post comment ... I did NOT intend to close the issue.

There is a now duplicate of the my comment, but I don't know how to remove it.

... perhaps the "close and comment" label in that button should be updated.

[vmagnin]

Hi DrO

I have deleted the duplicated message.

Concerning PLPLOT, I can not help you. But in my opinion, the GTK+ version for Windows is buggy.

Concerning Qt, perhaps it is possible to create a Qt-Fortran. I do not know. But I remember that in 2010, I chose GTK+ on purpose rather than Qt or wxWidgets because it is written in C, so the binding is easier than with C++ (Qt is written in C++), thanks to the ISO_C_BINDING module.

[DrOli]

Many thanks for your prompt response.

There does not seem to be much choice Re GTK for Win, which is several years
old (3.6.4 win vs. 3.16 now), since it is (at least for me) impossible to
build an updated GTK for Win. I have spent a huge amount of time trying to
build/install the latest GTK, on the hopes that would fix these issues.

Unfortunately, GTK requires GLib, which (for some time now) requires Python.
For me at least, building Python under MingW/GCC is insurmountable
(primarily since the the Python people will not create the bits for
MingW/GCC, only the bits for MSVC ... which I can compile with MSVC ...
however, according to those in the know, that cannot be used as a building
block to GLib/GTK (via MingW/GCC) since the MSVC c conventions/extensions
etc create collision with the those in the MingW/GCC construction for
GLib/GTK ... resulting in a perpetuity of crashes.

... apparently, and there are some strongly worded statements by some, the
Python people are wholly and wilfully uncooperative on this point ...

... I'll think about some other way to skin this cat, but at this point I am
not hopeful.

... my ultimate goal is to get GTKExtra's widget's working, and apparently
GTKExtra has its own graphics package ...

As for the choice of GTK over QT, I am entirely sympathetic ... just worried
that if the masses move to QT, which seems like a much more difficult
"fortran environment", the support/development for GTK may evaporate.

Once again, many thanks

DrO

-----Original Message-----
From: vmagnin [mailto:notifications@github.com]
Sent: 09 May 2015 13:25
To: jerryd/gtk-fortran
Cc: DrOli
Subject: Re: [gtk-fortran] gtk fortran winxp undefined reference (#84)

Hi DrO

I have deleted the duplicated message.

Concerning PLPLOT, I can not help you. But in my opinion, the GTK+ version
for Windows is buggy.

Concerning Qt, perhaps it is possible to create a Qt-Fortran. I do not know.
But I remember that in 2010, I chose GTK+ on purpose rather than Qt or
wxWidgets because it is written in C, so the binding is easier than with C++
(Qt is written in C++), thanks to the ISO_C_BINDING module.

Reply to this email directly or view
#84 (comment) it
on GitHub.
<https://github.com/notifications/beacon/ALdHirRb3EPHMykURfhZ08R5_DokCDbFks5
oHjpggaJpZM4EDeJ9.gif>

[DrOli]

OK, I've sussed it ... well the PLPlot bits anyway. At the moment, all of
the pure GTK, and all of the GTK/PLPlot examples work. The cairo examples
are still a problem.

The short explanation was in the editing of the examples for GTK3 vs. GTK2
usage, and many additional interface funcs/enums etc required for the
fortran-gtk mods/libs etc.

I'll let you know how I get on with the cairo bits.

Cheers

DrO

-----Original Message-----
From: oliver [mailto:droli@thebajors.com]
Sent: 09 May 2015 14:23
To: 'jerryd/gtk-fortran'
Subject: RE: [gtk-fortran] gtk fortran winxp undefined reference (#84)

Many thanks for your prompt response.

There does not seem to be much choice Re GTK for Win, which is several years
old (3.6.4 win vs. 3.16 now), since it is (at least for me) impossible to
build an updated GTK for Win. I have spent a huge amount of time trying to
build/install the latest GTK, on the hopes that would fix these issues.

Unfortunately, GTK requires GLib, which (for some time now) requires Python.
For me at least, building Python under MingW/GCC is insurmountable
(primarily since the the Python people will not create the bits for
MingW/GCC, only the bits for MSVC ... which I can compile with MSVC ...
however, according to those in the know, that cannot be used as a building
block to GLib/GTK (via MingW/GCC) since the MSVC c conventions/extensions
etc create collision with the those in the MingW/GCC construction for
GLib/GTK ... resulting in a perpetuity of crashes.

... apparently, and there are some strongly worded statements by some, the
Python people are wholly and wilfully uncooperative on this point ...

... I'll think about some other way to skin this cat, but at this point I am
not hopeful.

... my ultimate goal is to get GTKExtra's widget's working, and apparently
GTKExtra has its own graphics package ...

As for the choice of GTK over QT, I am entirely sympathetic ... just worried
that if the masses move to QT, which seems like a much more difficult
"fortran environment", the support/development for GTK may evaporate.

Once again, many thanks

DrO

-----Original Message-----
From: vmagnin [mailto:notifications@github.com]
Sent: 09 May 2015 13:25
To: jerryd/gtk-fortran
Cc: DrOli
Subject: Re: [gtk-fortran] gtk fortran winxp undefined reference (#84)

Hi DrO

I have deleted the duplicated message.

Concerning PLPLOT, I can not help you. But in my opinion, the GTK+ version
for Windows is buggy.

Concerning Qt, perhaps it is possible to create a Qt-Fortran. I do not know.
But I remember that in 2010, I chose GTK+ on purpose rather than Qt or
wxWidgets because it is written in C, so the binding is easier than with C++
(Qt is written in C++), thanks to the ISO_C_BINDING module.

Reply to this email directly or view
#84 (comment) it
on GitHub.
<https://github.com/notifications/beacon/ALdHirRb3EPHMykURfhZ08R5_DokCDbFks5
oHjpggaJpZM4EDeJ9.gif>

[vmagnin]

Fine, let us know your progress with Windows.

Concerning the choice of the graphics library, the long-life argument was important. I still use Fortran programs I wrote nearly 20 years ago, so I understand this argument. That is why I focused mainly on GTK+ and Qt, which were both used for more than 10 years and were largely used in the free software community.

It is true that there is some migrations toward Qt, but I believe/hope that GTK+ will still be alive in 10 years (in 20 years, I do not know !) because there is some great projects based on it: GIMP, GNOME and its derivatives, Inkscape, XFCE... (but LXDE has been ported to Qt...) I think there is room for many graphics library in the free software landscape. Linux has a market share around 1% on the desktop but is still alive and well alive ! In free software, to be in minority is not to be doomed. As long as there is some people passionate by a project, it can have a long life. But nothing is sure, rendez-vous in 20 years !

[DrOli]

Many thanks for those insights regarding the "longevity" of GTK-Fortran.
I'll plod on towards my objective of Glade/GTKExtra GUI via gtk-fortran.

As a matter of interest, I have started on what I hope is the last stage in
having the gtk-fortran examples working on WinXP64 (MingW32/GCC32). I have
been focusing my attention on the cairo-tests.f90. This compiles fine, but
either it is unstable/crashes (usually almost immediately on launch, or is
stable, but no image appears in the GTK drawing area.

I've been using the debugger, etc and found that:

1. On very rare occasions it has a stable launch (in which case it remains
   stable regardless of re-size/location manipulation of the GUI), but no
   "plot". In this case, stepping through the code, the console reports

(hl_cairo1.exe:1040): GLib-GObject-WARNING **: gsignal.c:2459: signal
expose-ev ent' is invalid for instance02411000'

(hl_cairo1.exe:1040): Gtk-WARNING **: drawing failure for widget
`GtkWindow': ou
t of memory
System time = 200.68800000000192

This seems to suggest that it is NOT plotting since it feels it does not
have sufficient memory. It's on a 16Gig RAM box, so I presume it is
complaining about stack memory or some other gkt buffer or whatever. I
tried a variety of tests changing width = 700 and height = 700, which also
drive the computational/array matters, to a variety of different values ...
down to 100 x 100, and still no joy.

The only array that I could see is the "pixel(:)" char Pointer array. As
that is created/allocated "on the fly", it is likely on the heap, which
should not create any (fortran) memory issues ... of course I have no idea
what happens on the C/GTK side.

2. On the vast majority of cases, it crashes "on launch". In fact stepping
   through the code, it performs a substantial part of the initial calculation,
   but in the calculation loop there is a call to process "pending_events".
   This is where the crash occurs. In particular, it calls the s/r

subroutine pending_events ()
do while(IAND(gtk_events_pending(), run_status) /= FALSE)
boolresult = gtk_main_iteration_do(FALSE) ! False for non-blocking
! <<<<<<<<<<<<<< this where the crash occurs, not possible to "step into"
end do
end subroutine pending_events

The call stack shows that in gtk's attempt to process its events, it falls
afoul of msvcrt/malloc, as per

#0 7D61002E ?? () (??:??)
#1 7D684C99 ?? () (??:??)
#2 7D656AF3 ?? () (??:??)
#3 7D6858A2 ?? () (??:??)
#4 7D65695E ?? () (??:??)
#5 7D634B91 ?? () (??:??)
#6 77BBD08C msvcrt!malloc() (C:\WINDOWS\syswow64\msvcrt.dll:??)
#7 68DD8204 _cairo_gstate_save() (D:\Apps\GTK3\bin\libcairo-2.dll:??)
#8 68DCE7D1 cairo_save() (D:\Apps\GTK3\bin\libcairo-2.dll:??)
#9 665F9CC8 gtk_render_handle() (D:\Apps\GTK3\bin\libgtk-3-0.dll:??)
#10 666DBEDB gtk_window_draw() (D:\Apps\GTK3\bin\libgtk-3-0.dll:??)
#11 665556E5 _gtk_marshal_BOOLEAN__BOXEDv()
(D:\Apps\GTK3\bin\libgtk-3-0.dll:??)
#12 666B7928 gtk_widget_draw_marshallerv()
(D:\Apps\GTK3\bin\libgtk-3-0.dll:??)
#13 63A46913 g_type_class_meta_marshalv()
(D:\Apps\GTK3\bin\libgobject-2.0-0.dll:??)
#14 63A4654E _g_closure_invoke_va()
(D:\Apps\GTK3\bin\libgobject-2.0-0.dll:??)
#15 63A5C6C5 g_signal_emit_valist()
(D:\Apps\GTK3\bin\libgobject-2.0-0.dll:??)
#16 63A5D06A g_signal_emit() (D:\Apps\GTK3\bin\libgobject-2.0-0.dll:??)
#17 666BFE2C _gtk_widget_draw_internal()
(D:\Apps\GTK3\bin\libgtk-3-0.dll:??)
#18 666C098E gtk_widget_send_expose() (D:\Apps\GTK3\bin\libgtk-3-0.dll:??)
#19 66553F35 gtk_main_do_event() (D:\Apps\GTK3\bin\libgtk-3-0.dll:??)
#20 70ECB532 _gdk_event_emit() (D:\Apps\GTK3\bin\libgdk-3-0.dll:??)
#21 70ED93BD _gdk_window_process_updates_recurse()
(D:\Apps\GTK3\bin\libgdk-3-0.dll:??)
#22 70ED94E2 _gdk_window_process_updates_recurse()
(D:\Apps\GTK3\bin\libgdk-3-0.dll:??)
#23 70F081CF gdk_win32_window_process_updates_recurse()
(D:\Apps\GTK3\bin\libgdk-3-0.dll:??)
#24 70ED9751 gdk_window_process_updates_internal()
(D:\Apps\GTK3\bin\libgdk-3-0.dll:??)
#25 70ED99B2 gdk_window_process_all_updates()
(D:\Apps\GTK3\bin\libgdk-3-0.dll:??)
#26 70ED9249 gdk_window_update_idle() (D:\Apps\GTK3\bin\libgdk-3-0.dll:??)
#27 70EC183A gdk_threads_dispatch() (D:\Apps\GTK3\bin\libgdk-3-0.dll:??)
#28 685FA30E g_idle_dispatch() (D:\Apps\GTK3\bin\libglib-2.0-0.dll:??)
#29 685F81D3 g_main_dispatch() (D:\Apps\GTK3\bin\libglib-2.0-0.dll:??)

I simply don't know enough about gtk to determine what exactly is happening
here. I am aware that in debug mode msvcrt/malloc do have some weird
memory problems (its a known bug apparently, even though it is rather
sporadic), but the crash also occurs in "release" mode, so it unlikely to be
that msvcrt/malloc issue.

Not quite sure where to take it from here. Any hints/guesses would be
appreciated.

Cheers

DrO

-----Original Message-----
From: vmagnin [mailto:notifications@github.com]
Sent: 10 May 2015 06:16
To: jerryd/gtk-fortran
Cc: DrOli
Subject: Re: [gtk-fortran] gtk fortran winxp undefined reference (#84)

Fine, let us know your progress with Windows.

Concerning the choice of the graphics library, the long-life argument was
important. I still use Fortran programs I wrote nearly 20 years ago, so I
understand this argument. That is why I focused mainly on GTK+ and Qt, which
were both used for more than 10 years and were largely used in the free
software community.

It is true that there is some migrations toward Qt, but I believe/hope that
GTK+ will still be alive in 10 years (in 20 years, I do not know !) because
there is some great projects based on it: GIMP, GNOME and its derivatives,
Inkscape, XFCE... (but LXDE has been ported to Qt...) I think there is room
for many graphics library in the free software landscape. Linux has a market
share around 1% on the desktop but is still alive and well alive ! In free
software, to be in minority is not to be doomed. As long as there is some
people passionate by a project, it can have a long life. But nothing is
sure, rendez-vous in 20 years !

Reply to this email directly or view
#84 (comment) it
on GitHub.
<https://github.com/notifications/beacon/ALdHiruJerBtfoYOZubX6kxVawYG0TLzks5
oHydPgaJpZM4EDeJ9.gif>

[bonanza]

Hey!
I made successful tests under Windows XP to years ago. However, it was a 32bit system. In the meantime I have no more Windows XP running somewhere (and I believe that it's not the best idea to use this Windows generation anymore ...) - therefore it will be a bit difficult for me to help with this issue. Is it necessary for you to get it working with WIndows XP 64? If not, I would suggest to do further work with Windows 7.

Cheerio,
Jens.

[DrOli]

Dear Jens/Vincent:

Many thanks for all the help ... I've made some substantial progress. Many
things are working now (compiled with WinXP64/MingW32 etc, and also
"distributed" to a WinXP32 box).

There are still some issues:

1. gdk_events.mod is not created, since there seems to be no source (.f90)
   or anything from which to create that (I searched all files in case it was
   buried somewhere, but no joy). Thus, it is not possible to compile
   hl_cairo.

Any chance I could dload that (gdk_events) source from somewhere?

2. One of the snags was when searching for all the edits required for GTK3
   (and many thanks for the good effort on that), a couple of the
   "expose-event" bits were not marked for GTK3 update (to "draw"), and it took
   me a little while to find all of those. That made a big difference.

BTW, the use of C_F_Pointer(a,b, (/0/)), i.e. setting the optional Shape arg
to (/0/) seems "un-natural" for those of us coming in as end-users with a
Fortran philosophy (since it implies and array of length 0, though in
reality it is to deal with properties of the c-side pointer) ... as such, I
would add a comment on those lines, as people like me are likely to get
snagged on that.

3. hl_plplot17e crashes on resize on both WinXP64 and 32 ... I can see how
   having a "dynamic/strip" chart could collide with a resize in principle, but
   no idea how GTK deals with that ... any hints as to what to look for there
   would be appreciated.

4. bazaar works on the "dev" machine (WinXP64), but fails on the
   "distributed" WinXP32 machine due "GSetting/schemas" not found etc ... even
   though I had "distributed" all the dll's, schema's, drivers, etc
   (everything else works on the "distributed" WinXP32 machine, save for the
   comments here).

Any hints as to how to "distribute" the schema's would be appreciated (I
tried several different locations/paths for the schema's but no joy on the
distributed machine).

5. Very low priority, but the hl_plplot8e gui save file button is labelled
   "Open", have changed that to "Save" in my copy

6. Cairo-Tests: Fairly problematic. It crashes on most launches in WinXP64
   on the call to "pending_events" inside the double loop creating the image
   (s/r Mandelbrot_set). Every once in a while it does not crash, and
   completes the image, but then crashes as soon as the gui is clicked or
   touched (presumably on the "pending_events" call in the main programme)..

It always launches/completes the image in WinXP32 (the exact same code from
64), but then crashes as soon as the image is finished (presumably on the
"pending_events" call in the main programme).

... it is quite interesting that it should deal reliably with the inner
"pending_events" on WinXP32, but not on 64 etc.

7. hl_plplot4e has a curiosity. If the gui is resized before the selection
   of the second tab, then on selecting the second tab, it is blank/black. If
   the second tab is selected before resize, then the plot shows correctly,
   regardless of later resize etc. Presumably, something gets lost if the
   resize occurs before the image/buffer or something is not
   set/initialised/created.

No idea what to look for here, any hints would be appreciated.

For a variety of reasons, I must develop some of this in WinXP (preferably
64, but MingW32 etc), and will also test later in WinXP64/MingW64. I will
also test in Win7/64, but that is unlikely to be the main dev environment.

Once again, many thanks for all the effort you have put into this.

Cheers

DrO

-----Original Message-----
From: Jens Hunger [mailto:notifications@github.com]
Sent: 10 May 2015 19:32
To: jerryd/gtk-fortran
Cc: DrOli
Subject: Re: [gtk-fortran] gtk fortran winxp undefined reference (#84)

Hey!
I made successful tests under Windows XP to years ago. However, it was a
32bit system. In the meantime I have no more Windows XP running somewhere
(and I believe that it's not the best idea to use this Windows generation
anymore ...) - therefore it will be a bit difficult for me to help with this
issue. Is it necessary for you to get it working with WIndows XP 64? If not,
I would suggest to do further work with Windows 7.

Cheerio,
Jens.

Reply to this email directly or view
#84 (comment) it
on GitHub.
<https://github.com/notifications/beacon/ALdHis20DUPHpBORCejJR60gxioY4GbFks5
oH-IJgaJpZM4EDeJ9.gif>

[DrOli]

oops, in my previous comments on "missing" gdk_events mod in hl_cairo, there was a time when hl_cairo compiled without complaints about missing gdk_events. So, it seems, it must have been there at some point, but it appears to have gone "walkies". I double checked the original dloaded zip, and still no joy. So I am not sure what happened here.

[DrOli]

oops, oops, OK I found gdkevents-auto2.f90 in the "master", and added that to the test_gtk_fortran_1 project/hl_cairo ... it works!

However, it seems pretty certain that f90 is not part of the original test_gtk_fortan_1 gtk_src set, so no idea how come it would compile sometimes, but fail on missing gdk_events at other times.

[DrOli]

BTW, to make it work with GTK3, I made the appropriate edits everywhere you were good enough to mark as GTK3 vs GTK2 (plus a bunch of places which were not marked). However, some of the Module/Use edits to GTK3 resulted with interfaces/routines that were originally in mswindowsonly-auto.f90 (i.e. os-dep) being required in GTK-Auto.f90 (i.e. Module gtk) instead. For example, the GTK2 version has (in gtk-hl-chooser.f90)

use gtk_os_dependent, only: gtk_file_chooser_get_current_folder, &

but, for example, the GTK3 variation had gtk_file_chooser_get_current_folder as part of the Use gtk, Only: ... block, which then causes a conflict with the one in the use gtk_os_dependent block.

So I added a gtk_file_chooser_get_current_folder (and some others) to gtk-auto.f90, and commented out the Use gtk_os_dependent lines.

I am not sure if that was wise. For example, I do plan to also try to run everything in Linux (and if ever possible in Android). Should I have "gone the other way" (i.e. put things into os_dep, and not access them via Module gtk?

... best to know before I make too much investment down this path.

[DrOli]

Update, with most important point left for last.

OK, have completely abandoned GTK3, it's too unstable (on Windows).

Have switched to GTK2 (aka GTK+). On WinXP64/MingW32 all the gtk-fortran/PLPlot/Glade examples work as expected (more or less). Indeed, they execute much faster compared to the GTK3 (e.g. hl_cairo1/cairo_tests is much faster), and are stable (with certain special exceptions).

Distributing all those example exe's to WinXP32 (with necessary libs/paths/env's etc) all work as on the dev WinXP64 machine ... except hl_cairo/cairo_tests, which crash if the completed image/gui is "touched/clicked".

Distributing all those example exe's to Win7/64 (with necessary libs/paths/env's etc) is a different story. The basic gtk exe's work. The hl_cairo/cairo_test exe crash on launch. None of the PLPlot exe's work since it complains about plInitDispatchTable cannot create temporary file, and aborts. I have set all permissions to full everywhere I could see, but no joy.

... any thoughts on getting PLPlot to work on Win7 that would be helpful.

The crashes by hl_cairo/cairo_tests, as before, seem to be in the "pending_events()" call, and the call stack points to malloc in msvcrt as the possible culprit.

Finally, and most important (to me) is getting GTKExtra installed. I've tried building it with MingW/MSys, but I can't figure out how to tell bash where to look for the GTK2 files, and so the make aborts as it can't see the GTK2 files.

... any help at all on this would be EXTREMELY appreciated ... if there is something I could "bribe" with, let me know.

Cheers

DrO

PS, I have started to create a "Do's/Dont's" document for GTK/Glade/Fortran for Windows users. Not sure if that would help, feel free to let me know where to upload such.

[vmagnin]

I close that issue because it is an old post, but don't hesitate to reopen if the problem persists.