DLL and SymbolName decoration and recognition (DLLEXPORT vs DEF file)

[wolfgang_trautenberg]

Greetings,

we need to generate DLLs containing FORTRAN Code in two different
ways:
1) with !DEC$ ATTRIBUTES DLLEXPORT::myfunc
2) with a DEF / export file
Version 1) works, Version 2) fails.

We are compiling our sources with
-names:lowercase -iface:cvf -iface:nomixed_str_len_arg

This leads to dual symbol names in the objects (dumpbin -symbols)
_myfunc@8 AND _myfunc .

When building a DLL and in the source of myfunc.f the subroutin myfunc
was exported with
SUBROUTINE myfunc( int1, int2)
!DEC$ ATTRIBUTES DLLEXPORT::myfunc

Then the dll exports both the decorated and the completely undecorated symbol name:
dumpbin -exports mydll.dll
...
2 0 00001000 _myfunc@8
1 1 0000327E myfunc

In Consequence the DLL and LIB can be used easily even from code that
does not call the functions with the decorations.


Now comes the problem (version 2):

Some of our DLLs cannnot be build by explicitly exporting the symbols
in the source code with the
!DEC$ ATTRIBUTES DLLEXPORT::myfunc
instruction (since we dont have the source code ...).
For those cases, we need to use an export file to define the DLL interface.
We are linking similar to what follows:

link -OUT:mydll.dll -DLL -DEF:dllname.export mfunc.obj

where dllname.export should contain something like this

LIBRARY mydll
VERSION 1.0.0
EXPORTS
myfunc

However if we do this, the linker complains that it does not find a symbol
with the name myfunc, even though there is one present in the object.

mydll.export : warning LNK4022: cannot find unique match for symbol 'myfunc'
mydll.export : warning LNK4002: _myfunc defined in myfunc.obj
mydll.export : warning LNK4002: _myfunc@8 defined in myfunc.obj
mydll.export : error LNK2001: unresolved external symbol myfunc
mydll.lib : fatal error LNK1120: 1 unresolved externals



How can we teach the linker to generate a dll with the def/export file
the same way as when generating one with symbols exported by !DEC$ ATTRIBUTES DLLEXPORT::myfunc?

thanks

Wolfgang

[g_f_thomas]

I only use .def modules. Try aliasing myfunc to '_myfunc'.

Gerry

[wolfgang_trautenberg]

Thanks for the hint,

how can one alias the function without having access to the source of it?
What I would like to avoid is to have to explicitely alias the function name
with the full decoration (i.e. _symbolname@ParListByteLength ) since that
would be really cumbersome and would not exactly be highly protable
between 32 and 64 bit.

Wolfgang

[g_f_thomas]

Without the source code there isn't much you can do. I would encourage you to ditch the cvf calling convention in favor of the ivf default.

Gerry

[Jugoslav_Dujic]

You can dump the decorated symbols from .obj or .lib file using:

dumpbin /symbols libname.lib > temp.txt

and investigate the contents of temp.txt, so that you can reuse the symbol in the .def file.

I second the Gerry's advice to switch to the now-default calling convention (_cdecl), unless you don't have access to the recompiled version of that 3rd-party library. However, I think (please double-check!) that 32-bit and 64-bit naming schemes are different even for _cdecl -- 64-bit one does not include the underscore.

[Steven_L_Intel1]

JugoslavDujic:

However, I think (please double-check!) that 32-bit and 64-bit naming schemes are different even for _cdecl -- 64-bit one does not include the underscore.

Correct. Note also that on Win64 there is only one calling convention, C - STDCALL does not exist. This is why I prefer to use the DECORATE attribute rather than explicitly adding decoration to the alias.