topic Steve, in Intel® Fortran Compiler

Any Success Building GTK+ Apps w/ IVF?

Jeffrey_K_ — Wed, 24 Sep 2014 17:22:55 GMT

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

You've created a "Windowing

Steven_L_Intel1 — Wed, 24 Sep 2014 17:39:25 GMT

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

Steve,

Jeffrey_K_ — Wed, 24 Sep 2014 18:24:09 GMT

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

Winteracter probably supplies

Steven_L_Intel1 — Wed, 24 Sep 2014 18:36:08 GMT

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.)

Steve,

Jeffrey_K_ — Wed, 24 Sep 2014 19:58:24 GMT

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

The difference in the linker

Steven_L_Intel1 — Wed, 24 Sep 2014 20:19:06 GMT

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.

I have been meaning to play

IanH — Thu, 25 Sep 2014 06:48:16 GMT

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

Ian,

Jeffrey_K_ — Thu, 25 Sep 2014 18:48:47 GMT

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

Unlikely the libraries need

Steven_L_Intel1 — Thu, 25 Sep 2014 19:19:34 GMT

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.

Apologies for being slow, but

IanH — Thu, 25 Sep 2014 22:02:01 GMT

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?

Hey Ian,

Jeffrey_K_ — Fri, 26 Sep 2014 12:29:03 GMT

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

Jeff,

Steven_L_Intel1 — Fri, 26 Sep 2014 13:16:02 GMT

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.

Steve,

Jeffrey_K_ — Fri, 26 Sep 2014 16:57:03 GMT

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...

I have found a set of

JVanB — Fri, 26 Sep 2014 20:10:58 GMT

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.

The set path command is the

Steven_L_Intel1 — Fri, 26 Sep 2014 20:18:06 GMT

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

Ok - I was tryigthe cmake

IanH — Fri, 26 Sep 2014 22:11:27 GMT

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...

No, it's linking to libgtk

JVanB — Fri, 26 Sep 2014 22:24:17 GMT

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.

Hmm. .a is a Linux spelling -

Steven_L_Intel1 — Fri, 26 Sep 2014 23:05:46 GMT

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.

I have it building, after a

IanH — Sat, 27 Sep 2014 00:28:53 GMT

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.

It looks like the .lib files

JVanB — Sat, 27 Sep 2014 01:18:31 GMT

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.