Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Linking on Windows #34

Open
waltbrainerd opened this Issue · 52 comments

5 participants

@waltbrainerd

I am having trouble getting my first GTK/Fortran program
to link.

Great project! I am hoping to put links to it on fortran.com
(when I get it to work :-) and include it with our Fortran Tools.

Here is what I have. All the Fortran
programs compile OK. I am using gfortran 4.7 on Windows 7 (64).
I am using bash because of the `tic stuff in the command, but
would like to be able to use it without bash, if possible.

I get the same "invalid argumentr" when trying to compile the
examples running "test.sh".

Help would be appreciated.

Thanks.

walt dot brainerd
gmail dot com

C:\walt\FortranToolsCB\Src\GTK\Test>bash

Walt@HP_Laptop /cygdrive/c/walt/FortranToolsCB/Src/GTK/Test
$ XXX=pkg-config --cflags --libs gtk+-2.0

Walt@HP_Laptop /cygdrive/c/walt/FortranToolsCB/Src/GTK/Test
$ echo $XXX
-mms-bitfields -IC:/walt/FortranToolsCB/Src/GTK/include/gtk-2.0
-IC:/walt/FortranToolsCB/Src/GTK/lib/gtk-2.0/include -IC
:/walt/FortranToolsCB/Src/GTK/include/atk-1.0
-IC:/walt/FortranToolsCB/Src/GTK/include/cairo
-IC:/walt/FortranToolsCB/Sr
c/GTK/include/gdk-pixbuf-2.0
-IC:/walt/FortranToolsCB/Src/GTK/include/pango-1.0
-IC:/walt/FortranToolsCB/Src/GTK/include
/glib-2.0 -IC:/walt/FortranToolsCB/Src/GTK/lib/glib-2.0/include
-IC:/walt/FortranToolsCB/Src/GTK/include -IC:/walt/Fortr
anToolsCB/Src/GTK/include/freetype2
-IC:/walt/FortranToolsCB/Src/GTK/include/libpng14
-LC:/walt/FortranToolsCB/Src/GTK/l
ib -lgtk-win32-2.0 -lgdk-win32-2.0 -latk-1.0 -lgio-2.0
-lpangowin32-1.0 -lgdi32 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lpang
o-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lglib-2.0 -lintl

Walt@HP_Laptop /cygdrive/c/walt/FortranToolsCB/Src/GTK/Test
$ gfortran *.o $XXX
: Invalid argumentr:

Walt@HP_Laptop /cygdrive/c/walt/FortranToolsCB/Src/GTK/Test
$

@jerryd
Owner
@bonanza
Collaborator

I also tried to compile the examples from the gtk2-old branch via test.bat using GTK for Windows (http://ftp.gnome.org/pub/gnome/binaries/win32/gtk+/2.24/gtk+-bundle_2.24.10-20120208_win32.zip).
This results in undefined references:

gtk-hl-container.o:gtk-hl-container.f90:(.text+0x902): undefined reference to `gtk_window_set_icon_from_file'
gtk-hl-chooser.o:gtk-hl-chooser.f90:(.text+0x6f9): undefined reference to `gtk_file_chooser_get_filenames'
gtk-hl-chooser.o:gtk-hl-chooser.f90:(.text+0x721): undefined reference to `gtk_file_chooser_get_current_folder'
gtk-hl-chooser.o:gtk-hl-chooser.f90:(.text+0xb6b): undefined reference to `gtk_file_chooser_set_current_folder'
gtk-hl-chooser.o:gtk-hl-chooser.f90:(.text+0xb98): undefined reference to `gtk_file_chooser_set_current_folder'
gtk-hl-chooser.o:gtk-hl-chooser.f90:(.text+0xbb3): undefined reference to `gtk_file_chooser_select_filename'
gtk-hl-chooser.o:gtk-hl-chooser.f90:(.text+0x1ab9): undefined reference to `gtk_file_chooser_set_current_folder'
gtk-hl-chooser.o:gtk-hl-chooser.f90:(.text+0x1ad9): undefined reference to `gtk_file_chooser_set_current_folder'
gtk-hl-chooser.o:gtk-hl-chooser.f90:(.text+0x1b68): undefined reference to `gtk_file_chooser_set_current_folder'
gtk-hl-chooser.o:gtk-hl-chooser.f90:(.text+0x1b83): undefined reference to `gtk_file_chooser_set_filename'

I also tried the cmake build system under Windows using the CMakeLists.txt files from the master branch (because strange things happened with the files from gtk2-old branch). After changing

install(TARGETS gtk-fortran_static ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR})
install(TARGETS gtk-fortran_shared LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR})

to

install(TARGETS gtk-fortran_static ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR}
RUNTIME DESTINATION ${CMAKE_INSTALL_LIBDIR})
install(TARGETS gtk-fortran_shared LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR}
RUNTIME DESTINATION ${CMAKE_INSTALL_LIBDIR})

in src/CMakeLists.txt and removing gtk-hl-infobar.f90 and gtk-hl-assistant.f90 from the sources list it works so far.
But running make afterwards I get:

...
[ 27%] Building Fortran object src/CMakeFiles/gtk-fortran_shared.dir/pango-auto.f90.obj
gfortran.exe: unrecognized option '-pthread'
Linking Fortran shared library libgtk-2-fortran.dll
Creating library file: libgtk-2-fortran.dll.a
CMakeFiles/gtk-fortran_shared.dir/objects.a(gtk-hl-container.f90.obj):gtk-hl-container.f90:(.text+0x818): undefined reference to `gtk_window_set_icon_from_file'
CMakeFiles/gtk-fortran_shared.dir/objects.a(gtk-hl-chooser.f90.obj):gtk-hl-chooser.f90:(.text+0x6cf): undefined reference to `gtk_file_chooser_get_current_folder'
CMakeFiles/gtk-fortran_shared.dir/objects.a(gtk-hl-chooser.f90.obj):gtk-hl-chooser.f90:(.text+0x6e6): undefined reference to `gtk_file_chooser_get_filenames'
CMakeFiles/gtk-fortran_shared.dir/objects.a(gtk-hl-chooser.f90.obj):gtk-hl-chooser.f90:(.text+0x980): undefined reference to `gtk_file_chooser_set_current_folder'
CMakeFiles/gtk-fortran_shared.dir/objects.a(gtk-hl-chooser.f90.obj):gtk-hl-chooser.f90:(.text+0x99c): undefined reference to `gtk_file_chooser_select_filename'
CMakeFiles/gtk-fortran_shared.dir/objects.a(gtk-hl-chooser.f90.obj):gtk-hl-chooser.f90:(.text+0x11a3): undefined reference to `gtk_file_chooser_set_current_folder'
CMakeFiles/gtk-fortran_shared.dir/objects.a(gtk-hl-chooser.f90.obj):gtk-hl-chooser.f90:(.text+0x1696): undefined reference to `gtk_file_chooser_set_current_folder'
CMakeFiles/gtk-fortran_shared.dir/objects.a(gtk-hl-chooser.f90.obj):gtk-hl-chooser.f90:(.text+0x16af): undefined reference to `gtk_file_chooser_set_filename'
CMakeFiles/gtk-fortran_shared.dir/objects.a(gtk-hl-chooser.f90.obj):gtk-hl-chooser.f90:(.text+0x1e82): undefined reference to `gtk_file_chooser_set_current_folder'
CMakeFiles/gtk-fortran_shared.dir/objects.a(gtk-hl-chooser.f90.obj):gtk-hl-chooser.f90:(.text+0x1f4f): undefined reference to `gtk_file_chooser_set_current_folder'
CMakeFiles/gtk-fortran_shared.dir/objects.a(gdk-pixbuf-hl.f90.obj):gdk-pixbuf-hl.f90:(.text+0x17fa): undefined reference to `gdk_pixbuf_savev'
CMakeFiles/gtk-fortran_shared.dir/objects.a(gdk-pixbuf-hl.f90.obj):gdk-pixbuf-hl.f90:(.text+0x1c84): undefined reference to `gdk_pixbuf_savev'
CMakeFiles/gtk-fortran_shared.dir/objects.a(gdk-pixbuf-hl.f90.obj):gdk-pixbuf-hl.f90:(.text+0x5aa1): undefined reference to `gdk_pixbuf_new_from_file_at_scale'
CMakeFiles/gtk-fortran_shared.dir/objects.a(gdk-pixbuf-hl.f90.obj):gdk-pixbuf-hl.f90:(.text+0x5b7c): undefined reference to `gdk_pixbuf_new_from_file'
collect2: ld returned 1 exit status
make[2]: *** [src/libgtk-2-fortran.dll] Error 1
make[1]: *** [src/CMakeFiles/gtk-fortran_shared.dir/all] Error 2
make: *** [all] Error 2

It looks like incompatible libraries, but the GTK Windows bundle contains GTK+ 2.24.10 and GLib 2.28.8 and should therefore be compatible with the gtk2-old branch. Any ideas?

@jtappin
Collaborator

Hi Jens

Not sure I can be that much help except to note that according to the Gtk+ documentation page, the routines giving the errors were all introduced early in the 2.x cycle (2.2 or 2.4) so they ought to be there.

I guess one thing to check is whether the interfaces are in the auto-generated files, but I think that that should cause an error at an earlier stage.

I don't have a Windows machine to do any tests and I'm not at all familiar with Windows libraries or development.

@vmagnin
Collaborator

Note that test.bat is not maintained. We are lacking someone working fully under Windows.
I remember that I had also that kind of errors with for example the g_usleep function when I made some tests last summer.

It could be interesting to test GTK+ 3 for Windows. There is no official version by now, but I found a french developper who is publishing GTK+ 3.6.1 for Windows 32 bits:
http://www.tarnyko.net/?q=node/22
(I have not tested it...)

@bonanza
Collaborator

I found the following sections in the GTK include files:

/* Filename manipulation
 */
#ifdef G_OS_WIN32
/* Reserve old names for DLL ABI backward compatibility */
#define gtk_file_chooser_get_filename gtk_file_chooser_get_filename_utf8
#define gtk_file_chooser_set_filename gtk_file_chooser_set_filename_utf8
#define gtk_file_chooser_select_filename gtk_file_chooser_select_filename_utf8
#define gtk_file_chooser_unselect_filename gtk_file_chooser_unselect_filename_utf8
#define gtk_file_chooser_get_filenames gtk_file_chooser_get_filenames_utf8
#define gtk_file_chooser_set_current_folder gtk_file_chooser_set_current_folder_utf8
#define gtk_file_chooser_get_current_folder gtk_file_chooser_get_current_folder_utf8
#define gtk_file_chooser_get_preview_filename gtk_file_chooser_get_preview_filename_utf8
#define gtk_file_chooser_add_shortcut_folder gtk_file_chooser_add_shortcut_folder_utf8
#define gtk_file_chooser_remove_shortcut_folder gtk_file_chooser_remove_shortcut_folder_utf8
#define gtk_file_chooser_list_shortcut_folders gtk_file_chooser_list_shortcut_folders_utf8
#endif
#ifdef G_OS_WIN32
/* Reserve old names for DLL ABI backward compatibility */
#define gtk_window_set_icon_from_file gtk_window_set_icon_from_file_utf8
#define gtk_window_set_default_icon_from_file gtk_window_set_default_icon_from_file_utf8
#endif

I guess, these preprocessor macros are ignored somehow.

@jtappin
Collaborator

I think I see what's happening:
cfwrapper.py does not interpret #defines so the gtk-auto.f90 interface file contains the public names.
On Windows, the actual names (in gtkfilechooser.c etc.) are the _utf8 forms and the defines modify the "standard" names (both in the headers and in the user programs) to be the _utf8 forms.

I principle it ought to be possible to use the bind(c,name=...) construction to do the mapping, but that would have two problems: Firstly it would be necessary to maintain 2 codebases; and Secondly it would be hard to figure out which defines were relevant (and some of the defines in the gtk headers are pretty messy).

@vmagnin
Collaborator

I have looked for #ifdef G_OS_WIN32 in the /usr/include directory and found these number of occurences:
glib-2.0 : 18
gdk-pixbuf-2.0 : 3
gtk-2.0 : 11
gtk-3.0 : 1 (but it's not about _utf8 forms)

When GTK+ 3 will be officially released for Windows, there will be no problem except with glib and gdk-pixbuf functions.

I confirm that cfwrapper.py is deleting all the lines beginning by # in the C header files.

@bonanza
Collaborator

I think, for larger projects functions from glib and gdk-pixbuf (e.g. gobject, locales, custom icons) are needed. Maybe it is possible to get the current platform in cfwrapper.py automatically (or even make it possible to choose the platform via a command line argument) and do mapping of the Windows functions in case of G_OS_WIN32 is defined? I have some computers running Windows and can test all the Windows stuff. Also, I started some larger projects which are intended to be available for Windows users.

@vmagnin
Collaborator

An idea to implement the _utf8 windows functions:
1) for each function "a_function", cfwrapper.py would look in the original C header file for a line like "#define a_function a_function_utf8" (this regular expression seems to work correctly: "^#define (\w+) \1_utf8"),
2) if such a line is found, the function interface would be duplicated with the name "a_function_utf8",
3) so the gtk-fortran files would contain both "a_function" and "a_function_utf8". Unix developers would use "a_function" and Windows developers would use "a_function_utf8". If a function does not exist on your system, there should be no problem if you do not use it. There would be no error when building gtk-fortran.

Any comment on that idea ?

Note that I have no more system with GLib 2.28.8. I can try with GTK+ 2.24.13, GLib 2.34.1 and GTK+ 3.6.0, GLib 2.34.1.

@vmagnin vmagnin was assigned
@bonanza bonanza was assigned
@vmagnin vmagnin was assigned
@bonanza
Collaborator

Your idea sounds reasonable to me. Cross platform developers then will be able to use the built in cpp (http://gcc.gnu.org/onlinedocs/gfortran/Preprocessing-Options.html). IMHO it will be desirable to care for the scope of gtk-fortran as a cross platform tool using the different official library versions for different platforms. But I also think that the goal should be to have only one codebase - if possible.

As said earlier, I have several Windows systems where I can (and will) test and develop with GLib 2.28.8. But I have also no Linux system with such old versions.

@vmagnin
Collaborator

Yes, the cross platform goal was initially one of my main motivations to begin gtk-fortran.

Should the few differences between platforms be contained in the gtk-fortran files or in the developers files ? The problem with the first solution is that maintaining more branches is time consuming and error prone.

If we decide to let the problem on the Windows developers' side, we could perhaps imagine to write a script that could swap the normal and _utf8 forms in the developers' code ?

James, what is your opinion ?

Jens, do you think this _utf8 problem concerns only old windows versions (XP...) or also Windows 7 and 8 ? And does it only concern the 32 bits versions (#ifdef G_OS_WIN32) or also the 64 bits ?

@jtappin
Collaborator

Vincent,
I don't have particularly strong views on this, as I do not use Windows (the last version that I used more than once or twice was Win95) and have never developed for the platform.

Generally I think it's probably better to handle the differences between platforms at the library level if possible (that is part of the thinking behind the high-level interfaces which offer the same API for both Gtk2 & Gtk3).

I think most Fortran compilers allow the use of the C-preprocessor by naming the file .F90 instead of .f90 so that might be worth investigating -- I don't think it would be hard to get cmake to generate a header file that defined things like OS_WIN32 or the GTK version.

@vmagnin
Collaborator

My cfwrapper.py is now able to find the _utf8 functions.

Idea: I could put the normal forms in a "unix-auto.f90" file and the _utf8 forms in a "mswindows-auto.f90" file.

The "unix-auto.f90" file would contain for example:

function g_get_user_name() bind(c) 
  use iso_c_binding, only: c_ptr
  type(c_ptr) :: g_get_user_name
end function

And the "mswindows-auto.f90" file would contain:

function g_get_user_name() bind(c, name='g_get_user_name_utf8') 
  use iso_c_binding, only: c_ptr
  type(c_ptr) :: g_get_user_name
end function

The developers, Unix or Windows, would always use the normal form g_get_user_name() (a warning would be added in the Wiki).

And if there are other types of specific Windows functions, they would be dispatched similarly.

James, is CMake able to determine the platform and to chose the right file ?

@jtappin
Collaborator

Vincent

At the top level I think it's quite easy - in fact I can think of two ways to do it.
In either case I think we need the separation to be at the modules level (e.g. g-unix-auto.f90 and g-mswindows-auto.f90).
First

if (CMAKE_HOST_WIN32)
  set(sysname "mswindows")
else()
  set(sysname "unix")
endif()

And then have the affected source files referred to in the CMakeLists.txt as g-${sysname}-auto.f90

The alternative is just to bracket those files that need to be different with similar conditionals (I'd need to test to see if that is allowed). e.g.

set (sources
   if (CMAKE_HOST_WIN32)
      g-mswindows-auto.f90
      gdk-pixbuf-mswindows-auto.f90
  else()
      g-unix-auto.f90
      gdk-pixbuf-unix-auto.f90
  endif()
  .
  .
  .

For the gtk.f90 file whether there is an include, I think that (if it's needed in that case) both files would need to be flagged otherwise we would need either to use the c pre-processor or a special sed command to make the conversion.

BTW, the cmake documentation explicitly states that CMAKE_HOST_WIN32 is set on 64-bit Windows as well as 32-bit.

@bonanza
Collaborator

The problems concern also the 64bit Windows versions where G_OS_WIN32 and additionally _WIN64 are defined. But the latter seems to be relevant only for get_package_installation_directory functions (http://developer.gnome.org/glib/2.28/glib-Windows-Compatibility-Functions.html).

@vmagnin
Collaborator

My idea is to have only two supplementary files named "mswindowsonly-auto.f90" and "unixonly-auto.f90", containing the modules mswindowsonly and unixonly. Each contains 33 platform specific functions. Do you agree with the names ?

I have pushed a new branch in GitHub: testwin32gtk3. It seems gdk-pixbuf-hl.f90 must be adapted.

When it's OK we will test it also with gtk2.

@jtappin
Collaborator

Vincent,
I think the module name needs to be the same in both files. For example gtk_os_dependent so that use programs and the high-level modules don't need to be modified between OS's. Since only one will get compiled there shouldn't be a clash.

@jtappin
Collaborator

The system now builds with the above change and a fix to gdk-pixbuf-hl.f90, but as it stands, the automated module scanning is broken as the .csv file has the source package rather than the final module in the first column.

I think the answer to this is to in those routines that are in the os-dependent module the index record should be something like:

<module>;<public name>;unixonly-auto.f90/mswindowsonly-auto.f90;<the rest as before>

e.g. for gdk_pixbuf_savev instead of:

gdk_pixbuf;gdk_pixbuf_savev;unixonly-auto.f90;/usr/include/gdk-pixbuf-2.0/gdk-pixbuf/gdk-pixbuf-core.h;" gboolean gdk_pixbuf_savev (GdkPixbuf *pixbuf, const char *filename, const char *type, char **option_keys, char **option_values, GError **error);"
gdk_pixbuf;gdk_pixbuf_savev_utf8;mswindowsonly-auto.f90;/usr/include/gdk-pixbuf-2.0/gdk-pixbuf/gdk-pixbuf-core.h;" gboolean gdk_pixbuf_savev (GdkPixbuf *pixbuf, const char *filename, const char *type, char **option_keys, char **option_values, GError **error);"

we would have:

gtk_os_dependent;gdk_pixbuf_savev;unixonly-auto.f90/mswindowsonly-auto.f90;/usr/include/gdk-pixbuf-2.0/gdk-pixbuf/gdk-pixbuf-core.h;" gboolean gdk_pixbuf_savev (GdkPixbuf *pixbuf, const char *filename, const char *type, char **option_keys, char **option_values, GError **error);"

I have made the necessary changes but now I am seeing a problem in the enumerators file (even with an unmodified cfwrapper.py) where /usr/include/gtk-3.0/gtk/deprecated/gtkrc.h is being scanned before /usr/include/glib-2.0/glib/gscanner.h with the result that G_TOKEN_LAST is used before it is defined. Should we even be scanning in the deprecated subdirectory?

@jtappin
Collaborator

After reordering the PATH_DICT as:

PATH_DICT = { "/usr/include/gtk-3.0/unix-print":"unix-print-auto.f90",
              "/usr/include/cairo":"cairo-auto.f90",
              "/usr/include/pango-1.0":"pango-auto.f90",
              "/usr/include/glib-2.0":"glib-auto.f90",
              "/usr/include/atk-1.0":"atk-auto.f90",
              "/usr/include/gtk-3.0/gdk":"gdk-auto.f90",
              "/usr/include/gdk-pixbuf-2.0":"gdk-pixbuf-auto.f90",
              "/usr/include/gtk-3.0/gtk":"gtk-auto.f90",}

it seems to work at least sometimes.

Vincent do you have any objections to my pushing the changes described above (with a correctly ordered enums file)?

@vmagnin
Collaborator

You are right, there should be two files but only one module name. OK for gtk_os_dependent.

It should be quite easy to exclude the "deprecated" directory, but I do not yet understand what caused the G_TOKEN_LAST problem. I have just written the specific functions in two additional files. Moreover, cfwrapper.py is detecting the enumerators in a first pass and the functions during the second pass.

In fact I just remember something: in python the dictionnaries are not ordered ! So you have no guarantee on the effective order (as you say it works "at least sometimes") when you iterate... Ordered dictionnaries exist only in python3. I perhaps found a workaround here:
http://stackoverflow.com/questions/364519/in-python-how-to-i-iterate-over-a-dictionary-in-sorted-order

You can push your changes. I will have a look.

@jtappin
Collaborator

Vincent,

I've pushed the changes (of course lots of the differences are just because things got processed in different orders).

It's pretty clear what is happening with G_TOKEN_LAST at least at the top level-- it is defined in glib (/usr/include/glib-2.0/glib/gscanner.h), but it is used in /usr/include/gtk-3.0/gtk/deprecated/gtkrc.h so if the latter file gets processed before the former then gfortran croaks because G_TOKEN_LAST has not been defined.

@vmagnin
Collaborator

On my PC, the paths were explored in that order:

['/usr/include/atk-1.0', '/usr/include/glib-2.0', '/usr/include/cairo', '/usr/include/pango-1.0', '/usr/include/gtk-3.0/unix-print', '/usr/include/gtk-3.0/gdk', '/usr/include/gdk-pixbuf-2.0', '/usr/include/gtk-3.0/gtk']

But perhaps on yours it were different...

I have sorted the keys of the dictionnary and obtained that order:

['/usr/include/atk-1.0', '/usr/include/cairo', '/usr/include/gdk-pixbuf-2.0', '/usr/include/glib-2.0', '/usr/include/gtk-3.0/gdk', '/usr/include/gtk-3.0/gtk', '/usr/include/gtk-3.0/unix-print', '/usr/include/pango-1.0']

Of course, the fact that this order is OK is just a chance ! I have added some comments on that fact.

Everything seems OK with CMake. So I have pushed my changes.

If you think it is ready, you can create a branch testwin32gtk2 from the master or gtk2-old branch (it depends on Jens, and we should also be carreful with the glib version). You can copy the last testwin32gtk3 cfwrapper.py and just comment the GTK+3 dictionnary and uncomment the GTK+2 dictionnary I have added (lines 294-310). I guess some other files should be adapted in HL and CMake...

@bonanza
Collaborator

Great work! Thanks.
I'll test under Windows both GTK+2 (please use the gtk-old branch since this is based on the official Windows GLib version) and GTK+3 versions if you think that everything is OK so far.

@jtappin
Collaborator

I guess that would need to be done on one of the VMs that still have an old glib (I think the Xubuntu 11.10 would be suitable).

That has Glib 2.30 -- is that appropriate?

@bonanza
Collaborator

I don't know exactly, but the official stable win32 GLib version is 2.28.8.
This version is also available in Ubuntu Oneiric (11.10) - which is still downloadable (http://releases.ubuntu.com/11.10/)

@jtappin
Collaborator

I think that the only system I have that has 2.28 is irretrievably broken.

** Correction ** Not totally broken, just limited to 1024x768

As I recall the disruptive change was at 2.32 when some incompatible changes were made to the handling of char types in the gvalue routines that made a real mess of the list/tree handling. There are a number of new symbols in 2.30, but I think that unless they are accessed they will be harmless.

@jtappin
Collaborator

OK having had a think here's what I suggest.

Work off the current gtk2 (master) branch. That way all the newer goodies in HL (there's nothing there that depends on Gtk3) , and the c_int /= Fortran Integer fixes will be available and since we are going to fully regenerate all the auto files the Gtk & Glib versions of the base branch don't matter.

Update cfwrapper.py as Vincent describes and make the necessary changes to src/CMakeList.txt. Rebuild the auto files on the outdated Pardus system, which has Glib 2.28, and also the high-level files from their templates.

Regenerate the events module and enumerator listing files.

Test at least the main examples -- plplot is definitely broken on that VM.

Commit as testwin32gtk2

@jtappin
Collaborator

The testwin32gtk2 branch is now created.

@vmagnin
Collaborator

I have tested testwin32gtk2 with Ubuntu 12.10 (GTK+ 2.24.13, GLib 2.34.1). It seems OK.

Note that I have updated the wiki page about git:
https://github.com/jerryd/gtk-fortran/wiki/git-basics
(I always need it when I have not worked on the project for a while !)

@bonanza
Collaborator

I tested the testwin32gtk2 branch with Windows XP.
First, there was a cmake error:

CMake Error at src/CMakeLists.txt:72 (add_library):
  Cannot find source file:

    mswindowsonly-auto.f90

And if I use the mswindowsonly-auto.f90 from the testwin32gtk3 branch I get the following error with mingw32-make:

C:\gtk-fortran-testwin32gtk2\src\gtk-hl-assistant.f90:61.29:

  use gtk_os_dependent, only: gtk_window_set_icon_from_file
                             1
Error: Symbol 'gtk_window_set_icon_from_file' referenced at (1) not found in module 'gtk_os_dependent'
C:\gtk-fortran-testwin32gtk2\src\gtk-hl-assistant.f90:191.17:

       icon_ok = gtk_window_set_icon_from_file (asstnt, icon_file, c_null_ptr)
                 1
Error: Function 'gtk_window_set_icon_from_file' at (1) has no IMPLICIT type
@vmagnin
Collaborator

Jens, I do not know if you have a Unix shell on your Windows system (Cygwin ?). If it is the case and if you have installed python2, you can generate the gtk-fortran files (including mswindowsonly-auto.f90) by typing:
python cfwrapper.py

@jtappin
Collaborator

Error between chair & keyboard. I forgot the git add for the 2 new modules. Corrected.

P.S. I know the update time is a little odd -- Pardus assumes local time clock, but VirtualBox uses the host clock.

@bonanza
Collaborator

The result of cfwrapper.py using Python for Windows (after adjusting the include paths):

Pass 1: looking for enumerators...
Pass 2: looking for C functions...
C:/gtk/include/atk-1.0/atk
C:/gtk/include/cairo
C:/gtk/include/gdk-pixbuf-2.0/gdk-pixbuf
C:/gtk/include/glib-2.0
C:/gtk/include/gtk-2.0/gdk
C:/gtk/include/gtk-2.0/gtk
C:/gtk/include/pango-1.0/pango

=== Statistics ===
nb_files scanned = 524
nb_generated_interfaces = 8737
nb_type_errors = 130
nb_errors (others) = 283
nb_lines treated = 23102
nb_variadic functions = 83
@bonanza
Collaborator

Now mingw32-make is able to build the libraries:

C:\gtk-fortran-testwin32gtk2\build>mingw32-make
Scanning dependencies of target gtk-fortran_shared
[  1%] Building Fortran object src/CMakeFiles/gtk-fortran_shared.dir/glib-auto.f90.obj
[  2%] Building Fortran object src/CMakeFiles/gtk-fortran_shared.dir/gdk-auto.f90.obj
[  3%] Building Fortran object src/CMakeFiles/gtk-fortran_shared.dir/gtk.f90.obj
[  4%] Building Fortran object src/CMakeFiles/gtk-fortran_shared.dir/gtk-hl-accelerator.f90.obj
[  5%] Building Fortran object src/CMakeFiles/gtk-fortran_shared.dir/mswindowsonly-auto.f90.obj
[  6%] Building Fortran object src/CMakeFiles/gtk-fortran_shared.dir/gtk-hl-assistant.f90.obj
[  7%] Building Fortran object src/CMakeFiles/gtk-fortran_shared.dir/gtk-sup.f90.obj
[  8%] Building Fortran object src/CMakeFiles/gtk-fortran_shared.dir/gtk-hl-misc.f90.obj
[  9%] Building Fortran object src/CMakeFiles/gtk-fortran_shared.dir/gtk-hl-button.f90.obj
[ 10%] Building Fortran object src/CMakeFiles/gtk-fortran_shared.dir/gtk-hl-container.f90.obj
[ 11%] Building Fortran object src/CMakeFiles/gtk-fortran_shared.dir/gtk-hl-entry.f90.obj
[ 12%] Building Fortran object src/CMakeFiles/gtk-fortran_shared.dir/gtk-hl-chooser.f90.obj
[ 13%] Building Fortran object src/CMakeFiles/gtk-fortran_shared.dir/gtk-hl-combobox.f90.obj
[ 14%] Building Fortran object src/CMakeFiles/gtk-fortran_shared.dir/gtk-hl-dialog.f90.obj
[ 15%] Building Fortran object src/CMakeFiles/gtk-fortran_shared.dir/gtk-hl-infobar.f90.obj
[ 16%] Building Fortran object src/CMakeFiles/gtk-fortran_shared.dir/gtk-hl-menu.f90.obj
[ 17%] Building Fortran object src/CMakeFiles/gtk-fortran_shared.dir/gtk-hl-progress.f90.obj
[ 18%] Building Fortran object src/CMakeFiles/gtk-fortran_shared.dir/gtk-hl-spin-slider.f90.obj
[ 20%] Building Fortran object src/CMakeFiles/gtk-fortran_shared.dir/gdk-pixbuf-auto.f90.obj
[ 21%] Building Fortran object src/CMakeFiles/gtk-fortran_shared.dir/gtk-hl-tree.f90.obj
[ 22%] Building Fortran object src/CMakeFiles/gtk-fortran_shared.dir/cairo-auto.f90.obj
[ 23%] Building Fortran object src/CMakeFiles/gtk-fortran_shared.dir/atk-auto.f90.obj
[ 24%] Building Fortran object src/CMakeFiles/gtk-fortran_shared.dir/gdk-pixbuf-hl.f90.obj
[ 25%] Building Fortran object src/CMakeFiles/gtk-fortran_shared.dir/gdkevents-auto2.f90.obj
[ 26%] Building Fortran object src/CMakeFiles/gtk-fortran_shared.dir/gtk-draw-hl.f90.obj
[ 27%] Building Fortran object src/CMakeFiles/gtk-fortran_shared.dir/gtk-hl.f90.obj
[ 28%] Building Fortran object src/CMakeFiles/gtk-fortran_shared.dir/pango-auto.f90.obj
Linking Fortran shared library libgtk-2-fortran.dll
[ 28%] Built target gtk-fortran_shared
Scanning dependencies of target gtk-fortran_static
[ 29%] Building Fortran object src/CMakeFiles/gtk-fortran_static.dir/glib-auto.f90.obj
[ 30%] Building Fortran object src/CMakeFiles/gtk-fortran_static.dir/gdk-auto.f90.obj
[ 31%] Building Fortran object src/CMakeFiles/gtk-fortran_static.dir/gtk.f90.obj
[ 32%] Building Fortran object src/CMakeFiles/gtk-fortran_static.dir/gtk-hl-accelerator.f90.obj
[ 33%] Building Fortran object src/CMakeFiles/gtk-fortran_static.dir/mswindowsonly-auto.f90.obj
[ 34%] Building Fortran object src/CMakeFiles/gtk-fortran_static.dir/gtk-hl-assistant.f90.obj
[ 35%] Building Fortran object src/CMakeFiles/gtk-fortran_static.dir/gtk-sup.f90.obj
[ 36%] Building Fortran object src/CMakeFiles/gtk-fortran_static.dir/gtk-hl-misc.f90.obj
[ 37%] Building Fortran object src/CMakeFiles/gtk-fortran_static.dir/gtk-hl-button.f90.obj
[ 38%] Building Fortran object src/CMakeFiles/gtk-fortran_static.dir/gtk-hl-container.f90.obj
[ 40%] Building Fortran object src/CMakeFiles/gtk-fortran_static.dir/gtk-hl-entry.f90.obj
[ 41%] Building Fortran object src/CMakeFiles/gtk-fortran_static.dir/gtk-hl-chooser.f90.obj
[ 42%] Building Fortran object src/CMakeFiles/gtk-fortran_static.dir/gtk-hl-combobox.f90.obj
[ 43%] Building Fortran object src/CMakeFiles/gtk-fortran_static.dir/gtk-hl-dialog.f90.obj
[ 44%] Building Fortran object src/CMakeFiles/gtk-fortran_static.dir/gtk-hl-infobar.f90.obj
[ 45%] Building Fortran object src/CMakeFiles/gtk-fortran_static.dir/gtk-hl-menu.f90.obj
[ 46%] Building Fortran object src/CMakeFiles/gtk-fortran_static.dir/gtk-hl-progress.f90.obj
[ 47%] Building Fortran object src/CMakeFiles/gtk-fortran_static.dir/gtk-hl-spin-slider.f90.obj
[ 48%] Building Fortran object src/CMakeFiles/gtk-fortran_static.dir/gdk-pixbuf-auto.f90.obj
[ 49%] Building Fortran object src/CMakeFiles/gtk-fortran_static.dir/gtk-hl-tree.f90.obj
[ 50%] Building Fortran object src/CMakeFiles/gtk-fortran_static.dir/cairo-auto.f90.obj
[ 51%] Building Fortran object src/CMakeFiles/gtk-fortran_static.dir/atk-auto.f90.obj
[ 52%] Building Fortran object src/CMakeFiles/gtk-fortran_static.dir/gdk-pixbuf-hl.f90.obj
[ 53%] Building Fortran object src/CMakeFiles/gtk-fortran_static.dir/gdkevents-auto2.f90.obj
[ 54%] Building Fortran object src/CMakeFiles/gtk-fortran_static.dir/gtk-draw-hl.f90.obj
[ 55%] Building Fortran object src/CMakeFiles/gtk-fortran_static.dir/gtk-hl.f90.obj
[ 56%] Building Fortran object src/CMakeFiles/gtk-fortran_static.dir/pango-auto.f90.obj
Linking Fortran static library libgtk-2-fortran.a
[ 56%] Built target gtk-fortran_static
Scanning dependencies of target manpage
[ 57%] Generating gtk-2-fortran-modscan.1
Der Befehl "sed" ist entweder falsch geschrieben oder
konnte nicht gefunden werden.
src\CMakeFiles\manpage.dir\build.make:53: recipe for target 'src/gtk-2-fortran-modscan.1' failed
mingw32-make[2]: *** [src/gtk-2-fortran-modscan.1] Error 1
CMakeFiles\Makefile2:250: recipe for target 'src/CMakeFiles/manpage.dir/all' failed
mingw32-make[1]: *** [src/CMakeFiles/manpage.dir/all] Error 2
Makefile:145: recipe for target 'all' failed
mingw32-make: *** [all] Error 2

But it looks like I have to install sed for windows now ...

@jtappin
Collaborator

Actually that whole area probably needs some work,: as that is trying to generate a man page for the module scanner
1) Are man pages even useful in Windows?
2) What is the best way to install a perl script as a program?
etc.

@vmagnin
Collaborator

Good, with cfwrapper.py you have a gtk-fortran perfectly adapted to your GTK+ and glib versions.

Concerning CMake, in the meantime you can try to work with the test.sh script. It's basic but can be useful. Although I do not know if it will find the GTK dll in your system...

when you have time, I also think it could be useful to write something on the wiki page about the installation and use of gtk-fortran under Windows. I made some tests but it was very basic: just putting the GTK+ dlls in the same directory as the gtk-fortran files...

@jtappin jtappin was assigned
@bonanza
Collaborator

I think, the goal is to get the cmake build system working also under Windows.
I will write something on the wiki page about the key points of installation and use of gtk-fortran under Windows - but not before first week of march.

@jtappin
Collaborator

Jens,
I agree there -- the old build scripts were a useful start but they aren't really maintainable and aren't that portable.

If you find differences that are needed or bits that are relevant to only one platform in the CMakeLists.txt files, then they can be wrapped in

if (WIN32)
else()
endif()

or

if (UNIX)
else()
endif()

constructs.

@bonanza
Collaborator

OK, I'll go through the CMakeLists.txt files and try to get something to work under Windows.
However, there is some equivalent to man pages under Windows (called by CommandName /?). But I think, it is not really needed here at the moment.
Concerning perl scripts under Windows: http://www.planet-source-code.com/vb/scripts/ShowCode.asp?txtCodeId=796&lngWId=6

@bonanza
Collaborator

I committed modified CMakeLists.txt files (working under Windows XP 32bit) to the testwin32gtk2 branch and also added a build script for Windows. Using that script all gtk-fortran files are compiled after downloading and installing free third party software (wget, MinGW, CMake, GTK, sed), if needed.
However, there are several runtime errors with the examples using the official GTK for Windows bundle (GTK+ 2.24.10 and GLib 2.28.8):

symbols not found:

  • gtk_table_get_size (hl_assistent, hl_cairo_clock, hl_choosers, hl_containers, hl_dialog, hl_menu, hl_pbar, hl_pbar_p, hl_radio, hl_sliders, hl_sliders2, hl_textview)
  • gdk_device_get_name (hl_cairo1)
  • gtk_info_bar_add_button (hl_infobar)
  • gtk_cell_renderer_set_alignment (hl_list1, hl_list_n, hl_list_renderers, hl_tree)
  • gtk_notebook_set_group_name (notebooks)
  • g_hostname_is_ip_address (tests)

also, gtkbuilder.glade is not found by the examples which are using this file.

@vmagnin
Collaborator

The GTK+ doc says gtk_cell_renderer_set_alignment is available since 2.18 and gtk_table_get_size since 2.22. I remembered a problem under windows with a glib function that should have been present but was not. I looked for it in the binary of the DLL file but did not find its name.
Could you have a look in the DLLs to see if these names are present ?

@jtappin
Collaborator

I can't see anything odd about the declarations for those routines..

Have you tried running cfwrapper.py (in a fresh directory) and then seeing if those routines are found in the headers?

Not a solution to this problem, but gtk_table_get_size can probably be eliminated as there is no equivalent in GtkGrid (the gtk 3 replacement for GtkTable) and although it's not actually advertised resizing tables by adding a row or column outside the current limits works in gtk 2.24 (maybe not in earlier versions but they have other issues).

@bonanza
Collaborator

Sorry, my fault: There were some older libgtk versions in PATH before the current version (installed by some other software, namely Graphviz and GTK2-Runtime).
I changed that and all is working like a charm now! Great.
Now it's time to write something on the wiki page about installation and use of gtk-fortran under Windows.
I'll also test the GTK3 branch under Windows now.

@jtappin
Collaborator

Good that it's resolved as if it had been a real issue it looked like it might be quite tricky. There should probably be a warning about that possibility when you come to write up the Windows howto.

@bonanza
Collaborator

I was successful in testing the testwin32gtk3 branch using the GTK+ 3.6.1 version of tarnyko out of the box, that means without invoking cfwrapper.py. I committed a Windows build script and modified CMakeLists.txt files to the testwin32gtk3 branch. I think, this branch can now be merged with the gtk3 branch.

However, one small issue remains:
With the gtkbuilder2 example the signal handlers are not found and therefore the program has to be stopped via Ctrl-C:

Running: gtkbuilder2.exe
(gtkbuilder2.exe:105576): Gtk-WARNING **: Could not find signal handler 'destroy'
(gtkbuilder2.exe:105576): Gtk-WARNING **: Could not find signal handler 'delete_event'
(gtkbuilder2.exe:105576): Gtk-WARNING **: Could not find signal handler 'destroy'
(gtkbuilder2.exe:105576): Gtk-WARNING **: Could not find signal handler 'button2clicked'
(gtkbuilder2.exe:105576): Gtk-WARNING **: Could not find signal handler 'hello'
Terminating on signal SIGINT(2)

I'll have a detailed look on this problem tomorrow.

@jtappin
Collaborator

I recall seeing the same problem on PC BSD. libgmodule was not being loaded in that case.

@bonanza
Collaborator

Yes, that's correct (#49).
Looks like the same problem.
Maybe it helps to add the result of pkg-config --libs gmodule-2.0 (this gives result of pkg-config --libs glib-2.0 + -lgmodule-2.0) somewhere via cmake? But I have no idea how this can be done in a correct way.

@bonanza
Collaborator

I added PLplot support via the win32_build.bat script to testwin32gtk3 branch. It was a bit tricky because cmake automatic detection of PLplot is not working on Windows.
gtk-fortran with GTK+3 can now be build completely on Windows - the only remaining problem: gtkbuilder2.

@bonanza
Collaborator

I did a rewrite of the Windows installation wiki page section.
Maybe it will be appropriate to create a separate wiki page for installation instructions?

@vmagnin
Collaborator

Good !
Yes, it would be better to have a separate page for the installation instructions which are becoming quite long.

@waltbrainerd

I tried this again and still can't get things to work.

I downloaded the "master" gtk-fortran again. Tried cmake as in
the Install instructions. Tried compiling all the .f90 files (they all
compile), Can't figure out how to create a running program that
uses them. The pkg-configure thing didn't work. cmake says my
gfortran won't compile anything (it really does).

Now I am on Windows 7 with gfortran 4.8.1 with Mingw.
I have a full cygwin installed.

Any more pointers? Is it now supposed to work on Windows?

Is there more documentation somewhere?

How do you post something on Git Hub? Didn't see how to do
that, either.

Any help would be appreciated. I have queries asking about
creating dialogs and such with gfortran. I would like to point
them to gtk-fortran.

@waltbrainerd

Oh, the above was not quite correct.

When compiling, I got an argument mismatch, which
I "fixed" by changing gtk-sup.f90, line 60 from

"c_long" to "c_size_t"

I have no idea if this make any sense.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.