Export dll functions bug

[yDF8EPJN8]

Description

First of all I would like to thank you for your work on this project!

I should mention that I am using the visual c++ compiler and opencascade 7.9.0 installed via vcpkg.

I tried to compile gmsh with opencascade and noticed that I get three files when building: gmsh.exe, gmsh.exp and gmsh.lib.
The gmsh.exp and gmsh.lib files only appear when building gmsh with opencascade.
When building the executable, these extra files appear if a function has the __declspec(dllexport) keyword defined.
At first I thought the problem was in the gmsh code.
Then I ran the dumpbin /EXPORTS gmsh.exe command.

Here is what the dumpbin command gives when gmsh is compiled without opencascade

Microsoft (R) COFF/PE Dumper Version 14.42.34438.0
Copyright (C) Microsoft Corporation.  All rights reserved.


Dump of file gmsh.exe

File Type: EXECUTABLE IMAGE

  Summary

       84000 .data
       30000 .pdata
      2CA000 .rdata
        A000 .reloc
        1000 .rsrc
      71B000 .text

And this, if gmsh is compiled together with opencascade

Microsoft (R) COFF/PE Dumper Version 14.42.34438.0
Copyright (C) Microsoft Corporation.  All rights reserved.


Dump of file gmsh.exe

File Type: EXECUTABLE IMAGE

  Section contains the following exports for gmsh.exe

    00000000 characteristics
    FFFFFFFF time date stamp
        0.00 version
           1 ordinal base
          16 number of functions
          16 number of names

    ordinal hint RVA      name

          1    0 0018F120 ??_FAPIHeaderSection_MakeHeader@@QEAAXXZ
          2    1 0018F130 ??_FBRepBuilderAPI_Sewing@@QEAAXXZ
          3    2 0018F160 ??_FBRepFill_Filling@@QEAAXXZ
          4    3 0018F1B0 ??_FBRepOffsetAPI_MakeFilling@@QEAAXXZ
          5    4 0018F200 ??_FBRepOffsetAPI_ThruSections@@QEAAXXZ
          6    5 0018F220 ??_FBRepTools_Modifier@@QEAAXXZ
          7    6 0018F230 ??_FGeomPlate_BuildPlateSurface@@QEAAXXZ
          8    7 0018F270 ??_FMessage_Level@@QEAAXXZ
          9    8 0018F2A0 ??_FNCollection_IncAllocator@@QEAAXXZ
         10    9 00066790 ??_FOSD_MemInfo@@QEAAXXZ
         11    A 000667A0 ??_FStandard_OutOfMemory@@QEAAXXZ
         12    B 0018F2B0 ??_FTDF_Transaction@@QEAAXXZ
         13    C 001919B0 ?GetString@DESTEP_Parameters@@QEAA?AVTCollection_AsciiString@@W4ReadMode_ProductContext@1@@Z
         14    D 00134C50 ?HasCachedMinMax@Poly_Triangulation@@QEBA_NXZ
         15    E 0000B160 ?Paste@TDataStd_GenericEmpty@@UEBAXAEBV?$handle@VTDF_Attribute@@@opencascade@@AEBV?$handle@VTDF_RelocationTable@@@3@@Z
         16    F 0000B160 ?Restore@TDataStd_GenericEmpty@@UEAAXAEBV?$handle@VTDF_Attribute@@@opencascade@@@Z

  Summary

       85000 .data
       32000 .pdata
      2E2000 .rdata
        A000 .reloc
        1000 .rsrc
      76E000 .text

I have found that the Standard_EXPORT macro is defined as __declspec(dllexport) in the header file.
This macro is used for example in the file src/BRepBuilderAPI/BRepBuilderAPI_Sewing.hxx.
It is strange that there is no option to define Standard_EXPORT as __declspec(dllimport).
Perhaps this question is duplicating this one, but due to the sparse description I'm not sure.

The problem is that when I want to compile gmsh as a static library, there is a gmsh.lib filename conflict.

Expected Behavior

Standard_EXPORT as __declspec(dllimport)

Actual Behavior

Standard_EXPORT as __declspec(dllexport)

Sample Code or DRAW Tcl Script

none

Operating System

Windows

Compiler

MSVC

Bitness

64-bit

OCCT Version

latest

Additional Files

If you want to build gmsh using the msvc compiler, then disable OpenMP and FLTK when building with CMake.

[dpasukhi]

Dear @yDF8EPJN8 the occt was build as static or as shared lib?

[yDF8EPJN8]

occt was build as shared lib.

[gkv311]

It is strange that there is no option to define Standard_EXPORT as __declspec(dllimport).

Actually this macros COULD be overridden as it is defined by Standard_Macro.hxx conditionally:

#  ifndef Standard_EXPORT
#   define Standard_EXPORT __declspec( dllexport )

Therefore, you may pass desired Standard_EXPORT definition as compiler flags to your project. I've already seen some projects doing that.

As for why OCCT defines __declspec(dllexport) - just to simplify definitions, as it works fine for 99% cases. MSVC linker is smart enough to resolve (import) symbols marked by __declspec(dllexport) if these are methods of C++ class. The side effects appear when Standard_EXPORT is assigned to inline methods defined entirely in .hxx header file - in this case method could be re-exported by every DLL that uses this particular header file, so that putting Standard_EXPORT to clearly inline methods is bogus and should be avoided.

There is another problematic scenario - method is implemented in .cxx, but it's declaration in .hxx has default values for some arguments. In this case MSVC implicitly generates inline methods with substituted defaults.

[yDF8EPJN8]

I didn't know that MSVC linker is smart enough to import symbols marked as __declspec(dllexport), thanks.

Indeed, the problem is solved if you define Standard_EXPORT as __declspec(dllimport) when building the project.

I will leave the issue open as I believe that defining the Standard_EXPORT macro by the user is a temporary solution.