Prev: removing /save fortran compiler option
Next: Why not 0?
From: Ian Harvey on 5 Jul 2010 07:52
On 5/07/2010 9:06 PM, Arjen Markus wrote:
> On 5 jul, 10:53, Arjen Markus<arjen.markus...(a)gmail.com> wrote:
>
> On Windows I get very different problems indeed. The one I want to
> tackle
> first is the problem with gfortran that I see:
>
> win_dynlib.o:win_dynlib.f90:(.text+0x14a): undefined reference to
> `LoadLibraryW'
> collect2: ld returned 1 exit status
>
> where the source for win_dynlib.f90 is given below.
>
> At the command-line I specified --enable-stdcall-fixup to suppress a
> warning
> about GetProcAddress@8 - but the same linking procedure that is behind
> that
> fixup fails with LoadLibrary(A or W).
>
> Any thoughts?
>
> Regards,
>
> Arjen
>
> ----
> ! win_dynlib --
> ! Implementation for GNU Fortran on Windows of low-level routines
> ! that deal with dynamic libraries
> !
> module system_dynamic_libraries
> use iso_c_binding
> implicit none
>
> interface
> function c_load_library( cname ) bind(c, name='LoadLibraryW')

You're on win32? If so, then system API's don't use the C calling
convention. gfortran has a compiler directive that may help.

> use iso_c_binding

!GCC$ ATTRIBUTES STDCALL :: c_load_library

> character(kind=c_char), dimension(*) :: cname
> integer(kind=c_long) :: c_load_library
> end function c_load_library
> end interface
>
> interface
> function c_get_procedure( handle, cname ) bind(c,
> name='GetProcAddress')
> use iso_c_binding

!GCC$ ATTRIBUTES STDCALL :: c_get_procedure

> integer(kind=c_long), value :: handle
> character(kind=c_char), dimension(*) :: cname
> type(c_funptr) :: c_get_procedure
> end function c_get_procedure
> end interface
>
> contains
>
> ! system_load_library --
> ! Load the library
> !
> ! Arguments:
> ! handle Handle to the library
> ! cname Null-terminated name of the library
> !
> ! Returns:
> ! Handle to the library
> !
> subroutine system_load_library( handle, cname )
> integer(kind=c_long) :: handle
> character(len=1), dimension(*) :: cname

cname will need to be a unicode string if you are going to use
LoadStringW. LoadStringA might be better.

>
> write(*,*) ' in system_load_library', cname(1:20),
> ichar(cname(13))
> handle = c_load_library( cname )
> write(*,*) ' system_load_library: loaded'
> end subroutine system_load_library
>
> ! system_get_procedure --
> ! Get the procedure
> !
> ! Arguments:
> ! handle Handle to the library
> ! cname Null-terminated name of the procedure
> ! cproc C-style procedure pointer
> ! success Whether successful or not
> !
> ! Returns:
> ! Handle to the library
> !
> subroutine system_get_procedure( handle, cname, cproc, success )
> integer(kind=c_long) :: handle
> character(len=1), dimension(*) :: cname
> type(c_funptr) :: cproc
> logical :: success
>
> cproc = c_get_procedure( handle, cname )
>
> success = transfer(cproc, 0_c_long) /= 0_c_long
>
> end subroutine system_get_procedure
>
> end module system_dynamic_libraries

From: Arjen Markus on 5 Jul 2010 08:29
On 5 jul, 13:52, Ian Harvey <ian_har...(a)bigpond.com> wrote:
> On 5/07/2010 9:06 PM, Arjen Markus wrote:
>
>
>
>
>
> > On 5 jul, 10:53, Arjen Markus<arjen.markus...(a)gmail.com>  wrote:
>
> > On Windows I get very different problems indeed. The one I want to
> > tackle
> > first is the problem with gfortran that I see:
>
> > win_dynlib.o:win_dynlib.f90:(.text+0x14a): undefined reference to
> > `LoadLibraryW'
> > collect2: ld returned 1 exit status
>
> > where the source for win_dynlib.f90 is given below.
>
> > At the command-line I specified --enable-stdcall-fixup to suppress a
> > warning
> > about GetProcAddress@8 - but the same linking procedure that is behind
> > that
> > fixup fails with LoadLibrary(A or W).
>
> > Any thoughts?
>
> > Regards,
>
> > Arjen
>
> > ----
> > ! win_dynlib --
> > !     Implementation for GNU Fortran on Windows of low-level routines
> > !     that deal with dynamic libraries
> > !
> > module system_dynamic_libraries
> >      use iso_c_binding
> >      implicit none
>
> >      interface
> >          function c_load_library( cname ) bind(c, name='LoadLibraryW')
>
> You're on win32?  If so, then system API's don't use the C calling
> convention.  gfortran has a compiler directive that may help.
>
> >              use iso_c_binding
>
>                 !GCC$ ATTRIBUTES STDCALL :: c_load_library
>
> >              character(kind=c_char), dimension(*) :: cname
> >              integer(kind=c_long)                 :: c_load_library
> >          end function c_load_library
> >      end interface
>
> >      interface
> >          function c_get_procedure( handle, cname ) bind(c,
> > name='GetProcAddress')
> >              use iso_c_binding
>
>                 !GCC$ ATTRIBUTES STDCALL :: c_get_procedure
>
>
>
>
>
> >              integer(kind=c_long), value          :: handle
> >              character(kind=c_char), dimension(*) :: cname
> >              type(c_funptr)                       :: c_get_procedure
> >          end function c_get_procedure
> >      end interface
>
> > contains
>
> > ! system_load_library --
> > !     Load the library
> > !
> > ! Arguments:
> > !     handle         Handle to the library
> > !     cname          Null-terminated name of the library
> > !
> > ! Returns:
> > !     Handle to the library
> > !
> > subroutine system_load_library( handle, cname )
> >      integer(kind=c_long)           :: handle
> >      character(len=1), dimension(*) :: cname
>
> cname will need to be a unicode string if you are going to use
> LoadStringW.  LoadStringA might be better.
>
>
>
>
>
> >      write(*,*) ' in system_load_library', cname(1:20),
> > ichar(cname(13))
> >      handle = c_load_library( cname )
> >      write(*,*) ' system_load_library: loaded'
> > end subroutine system_load_library
>
> > ! system_get_procedure --
> > !     Get the procedure
> > !
> > ! Arguments:
> > !     handle         Handle to the library
> > !     cname          Null-terminated name of the procedure
> > !     cproc          C-style procedure pointer
> > !     success        Whether successful or not
> > !
> > ! Returns:
> > !     Handle to the library
> > !
> > subroutine system_get_procedure( handle, cname, cproc, success )
> >      integer(kind=c_long)           :: handle
> >      character(len=1), dimension(*) :: cname
> >      type(c_funptr)                 :: cproc
> >      logical                        :: success
>
> >      cproc = c_get_procedure( handle, cname )
>
> >      success = transfer(cproc, 0_c_long) /= 0_c_long
>
> > end subroutine system_get_procedure
>
> > end module system_dynamic_libraries- Tekst uit oorspronkelijk bericht niet weergeven -
>
> - Tekst uit oorspronkelijk bericht weergeven -- Tekst uit oorspronkelijk bericht niet weergeven -
>
> - Tekst uit oorspronkelijk bericht weergeven -- Tekst uit oorspronkelijk bericht niet weergeven -
>
> - Tekst uit oorspronkelijk bericht weergeven -

Well, I tried with both variations - none helped. I had hoped I could
avoid
such compiler directives ... in vain, most probably (Intel Fortran
requires
something similar, though).

Thanks, I will try this.

Regards,

Arjen
From: Arjen Markus on 5 Jul 2010 08:35
On 5 jul, 13:52, Ian Harvey <ian_har...(a)bigpond.com> wrote:
>
> You're on win32?  If so, then system API's don't use the C calling
> convention.  gfortran has a compiler directive that may help.
>
> >              use iso_c_binding
>
>                 !GCC$ ATTRIBUTES STDCALL :: c_load_library
>
> >              character(kind=c_char), dimension(*) :: cname

Unfortunately, this does not work!

The error message remains the same, I have tried with c_load_library,
LoadLibraryA and LoadLibraryA@4 - always the same message.

I use version 4.4.3 of gfortran at the moment.

Regards,

Arjen
From: dpb on 5 Jul 2010 08:53
Arjen Markus wrote:
> On 5 jul, 13:52, Ian Harvey <ian_har...(a)bigpond.com> wrote:
>> You're on win32? If so, then system API's don't use the C calling
>> convention. gfortran has a compiler directive that may help.
>>
>>> use iso_c_binding
>> !GCC$ ATTRIBUTES STDCALL :: c_load_library
>>
>>> character(kind=c_char), dimension(*) :: cname
>
> Unfortunately, this does not work!
>
> The error message remains the same, I have tried with c_load_library,
> LoadLibraryA and LoadLibraryA@4 - always the same message.
>
> I use version 4.4.3 of gfortran at the moment.
....

I don't know the GCC nomenclature but presume it's similar to the IVF
given the similarities above. But, I don't grok the "I don't grok the
c_load_library" above; seems like you need a reference to the actual
entry point to me.

My SDK doc's (admittedly somewhat dated now) show entry points for

LoadLibrary
LoadLibraryEx

but not

LoadLibraryA.

Are you sure you're trying to refer to a valid entry point?

--
From: Arjen Markus on 5 Jul 2010 08:59
On 5 jul, 14:53, dpb <n...(a)non.net> wrote:
> Arjen Markus wrote:
> > On 5 jul, 13:52, Ian Harvey <ian_har...(a)bigpond.com> wrote:
> >> You're on win32?  If so, then system API's don't use the C calling
> >> convention.  gfortran has a compiler directive that may help.
>
> >>>              use iso_c_binding
> >>                 !GCC$ ATTRIBUTES STDCALL :: c_load_library
>
> >>>              character(kind=c_char), dimension(*) :: cname
>
> > Unfortunately, this does not work!
>
> > The error message remains the same, I have tried with c_load_library,
> > LoadLibraryA and LoadLibraryA@4 - always the same message.
>
> > I use version 4.4.3 of gfortran at the moment.
>
> ...
>
> I don't know the GCC nomenclature but presume it's similar to the IVF
> given the similarities above.  But, I don't grok the "I don't grok the
> c_load_library" above; seems like you need a reference to the actual
> entry point to me.
>
> My SDK doc's (admittedly somewhat dated now) show entry points for
>
> LoadLibrary
> LoadLibraryEx
>
> but not
>
> LoadLibraryA.
>
> Are you sure you're trying to refer to a valid entry point?
>
> --- Tekst uit oorspronkelijk bericht niet weergeven -
>
> - Tekst uit oorspronkelijk bericht weergeven -

Yes, if you check the C header files, you will see LoadLibrary is
redefined to LoadLibraryA or LoadLibraryW, depending on whatever
branch
the compiler has decided to use. (I first used LoadLibrary, but that
obviously did not work ;)).

Regards,

Arjen
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: removing /save fortran compiler option
Next: Why not 0?