Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compiling on Windows? #42

Open
geekrelief opened this issue Sep 24, 2021 · 9 comments
Open

Compiling on Windows? #42

geekrelief opened this issue Sep 24, 2021 · 9 comments

Comments

@geekrelief
Copy link

Do you have any advice for getting this to compile on Windows? I'm using MSYS with the Windows version of cmake so I can call the generator for "MSYS Makefiles", but calling make I've run into these errors.

[ 15%] Linking CXX shared library libpsychecommon.dll
/C/msys64/usr/bin/../lib/gcc/x86_64-pc-msys/10.2.0/../../../../x86_64-pc-msys/bin/ld: CMakeFiles/psychecommon.dir/objects.a(TextElement.cpp.obj):TextElement.cpp:(.text+0x17): undefined reference to `__imp__ZTVN3psy11TextElementE'
/C/msys64/usr/bin/../lib/gcc/x86_64-pc-msys/10.2.0/../../../../x86_64-pc-msys/bin/ld: CMakeFiles/psychecommon.dir/objects.a(TextElement.cpp.obj):TextElement.cpp:(.text+0xb7): undefined reference to `__imp__ZTVN3psy11TextElementE'
/C/msys64/usr/bin/../lib/gcc/x86_64-pc-msys/10.2.0/../../../../x86_64-pc-msys/bin/ld: CMakeFiles/psychecommon.dir/objects.a(Diagnostic.cpp.obj):Diagnostic.cpp:(.text+0xae): undefined reference to `__imp__ZNK3psy20DiagnosticDescriptor15defaultSeverityEv'
/C/msys64/usr/bin/../lib/gcc/x86_64-pc-msys/10.2.0/../../../../x86_64-pc-msys/bin/ld: CMakeFiles/psychecommon.dir/objects.a(Diagnostic.cpp.obj):Diagnostic.cpp:(.text+0x208): undefined reference to `__imp__ZNK3psy20DiagnosticDescriptor11descriptionEv'
collect2: error: ld returned 1 exit status
make[2]: *** [common/CMakeFiles/psychecommon.dir/build.make:259: common/libpsychecommon.dll] Error 1
make[1]: *** [CMakeFiles/Makefile2:191: common/CMakeFiles/psychecommon.dir/all] Error 2
make: *** [Makefile:136: all] Error 2
@aytey
Copy link
Contributor

aytey commented Sep 24, 2021

I can reproduce this issue exactly; I think it is potentially due to something being marked as __declspec(dllexport)/__declspec(dllimport) inconsistently:

Unfortunately, just nuking PSY_API in common/API.h doesn't help ...

@aytey
Copy link
Contributor

aytey commented Sep 24, 2021

Indeed, there's actually errors about this:

[1/76] Building CXX object common/CMakeFiles/psychecommon.dir/text/TextElement.cpp.o
../common/text/TextElement.cpp:28:1: warning: 'psy::TextElement::TextElement(const char*, unsigned int)' redeclared without dllimport attribute: previous dllimport ignored [-Wattributes]
   28 | TextElement::TextElement(const char* chars, unsigned int size)
      | ^~~~~~~~~~~
../common/text/TextElement.cpp:38:1: warning: 'virtual psy::TextElement::~TextElement()' redeclared without dllimport attribute: previous dllimport ignored [-Wattributes]
   38 | TextElement::~TextElement()
      | ^~~~~~~~~~~
../common/text/TextElement.cpp:43:14: warning: 'static unsigned int psy::TextElement::hashCode(const char*, unsigned int)' redeclared without dllimport attribute after being referenced with dll linkage
   43 | unsigned int TextElement::hashCode(const char* chars, unsigned int size)
      |              ^~~~~~~~~~~

@aytey
Copy link
Contributor

aytey commented Sep 24, 2021

Right, I've got it to work, but it is a "hack".

Here's a diff:

diff --git a/C/API.h b/C/API.h
index fa65fd8..18ca42e 100644
--- a/C/API.h
+++ b/C/API.h
@@ -21,6 +21,10 @@
 #ifndef PYSCHE_C_API_H__
 #define PYSCHE_C_API_H__
 
+#ifdef PSY_C_API
+#undef PSY_C_API
+#endif
+
 // From https://gcc.gnu.org/wiki/Visibility
 #if defined _WIN32 || defined __CYGWIN__
   #ifdef EXPORT_API
@@ -55,4 +59,7 @@
   #endif
 #endif
 
+#undef PSY_C_API
+#define PSY_C_API
+
 #endif
diff --git a/C/plugin-api/PluginConfig.h b/C/plugin-api/PluginConfig.h
index 4897cd5..47b6538 100644
--- a/C/plugin-api/PluginConfig.h
+++ b/C/plugin-api/PluginConfig.h
@@ -21,6 +21,10 @@
 #ifndef PLUGIN_C_CONFIG_H__
 #define PLUGIN_C_CONFIG_H__
 
+#ifdef PLUGIN_API
+#undef PLUGIN_API
+#endif
+
 // From https://gcc.gnu.org/wiki/Visibility
 #if defined _WIN32 || defined __CYGWIN__
   #ifdef EXPORT_API
@@ -47,4 +51,7 @@
   #endif
 #endif
 
+#undef PLUGIN_API
+#define PLUGIN_API
+
 #endif
diff --git a/common/API.h b/common/API.h
index 468f883..221fa5b 100644
--- a/common/API.h
+++ b/common/API.h
@@ -21,6 +21,10 @@
 #ifndef PSYCHE_API_H__
 #define PSYCHE_API_H__
 
+#ifdef PSY_API
+#undef PSY_API
+#endif
+
 // From https://gcc.gnu.org/wiki/Visibility
 #if defined _WIN32 || defined __CYGWIN__
   #ifdef EXPORT_API
@@ -47,4 +51,7 @@
   #endif
 #endif
 
+#undef PSY_API
+#define PSY_API
+
 #endif

(save it to a file, and then do git apply <file>)

Now do your build and it should succeed, but it won't work:

vuljaw@UK15132NB /d/dev/clones/psychec/build$ ./cnip.exe
D:/dev/clones/psychec/build/cnip.exe: error while loading shared libraries: msys-psychecommon.dll: cannot open shared object file: No such file or directory

to fix that:

find . -iname "*.dll" -exec cp {} . \;

such that you get:

vuljaw@UK15132NB /d/dev/clones/psychec/build$ ls *.dll
msys-psychecfe.dll*  msys-psychecommon.dll*  msys-psychecstd.dll*

now you'll have:

vuljaw@UK15132NB /d/dev/clones/psychec/build$ ./cnip.exe
cnip: input file unspecified

Unfortunately, I have no motivation to "wrap this up" into something that could become a PR. However, if you're happy with the manual steps, the above should be enough to "keep you moving".

aytey added a commit to aytey/psychec that referenced this issue Sep 24, 2021
…o#42

Signed-off-by: Andrew V. Jones <andrew.jones@vector.com>
@ltcmelo
Copy link
Owner

ltcmelo commented Sep 24, 2021

@geekrelief please check my reply to @andrewvaughanj 's PR here.

Thanks for trying to help @andrewvaughanj :-)

@geekrelief
Copy link
Author

@andrewvaughanj Thanks for the patch above. Following your directions I was able to get cnip working! I'm excited to try out the AST dump now! @ltcmelo FYI, I'm exploring options for creating a Nim binding for the The Machinery which is a new game engine written in C. The engine developers are in exploring options for making it easier for other languages to create bindings as well as doing stuff like documentation generation or processing on the source.

And I've been looking at various home grown solutions from Nim using tree-sitter, clang's AST, and custom parser solutions.

Thanks for getting back to me so quickly!

Btw, is there way to get Pyschec compiling from Visual Studio? Before going the MSYS route, I had cmake installed via scoop, and I was able to produce solution files. Unfortunately, trying to Build the ALL_BUILD solution hung VS. I tried applying your PR plus the change in CMakeLists.txt to skip the tests. Also had to remove /Wsign-compare, swapped cstdio's popen and pclose for stdio.h's _popen and _pclose, and tried compiling cnip again.

Unfortunately, VS still hangs. I see these errors in the output:

u16Uy83uur

@ltcmelo
Copy link
Owner

ltcmelo commented Sep 24, 2021

That's cool @geekrelief !

In regards to Windows/Visual Studio, I can't help much right now (maybe in the future). But it won't be only about compiling, there are portions of the code that might not behave properly in Windows — from the top of my mind, I can think of Process and CompilerFacade.

@andrewvaughanj I merged your patch, thanks again!

@aytey
Copy link
Contributor

aytey commented Sep 24, 2021

Compiling with MSVC probably isn't as easy as with MSYS -- especially with things such as the flags that the CMakeLists.txt set.

However the error you've linked in your screenshot (about the operators!) is going to be because it was "partially broken" in the diff I gave.

You should try this again now, because I did set the linkage for the operator<< calls (at least for those that matter).

@geekrelief
Copy link
Author

geekrelief commented Sep 25, 2021

You should try this again now, because I did set the linkage for the operator<< calls (at least for those that matter).

I retried the latest commit in master just now, and I still get the same errors about operator<< redefinition; different linkage. Anyway, I got it cnip working and dumping the AST for my headers, so now the next issue is how to deal with macros. :)

Thanks for the help!

@aytey
Copy link
Contributor

aytey commented Sep 25, 2021

Hmm, yeah, I hadn't noticed that it seems this header is used in both "common" and "cfe" -- std::ostream& operator<<(std::ostream& os, const Diagnostic& diagnostic) should only be dllexport inside of "common" and not inside of "cfe".

If those messages are correct, then it seems it has inconsistent linkage inside of those modules (it should be dllexport in "common" and dllimport in "cfe").

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants