Building cryptest.exe fails on MinGW-w64 #28
Comments
|
so did someone fixed that? |
|
To fix this error you can put in front of the function memcpy_s your namespace. If you put |
|
@IlyaBizyaev - forgive my ignorance... When I search MinGW's site for the 64-bit download, I cannot find it. Confer: search: mingw64. I did find a quote: "In the future, other subsystems such as mingw64 may be supported...". The best I can tell, there is no MinGW-64. Where, exactly, does MinGW make the download available? (I can see where this ambiguity comes from, and we are going to clear it. I'm asking about the download because I want to get a test environment setup for this platform). |
|
The download page is here: http://mingw-w64.org/doku.php/download |
|
Thanks Ilya. Something looks very fishy here... MinGW does not recognize the project. And it appears different individuals have administrative control, and the projects are based in different countries. At minimum, I would expect email addresses to be consistent. I.e., both use _mingw-users-owner@lists.sourceforge.net_ because its MinGW. And I definetly don't trust these garbage addresses: _b6wnwyoptcoe5n6efws9@e.o-w-o.info_. |
|
Yes, MinGW-w64 is a fork, but a popular one. It seems to me that lots of former MinGW project participants moved there. |
|
Just read more on the main page: http://mingw-w64.org/doku.php/start |
|
Here is their mailing list: mingw-w64-public@lists.sourceforge.net |
|
Thanks again. I followed the link you provided, then followed to downloads. It took me to http://mingw-w64.org/doku.php/download. In the download matrix, I tried to download MinGW builds (http://mingw-w64.org/doku.php/download/mingw-builds), Win-Builds (http://mingw-w64.org/doku.php/download/win-builds) and Msys2 (http://mingw-w64.org/doku.php/download/msys2). None of them appear to provide a MinGW64 download. It looks like they sent me to empty wiki pages. Where, exactly, is there download in that table? Or, can you test RC6 at https://sourceforge.net/projects/cryptopp/files/cryptopp/5.6.3/ ? Or, can you provide me with remote access to one of your machines that has it installed? |
Assuming you installed Msys2, you need to do the following on the first launch:
Then you can install Msys2 provides 3 shortcuts: "MSYS2 Shell", "MinGW-w64 Win32 Shell" and "MinGW-w64 Win64 Shell", you need to use the 2nd to compile 32-bit binaries and the 3rd to compile 64-bit binaries. |
|
This happens because MinGW-w64 has its own implementation of You can fix this by replacing: #if (!__STDC_WANT_SECURE_LIB__ && !defined(_MEMORY_S_DEFINED))
with: #if (!__STDC_WANT_SECURE_LIB__ && !defined(_MEMORY_S_DEFINED) && !defined(__MINGW64__))
in misc.h. |
|
Sorry, I cannot remember the exact download. By the way, @Zireael-N, I simply use MSYS that comes with MinGW-32. |
The Msys2 part was addressed to Jeffrey. Have you tried doing what I suggested here? Line 212 in 1d5bcc0 |
|
@IlyaBizyaev, @Zireael-N - I have more bad news.... I tried to install MinGW and MinGW-64 on two different machines - Windows 7 and Windows 8. Only one of them ever worked for me (MinGW/Windows 7); the other three never worked. Now the WIndows 7/MinGW machine is broken: The same tests ran fine yesterday. I've tried reinstalling MinGW, but that did not help. MinGW and MinGW-64 don't seem to have the stability we expect or need (or at least for me under the role of tester). MinGW and MinGW-64 cause me more problems than Debian Unstable :) I'm going to remove MinGW and MinGW-64 from my testing regime. It causes too many problems (and a lot of frustration), and the time can be better spent elsewhere (for me). We talked about similar on the Crypto++ mailing list recently; see Strategy for Accommodating Unstable Platforms and Tools. Consensus was we should make an effort, but not waste too much time on platforms like these. Group consensus is important because it gives me authority to act. Without consensus, I have no authority and I cannot act. Don't read too much into it. I only said "... remove MinGW and MinGW-64 from my testing regime" because my time is better spent elsewhere. I did not say we should drop support altogether. Would either of you guys pick up the torch and take responsibility for this platform?
I should probably qualify this now... Sadly, this is not in a vaccuum. MinGW and MinGW-64 changes could affect down level MinGW versions, Windows and Cygwin. So testing should include something for those platforms, too. I can test the changes under the older platforms, like Windows XP, Windows Vista, Visual Studio 2005 and Visual Studio 2008. |
|
@Zireael-N, @IlyaBizyaev, @Liberus
I believe the library provides I think the change is consistent with what's supposed to happen. Does anyone see any problems with it? If there are no objections, then can someone test it and perform a merge request? |
I don't understand whether it says it can't find /bin/bash or ./cryptest.sh. But the repository certainly doesn't have the script: I'm experiencing this when trying to build tests: Was getting I'll try different compilation options to see if it can be fixed. And about There's a diff in default defines between MinGW and MinGW-w64 with i686 toolchain. The ones that are worth looking at: +#define __SIZEOF_FLOAT80__ 12
+#define __SIZEOF_FLOAT128__ 16
+#define __STDC_UTF_16__ 1
+#define __STDC_UTF_32__ 1
+#define __STDC_VERSION__ 201112L
+#define __GNUC_STDC_INLINE__ 1
-#define __GNUC_GNU_INLINE__ 1And the whole list: https://gist.github.com/Zireael-N/15240b72b30796b5184f |
|
Okay, that error had nothing to do with compilation options: Notice how WindowsPipeReceiver inherits Line 69 in 697ccb4 See https://github.com/Zireael-N/cryptopp/commit/f9bf7190cc4821b0d35e6c230ee35008f80e4ea2 ; if it's a correct guess as to what it's supposed to do, I'll make a pull request. Edit: I found the script on Crypto++'s Wiki. Takes an eternity to run. :( The results are: 15 of them are 3 of them are: Another edit: I see that you've updated the repo with RC6, now I'm getting this: |
|
Hello, @noloader ! As for your script, I don't quite understand it.
As for your suggestion to take responsibility on the platform, I can only say that if I could fix it myself, I wouldn't have asked for solution here 😉 That's not the area I'm good at (at least for now). And finally, which alternatives to MinGW would you suggest? |
|
The fixed, proposed by @Zireael-N, works fine, and both libcryptopp and cryptest.exe compile fine under MinGW-w64 (no matter if unalign data access is allowed or not) 😄 . |
|
What's interesting is that the Crypto++ that I clone with Git and the one I download in archive from GitHub differ really much! And that's how the one from *.zip looks: |
Hmmm.... I'm not sure what GitHub is providing as a ZIP. You should probably abandon it if it does not pass the sniff test. The ZIP download from the website is OK. You can find it at http://www.cryptopp.com/cryptopp563rc6.zip . I verified http://www.cryptopp.com/cryptopp563rc6.zip provides the changes. Can you switch to the clone and verify the issues still exist (or no longer exist) with the latest check-in? Or, can you verify the issues still exist (or no longer exist) with cryptopp563rc6.zip? |
Oh man... Try a Debian Chroot. it takes 6 to 12 hours to verify a change set on, say, S/390 or ARMHF.
This was because The only thing that really changed is we are now testing it. I believe the fix has been checked in. |
OK, we will need more details. "no matter if unalign data access is allowed or not..." - that's controlled by And then: I'm not sure how it can work one way but not another because everything pivots on |
|
The build now looks completely different! That seems to be a GitHub issue... |
Would you post the output of the following commands? They will dump the preprocessor symbols. Provide them for both MinGW-32 and MinGW-64. Make them available for download somewhere. Or ZIP them and email them to me and Zireael. This uses the compiler driver to tell us what it is defining. It will invoke The MinGW-32 issue is being tracked under Issue 58: Rollup of errata items to be fixed before release. |
Check the end of this message. |
Too much noise in the diff. There's no need for diff tell me there's a different between Add a I am also interested in some of the usual suspects, like |
|
I'm not entirely sure where I need to add
That's why I mentioned the ones that actually do matter before giving a link to the full list.
I was actually comparing MinGW-w64 with a 32-bit toolchain vs MinGW. It's a bit confusing but the former can compile both 32 and 64-bit binaries while the latter can only compile 32-bit binaries. That's why checking for The former does have |
Perfect. Let's wait to hear back from Ilya. If all goes well, then I'll close it. Hallelujah. |
Not really. The test executable's code is within CryptoPP namespace. Thus, it sees both CryptoPP::memcpy_s and the library's memcpy_s when using MinGW-w64. This shouldn't be a problem to you unless you use |
Like Neo said: the problem is choice. Also see What is the logic behind the “using” keyword in C++? on Stack Overflow. |
|
OK. The only question left is how should I check this solution.
|
Yes, I can use And if I remove |
|
OK, that's great! Let me compile it and see. |
This probably needs a new bug report if its a new issue.
You might want to perform a |
|
For completeness, this code: Was present going back to at least Crypto++ 5.6.1. |
|
So I'm clear... Is this your change? |
|
It's MINGW32. MINGW is not defined. |
|
No, @Zireael-N , @noloader... That doesn't work. Here is the full build log: Diffs: diff --git a/config.h b/config.h
index 9728ee2..bd66ad1 100644
--- a/config.h
+++ b/config.h
@@ -35,7 +35,7 @@
// Define this to ensure C/C++ standard compliance and respect for GCC aliasing rules and other alignment fodder. If you
// experience a break with GCC at -O3, you should try this first. Guard it in case its set on the command line (and it differs).
#ifndef CRYPTOPP_NO_UNALIGNED_DATA_ACCESS
-// # define CRYPTOPP_NO_UNALIGNED_DATA_ACCESS
+# define CRYPTOPP_NO_UNALIGNED_DATA_ACCESS
#endif
// ***************** Less Important Settings ***************
diff --git a/validat1.cpp b/validat1.cpp
index 478199f..4fccb50 100644
--- a/validat1.cpp
+++ b/validat1.cpp
@@ -150,6 +150,9 @@ bool TestSettings()
cout << "\nTesting Settings...\n\n";
word32 w;
+ #if defined(__MINGW32__)
+ using CryptoPP::memcpy_s;
+ #endif
memcpy_s(&w, sizeof(w), "\x01\x02\x03\x04", 4);
if (w == 0x04030201L)
g++ -dumpmachine: x86_64-w64-mingw32 |
|
MinGW-32 doesn't build it either. |
|
Of course it doesn't work! You forgot to remove Change: #if (!__STDC_WANT_SECURE_LIB__ && !defined(_MEMORY_S_DEFINED)) && !(defined(__MINGW__) || defined(__MINGW32__))
to: #if (!__STDC_WANT_SECURE_LIB__ && !defined(_MEMORY_S_DEFINED))
|
Ah, good catch... I was staring at it scratching my head.... |
|
@IlyaBizyaev - Did Zireael's observation clear the issue for you? |
|
There are good news and a bad one.
And on MGW32, all symbols are OK, but... remember that annoying issue with m_allocated? So, here it is... |
|
But I think those are different issues. What about pushing the changes and closing this issue? |
|
I've used |
You can use Here is randpool.h, and here is randpool.cpp. Nothing depends on |
|
Closing... |
|
Hello! I'm get last version from git. When compile (Qt 5.5.1 (mingw492_32)) there is next error my changes in file: validat1.cpp is |
g++ -v output:
The text was updated successfully, but these errors were encountered: