View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0029046 | Community | OCCT:Configuration | public | 2017-08-24 13:09 | 2018-02-26 00:18 |
| Reporter | Assigned To | Schaeffer AG | |||
| Priority | normal | Severity | minor | ||
| Status | closed | Resolution | open | ||
| Target Version | 7.2.0 | Fixed in Version | 7.2.0 | ||
| Summary | 0029046: Problem with OCCT static build with MinGW | ||||
| Description | The following report comes from our external contact. I provide it with all available details, but, apparently, some analysis is still required. --- If we try to build OpenCASCADE 7.1.0 with the cmake-option HAVE_NO_DLL, we receive the error attached in err.txt. The problem appears to be that 'rad1', 'rad2', ..., 'rad16' are already #defined as numeric contsants somewhere in windows.h (actually in dlgs.h, somehow included from windows.h). We have no idea why this only pops up when we build OpenCASCADE as static-only. Our workaround currently is to #undef ref1 and ref2 in the corresponding AIS code, but we realize that this is not an option for a public fix. Maybe you guys have a better idea how to fix this the right way (apparently, when building OCCT with shared-library enabled, the error doesn't pop up (?)). Regarding HAVE_NO_DLL: we're using cmake from the command line, so we're not very knowledgeable about what the available GUI options would be (there is no such option in CMake GUI -- ssv). (This is because we're having a "linux-farm" setup to compile our software and all dependencies, including OCCT, for all platforms.) Setting BUILD_LIBRARY_TYPE=Static is not enough, at least when building with MinGW. It will build a static library, yes, but it will not get the name mangling in exported symbols right. (All the symbols will be prefixed by an "__imp_..." string, preventing the linker from finding them later.) We've tracked this down to the __declspec(dllimport/dllexport) compiler flags that the headers are using. If we specify the HAVE_NO_DLL option, then the dllimport/dllexport flag combination is set correctly for MinGW (i.e. is not set at all -- I think declspec is a MS-typical thing). Then everything turns out ok and our compile pipeine works as expected. The idea to use HAVE_NO_DLL initially comes from various (OCCT?) forums on the internet, but ultimately, OCCT headers _do_ use this option and react to it. This is why we actually thought that HAVE_NO_DLL is the intended way to do it. But of course, we'll be happy to use another flag to disable the __declspec-stuff, if you care to provide one. BTW, meanwhile, we've also read that official position of OpenCASCADE is that "MinGW is not supported" (or at least was about 1 year ago). Unfortunately that's not an option for us. We use MinGW because all our builds are done on Linux servers (and will get even more "Linux"-y as soon as we've finished our new clustered, container-based infrastructure). So one way or another, we're going to stick with it. But the good news is that MinGW essentially works out of the box, the only remaining problem being the __declspec-stuff (and the related windows.h-macro stuff). And for the windows.h part you already _do_ have some solution buried in your code, because windows.h by itself doesn't react to the HAVE_NO_DLL flag. So, in essence, our current solution WorksForUs(tm), but we feel that if would be beneficial if there was a proper upstream fix -- especially since the solution is already there, it's just a matter of getting organized. | ||||
| Tags | No tags attached. | ||||
| Test case number | |||||
|
2017-08-24 13:09 developer |
err.txt (4,362 bytes) |
|
|
Some remarks: 1. The problem reported in err.txt does not seem to have any correlation with static builds -- it is due to conflict of names of local variables like rad1 or rad2 with global macros set by some third-party headers (like X11 or windows.h). This particular problem should be eliminated since OCCT 7.2.0 (by the fix for 0028417) 2. Macros HAVE_NO_DLL should be set when building OCCT statically; for OCCT build itself, it is done within 0029377 (to be integrated soon). It is still necessary to define HAVE_NO_DLL when building client code; we shall consider improvement to avoid this requirement. 3. MinGw is officially supported since OCCT 7.0.0, see https://www.opencascade.com/doc/occt-7.0.0/overview/html/index.html#overview_req_cpp |
|
|
Works with OCCT 7.2.0 under MinGW64 for both 32 and 64 bit. Thanks a lot. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2017-08-24 13:09 |
|
New Issue | |
| 2017-08-24 13:09 |
|
Assigned To | => bugmaster |
| 2017-08-24 13:09 |
|
File Added: err.txt | |
| 2017-12-18 07:17 |
|
Note Added: 0073009 | |
| 2017-12-18 07:18 |
|
Relationship added | related to 0029377 |
| 2018-01-09 16:32 | bugmaster | Assigned To | bugmaster => ssv |
| 2018-01-09 16:32 | bugmaster | Status | new => feedback |
| 2018-01-09 16:38 |
|
Assigned To | ssv => Schaeffer AG |
| 2018-02-07 12:44 | Schaeffer AG | Note Added: 0073861 | |
| 2018-02-26 00:18 |
|
Status | feedback => closed |
| 2018-02-26 00:18 |
|
Fixed in Version | => 7.2.0 |
| 2018-02-26 00:18 |
|
Target Version | 7.4.0 => 7.2.0 |
