-
Notifications
You must be signed in to change notification settings - Fork 280
Missing symbols when cross compiling for windows #26
Comments
I haven't updated the base distro for a while, maybe it's just an older version of the |
I've updated the base images, but my windows compilation now fails with:
Did you also encounter this, or is this a new error message already past the ones you reported? |
@karalabe Yeah, I encountered that as well, and it's a separate issue; you should apply this modification: cockroachdb/c-snappy#5 |
Ah yeah, with those two patches I'm at
I'll look into it. Have to run now. |
I've got past these error messages, but after crunching/compiling for 15-30 secs, it fails with
which is understandable, since there are no posix stuff available. Could you check why this file is getting included on the Windows builds? |
I've pushed out a new version with updates compilers and platform flags. Please allow a few hours for them to build, after which please try this Windows build. The above header issue should be in your code base. |
PS: You need to set |
Looks like that file shouldn't be included at all. I've removed it and force-pushed the branch. |
Now it crunched for a lot longer, then hit:
Edit: i.e. again managed to mingle in some non Windows specific header. |
This one's a bit trickier; the only way to get cgo to compile c/c++ code in general is to include (or symlink) the c/c++ files in your package's top level directory. In this case, This boils down to conditional compilation in cgo, which I'm not sure how to do. Do you have any ideas? EDIT: turns out this is the same story for |
Not really. Btw, just for the fun of it, I've removed that file for now, and then got till a linker failure:
|
Yeah, that's not surprising since we're not compiling any of the windows stuff. I think I have a solution though, stay tuned. |
Ah, ok. That was my second question. That if posix ports have been in there, where are the win ones :)). I have to run now, will only have time to look again tomorrow morning. Docker hub brilliantly crashed with a 500 internal server error while building the new images, so had to restart. Dunno if it'll survive this time. |
OK, I dropped another update; give it a try when you get some time. |
Will try it tomorrow. In the mean time the new images rolled out on docker hub, so you can also play with it (and the osx fixes). Just pull a fresh image via |
Got a lot further now, but failed on:
FWIW: https://msdn.microsoft.com/en-us/library/windows/desktop/aa379205(v=vs.85).aspx |
Out of curiosity, could you try the header with lowercase? Opposed to Windows the Linux cross compiler is case sensitive, and I'm almost certain all include files are lowercase in mingw. |
Bingo, that worked. Any way to bake this in so that it doesn't have to be repeated for every project? I had to make two such edits in this case: diff --git a/internal/port/win/env_win.cc b/internal/port/win/env_win.cc
index 70c68b8..600f7a9 100644
--- a/internal/port/win/env_win.cc
+++ b/internal/port/win/env_win.cc
@@ -34,8 +34,8 @@
#include "util/thread_status_updater.h"
#include "util/thread_status_util.h"
-#include <Rpc.h> // For UUID generation
-#include <Windows.h>
+#include <rpc.h> // For UUID generation
+#include <windows.h>
namespace rocksdb { Meanwhile, we're on to the next error:
EDIT: from http://stackoverflow.com/a/28904550/1261323:
No idea what to do about this one. By the way, separately from the above, the bit of cockroach that depends on c-snappy still fails with a linking error:
|
Regarding the i64 thing, the standard notation is However, the next error is:
Which according to MSDN too has too few parameters: https://msdn.microsoft.com/en-us/library/5dae5d43.aspx. |
Actually, it appears it has a 3-parameter overload:
This is in the same MSDN article you linked. |
Isn't that a template function that requires the Edit: I.e. the line above your snippet in MSDN. |
Sure, and in this case I believe it is. Here's our caller: strncpy_s(dir->entry_.d_name, dir->data_.name, strlen(dir->data_.name));
struct dirent {
char d_name[_MAX_PATH]; /* filename */
}; |
@karalabe now that the OSX issues are behind us, any thoughts on this? |
Updated the description and subject to indicate that this seems to be a problem with Secure Template Overloads. |
Looks like a bug in mingw-w64! https://sourceforge.net/p/mingw-w64/bugs/535/ I've sent a patch to their mailing list. After applying the patch, we're back to something that might be an xgo problem:
Note that |
The missing overloads patch has been accepted into mingw-w64: https://sourceforge.net/p/mingw-w64/mingw-w64/ci/6ec4fb2d8c1b1abfd5aca69c382c24feb6961342/ |
Ah awesome. We (Ethereum) were doing our big release for a while now, just went out a few hours ago so hopefully I'll find a bit more time to address xgo issues too. I'm a bit afraid of the overhead required to build mingw within xgo. I'll look into as to what it would entail. |
OK, so folks on the mingw-w64 mailing list have suggested that windows' portable executables don't support undefined symbols after link-time, so xgo is probably not at fault here any more. The rest of this is tracked in golang/go#14985. It'd be nice to package a more recent mingw-w64 release in xgo, but I'm going to close this thread all the same. |
Update: there appears to be a bug upstream (in mingw-w64) https://sourceforge.net/p/mingw-w64/bugs/535/.
Currently, it appears that the cgo linker option
-Wl,-unresolved-symbols=ignore-all
isn't behaving correctly.The text was updated successfully, but these errors were encountered: