Any Success Building GTK+ Apps w/ IVF?

[Jeffrey_K_]

All,

I have become interested with the GTK+ (GIMP Toolkit) Project (http://www.gtk.org/) as an alternate GUI builder for my Windows projects. A user has developed a fortran Library to interface w/ GTK+ environment called gtk-fortran (https://github.com/jerryd/gtk-fortran/wiki). I have followed his instructions to build a supplied demo code using GNU Fortran in the Code::Blocks IDE & it builds/executes fine :-)

However, I had difficulty getting Code::Blocks to work w/ IVF so I tried to build the GTK+ fortran demo in IVF (XE 14.0.4.237) as a Windows App...and had problems. I get this linker error:

Error    42     error LNK2019: unresolved external symbol _WinMain@16 referenced in function ___tmainCRTStartup    MSVCRTD.lib(crtexew.obj)    

and can't figure out to correct it. *HOWEVER*, it compiles & links fine...as a Console App but, of course, it does not execute correctly. What is the secret to correcting that WinMain@16 error?

Thanks in advance,

Jeff

[Steven_L_Intel1]

You've created a "Windowing application" and this requires that you supply a function called WinMain with that entry point. I suspect you're chasing the wrong problem, though. If it works in a simple gfortran build, which is unlikely to be a windowing application, it should work in ifort. What goes wrong as a console build?

To read more about windowing applications, see https://software.intel.com/sites/products/documentation/hpc/composerxe/en-us/fortran/win/pdf/Creating_Fortran_Win_Apps.pdf

[Jeffrey_K_]

Steve,

Gee, the GTK+ programs sure look look like Windows apps to me ;-)

"...this requires that you supply a function called WinMain with that entry point.'

This is not true in every instance. I also program using the Winteracter package (a Fortran GUI builder you have to pay for) & nowhere do i have to use a WinMain function. Wineracter uses instead (I presume) "CALL WInitialise()" which, after that, you can create & manipulate the Windows environment. I presume the GTK+ environment is the same - here is the 'Main' routine:

program gui_main
    use iso_c_binding
    use gtk, only: gtk_init, gtk_main
    use gui_functions
    implicit none

    type(window) :: demo_win

    call gtk_init()

    call create_window(demo_win,"test.glade"//c_null_char)

    call show_window(demo_win)

    call gtk_main()
end program gui_main

I'll see if I can attach screenshots of the Demo program that works from GFortran & the IVF 'Console' version that...sorta works. The IVF version, when the window appears & you go to enter the requested text, clicking the 'Say Hello' button causes it to crash.

Thanks for your help,

Jeff

[Steven_L_Intel1]

Winteracter probably supplies its own WinMain.

Try creating a new project as a QuickWin application and see what happens. Can you show me how the gfortran applcation is built? (What options are used.)

[Jeffrey_K_]

Steve,

I tried both Quickwin & the Standard Graphics options - they both essentially executed the same as the Console option. The compile error for Win32 has changed a bit, though, now that I have some Linker 'Additional Dependentcies' set correctly:

1>LIBCMT.lib(wincrt0.obj) : error LNK2019: unresolved external symbol _WinMain@16 referenced in function ___tmainCRTStartup

Attached is the Code::Block config file for the GFortran build of the Demo Program.

I hope these help.

Thanks in advance,

Jeff

[Steven_L_Intel1]

The difference in the linker error is not interesting - same cause. Don't specify a Windows application.

I'd try this myself, but it has a lot of prerequisites I don't have time for. You have all the source, I suggest debugging the console application and see what it doesn't like.

[IanH]

I have been meaning to play with this for some time.  How did you get it (the gtk-fortran library) to build with IVF?
 

[Jeffrey_K_]

Ian,

I didn't...I just used what was provided. Thinking about it & my work with the Winteracter GUI libraries, they (Winteracter) have a separate library sets ported to specific compilers - Lahey, Absoft, PGI, Intel/Compaq VF, etc. I wonder if the GTK+ libraries need to be compiled for IVF, or, since they are all in C, IVC? Doing that is *way* above my knowledge base...Looking for volunteers

Jeff

[Steven_L_Intel1]

Unlikely the libraries need to be compiled specifically, since the author says it makes use of the C interoperability features. Certainly one does not need to use Intel C++ (not that there's anything wrong with that.) The author says he made it work with Intel Fortran on Linux, There might be some other dependency but it seems unlikely.

[IanH]

Apologies for being slow, but what do you mean by "I just used what was provided".  They provide the library as Fortran source so something has to be built, and while my knowledge of cmake is limited (understatement), I see basic issues like command line options specified that don't make sense for ifort on windows.  I can fix that, but then I have problems when the included examples try and link against the glib libraries (and some examples have compile errors). 

Are you building against gtk2 or gtk3?

[Jeffrey_K_]

Hey Ian,

(clarification) The GUI Demo I was referencing was from the Fortran Dev Blog page (http://fortrandev.wordpress.com/2014/05/25/creating-a-gui-using-gtk3-and-gtk-fortran/) & the source is downloaded from GITHub (https://github.com/jshahbazi/fortran-gui-demo) ...Download ZIP on the right.

I presume the 'library' you are referring to are the interface routines listed in the gtk_src directory? I followed the model that was listed in the Code::Blocks config file for the fortran_gui_demo project. I included the needed files in the IVF Project listing as part of the build for the fortran_gui_demo. I added the needed "Linker\Input\Additional Dependencies" and "Addtional Include Directories" as indicated in the Code::Blocks config file and build it as a Windows Application (obviously).

It all compiled fine except for the linker error "LIBCMT.lib(wincrt0.obj) : error LNK2019: unresolved external symbol _WinMain@16 referenced in function ___tmainCRTStartup" which started this whole thread. It compiles/builds & executes correctly w/ gfortran...why not IVF & what will it take to remove that linker error to get IVF to work?

Also - I am using everything associated w/ gtk3

Jeff

[Steven_L_Intel1]

Jeff,

I believe I have told you twice if not three times about why you get that linker error and how to avoid it. Simply don't use /winapp (or choose a project type other than Windowing Application.) Your gfortran compile appears to be building a console application, so use that project type.

[Jeffrey_K_]

Steve,

I was responding to Ian's question. I already understand your position. Thank you for the responses you provided.

I'll go away now...

[JVanB]

I have found a set of commands that at least compiled an old version of a GTK program successfully.

Set the path so that Windows can find GTK's DLLs:

set path=%path%;C:\GTK\bin

Create the gtk.mod file the compiler will need to compile GTK programs:

gfortran -c gtk.f90

Then tell gfortran where GTK's libraries are and the libraries you need:

gfortran gtkhello.f90 -ogtkhello gtk.o -LC:\GTK\lib -lgtk-win32-2.0.dll -lgoblject-2.0.dll

And that worked in the good old days.  Can't really test it now because for some reason they made it just about impossible to install GTK on Windows any more.  Maybe Steve can translate the above sequence to ifort commands.  I was worried at first that GTK might be using STDCALL calling convention on 32-bit Windows, but it seems to be CDECL so that makes life easier.

[Steven_L_Intel1]

The set path command is the same. gfortran is linking directly to DLLs? Really?

[IanH]

Ok - I was tryigthe cmake build of the gtk-fortran library on top of gtk3.  Beyond the basic compile options mismatch and gross user error on my part, the cmake that I was using (2.8.12.1) trips up with ifort 15.0's integration new use of the TargetName project property.  I'm getting there...

[JVanB]

No, it's linking to libgtk-win32-2.0.dll.a and libgobject-2.0.dll.a .  I guess I misspelled gobject up there.  Sorry.

[Steven_L_Intel1]

Hmm. .a is a Linux spelling - I wonder if these are actually .lib files. The equivalent ifort command would be:

ifort gtkhello.f90 /link /libpath:C:\GTK\lib gtk-win32-2.0.dll.lib gobject-2.0.dll.lib

I'm assuming that the .lib files exist. If they're .a files, try renaming them to .lib and see if that works.

[IanH]

I have it building, after a few changes to the solutions and projects generated by cmake.  Some of the projects for the examples still have issues - some of which I suspect are Fortran language errors (but I need to dig further) and others are due to use of non-portable intrinsic functions.

The cmake configuration specifies the subsystem as console.  That just means that when you run an example by double clicking the exe file from within explorer (or similar), the operating system will create a console for the exe, which is pointless for most gui applications.  You can just use the editbin utility to change the exe type after a build is complete to workaround that.

[JVanB]

It looks like the .lib files exist, but they are called gtk-win32-2.0.lib and gobject-2.0.lib . I saw a web site that, for another mingw project, recommended taking the .def files the project created and then using lib.exe to turn them into .lib files.

[IanH]

Some notes for building the library and associated examples using ifort 15.0 and VS 2010.  Note that I am only barely capable in cmake.

• I used the gtk3 branch of the gtk-fortran library.
• I used a gtk3 "bundle" from http://win32builder.gnome.org/gtk+-bundle_3.6.4-20130921_win32.zip, which I unzipped into a sibling directory of the gtk-fortran source.  Earlier I tried against gtk2, but got link errors that suggested a more recent glib was required.
• I had to patch the CMakeLists.txt file in the top directory of the gtk-fortran source to remove the gfortran specific compile options.  See https://github.com/jerryd/gtk-fortran/issues/80. ; That patch sets no options for ifort in a debug configuration, /warn:all /check:all /standard-semantics /traceback /stand /magically_fix_my_bugs... etc might be worth specifying (with /stand you will get many errors from the generated source files for lines that are over 132 characters).
• I used the cmake build, generating a VS2010 solution and associated .vfproj files.  To get this to work cleanly I had to patch and rebuild cmake - it otherwise does not specify the TargetName property when the output file from linking differs from the project name (i.e. this business: https://software.intel.com/en-us/forums/topic/530369 ).  I opened a bug against cmake for this http://public.kitware.com/Bug/view.php?id=15175 - which has my very hacky patch attached.  If the Intel people are reading... some clarity about when/what/how/why TargetName is required would be appreciated.
• (As a variant, I also used the cmake build generating nmake makefiles.  I don't think this needs cmake to be patched.  It does require you to have the appropriate ifort command prompt open (x86 versus x64) for the variety of gtk3 that you are linking against, otherwise it is remarkable how many hours you can waste.)
• I had to disable parallel builds in Visual Studio (Tools > Options > Projects and Solutions > Build and Run, set maximum number of parallel project builds to 1).  This is because many of the example executables have Fortran modules of the same name that clash with each other.
• I had to patch in an alternative to the FDATE extension referenced in sketcher/gtkf-sketcher.f90.  I know that ifort has something similar, but I figured it was easier just to explicitly provide that function using DATE_AND_TIME - see https://github.com/jerryd/gtk-fortran/issues/81
• I still got build system related errors building a project called licenses and also building the doxygen docs.  With debugging options as listed in one of the dot points above I got an ICE in mandelbrot_pxibuf.f90.  I shall try and fish that out later.

Some of the examples that I ran started ok and seemed to work.  Others started but behaved a little oddly.  Others crashed.  I shall dig further at a later date.  They all come out as console apps, and many of them actually write to the console (in the unix style) when they have a runtime warning or, in some cases, in response to explicit fortran WRITE's.  Using editbin to reflag the exe's as being for the windows subsystem didn't seem to cause any additional issues though.