Can procedures returning ALLOCATABLE types be exported from a dynamic-link library (DLL)?

[FortranFan]

I'm in a time crunch and unsure in my current frame of mind as to where all I should look to understand this, so thought I'd ask here: can procedures returning ALLOCATABLE types be exported from a dynamic-link library (DLL)?

Consider the simple example below:

FUNCTION foo() RESULT(Message)
   
   !.. Function result
   CHARACTER(LEN=:), ALLOCATABLE :: Message
   
   Message = "Hello World!"
   
   RETURN
   
END FUNCTION foo

Can such a function be exported from a DLL and called from another program, say a Fortran console application?  I get a run-time library exception when I do so:

forrtl: severe (157): Program Exception - access violation
Image              PC        Routine            Line        Source
ntdll.dll          76F4E41B  Unknown               Unknown  Unknown
ntdll.dll          76F4E023  Unknown               Unknown  Unknown
kernel32.dll       757614AD  Unknown               Unknown  Unknown
...
...

Are function exports a no-no that is widely known, but about which I was unaware?

[Steven_L_Intel1]

There's nothing special about a DLL - it's just another kind of library. Did you have an explicit interface for this procedure visible to the caller? That's required in this case (deferred-length character and/or allocatable function result).

[FortranFan]

Steve Lionel (Intel) wrote:

There's nothing special about a DLL - it's just another kind of library...

That's what I thought - thanks for the clarification.

Steve Lionel (Intel) wrote:

... Did you have an explicit interface for this procedure visible to the caller? That's required in this case (deferred-length character and/or allocatable function result).

Yes, very much so.  The function is in a module and the caller has access to the module file built the same time as the DLL.

So the next step for me will be to try to put together a simple reproducer.

Thanks, 

[Simon_Geard]

Have you tried

allocate(Message, source = "Hello World!")

I know they should be the same but there are places in my code where I have had to use the allocate syntax and this look like one of them. Unfortunately I don't have the time to turn my code into a reproducible test case so I haven't been able to take it any further.

[FortranFan]

sgeard@cad-schroer.co.uk wrote:

Have you tried

allocate(Message, source = "Hello World!")

I know they should be the same but there are places in my code where I have had to use the allocate syntax and this look like one of them. Unfortunately I don't have the time to turn my code into a reproducible test case so I haven't been able to take it any further.

Hmm.. that's interesting!  I've not run into that, especially with alloctable string ("CHARACTER(LEN=:), ALLOCATABLE" :: ) types.  But I'll keep that in mind, thanks.

[FortranFan]

Steve Lionel (Intel) wrote:

There's nothing special about a DLL - it's just another kind of library..

It is best to keep in mind this comment by Steve.

I think the problem we are running into is probably due to other factors, especially linker options for run-time libraries and possibly even compiler options such as /iface, /Q (auto vs something else), etc.

In several unit tests we've tried since my original post, when the calling program as well as the DLL are built with the exact same compiler and linker options, no issues have been noticed.  Even DLL-exported functions returning fairly complicated allocatable derived types (containing allocatable sub-components of various kinds along with type-bound procedures) work as expected.

[Steven_L_Intel1]

Turns out the DLL is a red herring - not required to see the problem. Tracking separately in this thread.

[FortranFan]

Thanks much, Steve.  Much relieved to read your confirmation about DLLs; I was worried for a while since some of the users explicitly want DLLs for some aspect of their use cases and management would like the same structure for all users, so DLLs were selected.