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

[JVanB]

In the original gtk.f90, my recollection is that some variables got translated to LOGICAL(C_BOOL) when the corresponding C type wasn't _Bool. If that isn't fixed in current sources, it could cause failures.  Also if the GTK .dll files are compiled with gcc rather than MSVC, there is an incompatibility with functions that return any but the simplest structures that can cause the stack to come out of whack in 32-bit mode.  So either compile the GTK .dll files with MSVC, only work in 64-bit mode, or for each GTK function that returns an even slightly complicated structure write a wrapper subroutine that invokes the function and returns the result through an argument. Of course the wrapper subroutines should have the BIND attribute and be compiled with gfortran.

[IanH]

Repeat Offender wrote:
Also if the GTK .dll files are compiled with gcc rather than MSVC, there is an incompatibility with functions that return any but the simplest structures that can cause the stack to come out of whack in 32-bit mode.

You are probably right.

But well before we go there, it would seem that ifort needs to be given some urgent lessons in how to play nice with MSVC first.

/* 201-09-30 ptr-fun c.c */
#include <stdio.h>

char *thing = "no";

char *get_a_pointer()
{
  return thing;
}

void use_that_pointer(char *ptr, char *str)
{
  printf("Ifort has %s %s.\n", ptr, str);
}

! 2014-09-30 ptr-fun fortran.f90
MODULE surely_not
  IMPLICIT NONE
  INTERFACE
    FUNCTION get_a_pointer() BIND(C)
      USE, INTRINSIC :: ISO_C_BINDING, ONLY: C_PTR, C_INT
      IMPLICIT NONE
      TYPE(C_PTR) :: get_a_pointer
    END FUNCTION get_a_pointer
    
    SUBROUTINE use_that_pointer(ptr, str) BIND(C)
      USE, INTRINSIC :: ISO_C_BINDING, ONLY: C_PTR, C_CHAR
      IMPLICIT NONE
      TYPE(C_PTR), VALUE :: ptr
      CHARACTER(KIND=C_CHAR), DIMENSION(*) :: str
    END SUBROUTINE use_that_pointer
  END INTERFACE
CONTAINS
  FUNCTION some_fun(str) RESULT(ptr)
    USE, INTRINSIC :: ISO_C_BINDING, ONLY: C_CHAR, C_PTR, C_INT
    TYPE(C_PTR) :: ptr
    CHARACTER(KIND=C_CHAR), INTENT(IN), OPTIONAL :: str(*)
    ptr = get_a_pointer()
    IF (PRESENT(str)) CALL use_that_pointer(ptr, str)
  END FUNCTION some_fun
END MODULE surely_not

PROGRAM p
  USE surely_not
  USE, INTRINSIC :: ISO_C_BINDING, ONLY: C_PTR, C_INT, C_CHAR, C_NULL_CHAR
  IMPLICIT NONE
  TYPE(C_PTR) :: ptr
  CHARACTER(LEN=5,KIND=C_CHAR) :: str
  
  str = 'bugs' // C_NULL_CHAR
  
  ! Call directly.
  ptr = get_a_pointer()
  CALL use_that_pointer(ptr, str)
  
  ! Call via another function that has an optional argument.
  ptr = some_fun(str)
END PROGRAM p

>cl /c "2014-09-30 ptr-fun c.c"
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.40219.01 for 80x86
Copyright (C) Microsoft Corporation.  All rights reserved.

2014-09-30 ptr-fun c.c


>ifort /check:all /warn:all /standard-semantics /stand /Od "2014-09-30 ptr-fun fortran.f90" "2014-09-30 ptr-fun c.obj"
Intel(R) Visual Fortran Compiler XE for applications running on IA-32, Version 15.0.0.108 Build 20140726
Copyright (C) 1985-2014 Intel Corporation.  All rights reserved.

Microsoft (R) Incremental Linker Version 10.00.40219.01
Copyright (C) Microsoft Corporation.  All rights reserved.

"-out:2014-09-30 ptr-fun fortran.exe"
-subsystem:console
"2014-09-30 ptr-fun fortran.obj"
"2014-09-30 ptr-fun c.obj"


>"2014-09-30 ptr-fun fortran.exe"
Ifort has no bugs.
Ifort has  bugs.

[Steven_L_Intel1]

That's a very curious problem, Ian. What is happening is that the call to use_that_pointer in the main program is properly passing the pointer by value, but the one in some_fun is not. I tried removing the OPTIONAL attribute and the problem remained. I have escalated this to the developers as issue DPD200361582. Thanks for trying this.

[IanH]

You are right - the optional is a red herring.  It looks like the issue occurs when an C_PTR actual argument that is a function result gets passed to a BIND(C) procedure that takes a C_PTR by value.  That pattern happens quite a bit in the higher level gtk-fortran procedures, and I expect that explains many of the assertions and similar that I see. 

I rebuilt the gtk stack and its three and a half billion dependencies using VS2010 to see how much of a factor that was and it does not appear to have changed things significantly (bar my age), though issues might be being shadowed by this other problem.

For what its worth, I have been putting the changes I made to the library as part of this little get-it-working-with-ifort journey up at https://github.com/IanH0073/gtk-fortran/tree/gtk3 ; Note that I have little clue about this whole git business.  Some of the changes were to fix Fortran language usage issues, others were to the cmake build stuff - the latter is also reasonably foreign to me.  Suggestions welcomed from those more familiar with git/cmake. 

(With regard to the latter, the cmake people have made some changes that will be in cmake 3.1 that should fix the TargetName/TargetExt business above.)

[IanH]

Here is a cut down set of source for the ice.

>ifort /c /warn:all /check:all /standard-semantics /traceback /stand /Od gtk.f90
Intel(R) Visual Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 15.0.0.108 Build 20140726
Copyright (C) 1985-2014 Intel Corporation.  All rights reserved.



>ifort /c /warn:all /check:all /standard-semantics /traceback /stand /Od mandelbrot_pixbuf.f90
Intel(R) Visual Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 15.0.0.108 Build 20140726
Copyright (C) 1985-2014 Intel Corporation.  All rights reserved.

mandelbrot_pixbuf.f90(20): catastrophic error: **Internal compiler error: internal abort** Please report this error along with the circumstances in which it occurred in a Software Problem Report.  Note: File and line given may not be explicit cause of this error.
compilation aborted for mandelbrot_pixbuf.f90 (code 1)

[Steven_L_Intel1]

The problem with BIND(C) and C_PTR has been fixed for update 2, due in February.

Ian's internal compiler error is triggered by /warn:interface and has been reported as issue DPD200363108.