I'm following the instructions from INSTALL.W32 (various OpenSSL versions), in general it's:
* Configure for building with Borland Builder:
> perl Configure BC-32
* Create the appropriate makefile
> ms\do_nasm
* Build
> make -f ms\bcb.mak
Now, I do get two kind of errors when trying to build:
For OpenSSL < 1.0.0
nasmw -f obj -d__omf__ -ocrypto\md5\asm\m5_win32.obj .\crypto\md5\asm\m5_win32.asm
'nasmw' is not recognized as an internal or external command,
operable program or batch file.
Otherwise
Warning W8017 C:\CBuilder5\Include\sys/stat.h 34: Redefinition of 'S_IFMT' is not identical
Warning W8017 C:\CBuilder5\Include\sys/stat.h 35: Redefinition of 'S_IFDIR' is not identical
Error E2227 .\crypto\rand\randfile.c 226: Extra parameter in call to _open in function RAND_write_file
Warning W8053 .\crypto\rand\randfile.c 262: '_chmod(const signed char *,int,...)' is obsolete in function RAND_write_file
*** 1 errors in Compile ***
Yes, I feel bad for using Borland C++ Builder 5 but I can't do anything about it, and yes, I consider the Shining Light option if everything else fails.
I do not use OpenSSL but from your text some hints:
NASM
is not default assembler for Borland compilers
you need to download and install it first
(it is for free and one of the best compilers I used in the past)
you are missing some #define before including OpenSSL or including in wrong order
that is why you have the first warnings and most likely also the error
some libs need to add configuration #defines (added by some specific IDE's)
to specify what compiler,platform,endianess... is used
before any includes
usually if you include in wrong order then the defines are defined for some instances of a lib file but not for all
so try to reorder the includes
sometimes helps to include before the lib some other thing like conio,stdio,windows,...
to determine which define is missing or wrong open the stat.h
and look for #ifdef #ifndef statements around S_IFMT
The solution for the newest version (1.0.2d) was to:
remove the extra parameter from randfile (which, as comment stated, was unnecessary),
edit ms\bcb.mak, search for -DMD5_ASM -DSHA1_ASM -DRMD160_ASM
and change to -DMD5_NO_ASM -DSHA1_NO_ASM -DRMD160_NO_ASM . (there was an unresolved external error with SHA, MD5 and RMD160, they basically couldn't be compiled in asm).
There were some other steps included as well, but they're just specific to my environment.
Related
So I am trying to compile this flip fluids addon with blender, so I followed this tutorial, https://www.youtube.com/watch?v=TVKM1egDoGs , So I first ran cmake.exe -G "MinGW Makefiles" .. and it was telling me that it was missing a CMakeLists File... So I added one... then I ran cmake.exe --build . and it got to 3 percent than showed me errors like ...
In file included from C:/Users/N/Downloads/Blender-FLIP-Fluids-master/src/engine/threadutils.h:29,
from C:/Users/N/Downloads/Blender-FLIP-Fluids-master/src/engine/meshlevelset.h:65,
from C:/Users/N/Downloads/Blender-FLIP-Fluids-master/src/engine/meshobject.h:30,
from C:/Users/N/Downloads/Blender-FLIP-Fluids-master/src/engine/fluidsimulation.h:38,
from C:\Users\N\Downloads\Blender-FLIP-Fluids-master\src\engine\c_bindings\fluidsimulation_c.cpp:25:
C:/PROGRA~2/MINGW-~1/I686-8~1.0-P/mingw32/lib/gcc/i686-w64-mingw32/8.1.0/include/c++/mutex:93:9: note: previous definition of 'class std::recursive_mutex'
class recursive_mutex : private __recursive_mutex_base
^~~~~~~~~~~~~~~
In file included from C:/Users/N/Downloads/Blender-FLIP-Fluids-master/src/engine/mingw32_threads/mingw.condition_variable.h:25,
from C:/Users/N/Downloads/Blender-FLIP-Fluids-master/src/engine/threadutils.h:31,
from C:/Users/N/Downloads/Blender-FLIP-Fluids-master/src/engine/meshlevelset.h:65,
from C:/Users/N/Downloads/Blender-FLIP-Fluids-master/src/engine/meshobject.h:30,
from C:/Users/N/Downloads/Blender-FLIP-Fluids-master/src/engine/fluidsimulation.h:38,
from C:\Users\N\Downloads\Blender-FLIP-Fluids-master\src\engine\c_bindings\fluidsimulation_c.cpp:25:
C:/Users/N/Downloads/Blender-FLIP-Fluids-master/src/engine/mingw32_threads/mingw.mutex.h:142:44: error: conflicting declaration 'typedef class std::_NonRecursive<std::recursive_mutex> std::mutex'
This is the full error https://pastebin.com/KTnALG1E, where is this coming from?? is it a mingw error or what? Can someone help please?
Your full error message includes a more interesting bit:
C:/Users/N/Downloads/Blender-FLIP-Fluids-master/src/engine/mingw32_threads/mingw.thread.h:32:2:
error: #error This version of MinGW seems to include a win32 port of
pthreads, and probably already has C++11 std threading classes
implemented, based on pthreads. It is likely that you will get class
redefinition errors below, and unfortunately this implementation can
not be used standalone and independent of the system header,
since it relies on it for std::unique_lock and other utility classes.
If you would still like to use this implementation (as it is more
lightweight), you have to edit the c++-config.h system header of your
MinGW to not define _GLIBCXX_HAS_GTHREADS. This will prevent system
headers from defining actual threading classes while still defining
the necessary utility classes.
So either install a different version of mingw or edit your mingw files according to the instructions above.
Trying to build Tink library (https://github.com/google/tink) with Bazel. Bazel installed, gcc version 7.2.0, Windows 10 x64. Visual C++ 2017.
At first, there were errors like "C++ compilation of rule '#boringssl//:crypto' failed" - I commented these lines (with compilation flags I think) in boringssl/BUILD file (sections boringssl_copts, boringssl_copts_c11) and they disappeared.
But after that, bazel said, that error is in errors.h file (https://github.com/google/tink/blob/master/cc/util/errors.h)
// from #include "absl/base/port.h"
#define PRINTF_ATTRIBUTE(string_index, first_to_check) \
__attribute__((__format__ (__printf__, string_index, first_to_check)))
// Constructs a Status object given a printf-style va list.
crypto::tink::util::Status ToStatusF(
crypto::tink::util::error::Code code, const char* format, ...)
PRINTF_ATTRIBUTE(2, 3);
} // namespace tink
} // namespace crypto
enter code here
Error C3646: unknown override specifier on line 32 (line with "PRINTF_ATTRIBUTE(2, 3);"). The most frightening thing is that in another files the same code (defining same attribute) is working.
There are another errors in this file, but mentioned is the first (and another are about the same line, so they are consequences of the first I guess).
I'm nearly a total newbie in cpp, but only cpp should be used, not java-version of library.
Thank you for your help, and sorry for possible misformatting and broken english - this is my first question here.
Unfortunately, we don't support Windows for now. It's something that we plan to support next year, please see our feature roadmap.
I am trying to compile the boost log library and I keep getting this error from the dump_avx2.cpp file
error: always_inline function '_mm256_set1_epi32' requires target feature 'sse4.2', but would be inlined into function 'dump_data_avx2' that is compiled without support for 'sse4.2'
boost/boost/libs/log/src/dump_avx2.cpp:71:31: note: expanded from macro 'BOOST_LOG_AUX_MM_CONSTANTS'
const __m256i mm_char_0 = _mm256_set1_epi32(0x30303030);\
^
I get a lot of errors that are very similar to the one above, all of them have the same error message but different locations in the file where they occur, for reference I am on the commit hash 68701167a1020b0b4c47b76e31d3a3da9e2faf3f for the Boost.Log submodule as fetched from the github repo (https://github.com/boostorg/boost)
Does anyone know how I can go about resolving this issue? I am building with a C++14 compiler and this is what I get when I type g++ --version
Apple LLVM version 8.0.0 (clang-800.0.42.1)
Thanks!
Note I should clarify that in this context it is required that I compile this library separately.
Note There seem to be two related source files dump_ssse3.cpp and the mentioned dump_avx2.cpp file, do I have to compile only one of them? I cannot make out what to do from the Jamfile in the build folder :(
That looks like a bug in clang (LLVM). First, the intrinsic belongs to AVX2, not SSE4.2. Second, the whole dump_avx2.cpp file is compiled with -mavx2, so the required extensions are enabled. You can see the compiler switches in the error message from b2. And no, both dump_ssse3.cpp and dump_avx2.cpp should be compiled. The library does runtime detection of the available instructions in the CPU and selects the proper implementation.
I use MinGW64+msys on Winodws7 64bit
Now I’m trying to build CMAKE but I can’t.
When I typed ./configure soon an error happened. .
---------------------------------------------
CMake 3.2.3, Copyright 2000-2015 Kitware, Inc.
Found GNU toolchain
C compiler on this system is: gcc
---------------------------------------------
Error when bootstrapping CMake:
Cannot find appropriate C++ compiler on this system.
Please specify one using environment variable CXX.
See cmake_bootstrap.log for compilers attempted.
I also find error messages in Bootstrap.cmk/cmake_bootstrap.log like bellow.
[First Message in the log file]
In file included from c:/mingw64/x86_64-w64-mingw32/include/c++/iosfwd:40:0,^M
from c:/mingw64/x86_64-w64-mingw32/include/c++/ios:38,^M
from c:/mingw64/x86_64-w64-mingw32/include/c++/ostream:38,^M
from c:/mingw64/x86_64-w64-mingw32/include/c++/iostream:39,^M
from cmake_bootstrap_4468_test.cxx:3:^M
c:/mingw64/x86_64-w64-mingw32/include/c++/bits/postypes.h:40:35: fatal error: cw
char: No such file or directory^M
compilation terminated.^M
[Second Message in the log file]
cmake_bootstrap_4468_test.cxx:5:23: fatal error: iostream.h: No such file or dir
ectory^M
compilation terminated.^M
Test failed to compile
They said cwchar and iostream.h doesn't exist, although I have them and set their path to environmental variable.
The first massage said my C++ compiler isn’t appropriate. I installed it by mingw-get.exe.
Does anyone know, how can I get appropriate C++ compiler?
You mixed two compilers. I recommend: delete your old one and install msys2+mingw64.
I am using PC-lint on windows PC( platform) .
I am running my code but getting this errors/warning and after some percentage of running my code is getting crashed .All errors are related to linting only .
Warnings:
C:\Program Files\Texas Instruments\ndk_x_xx_xx_xxx\packages\ti\ndk\inc\usertype.h(118): Note 960: Violates MISRA 2004 Required Rule 10.6, Unsigned integer literals require a 'U' suffix
C:\Program Files\Texas Instruments\ndk_x_xx_xx_xxx\packages\ti\ndk\inc\usertype.h(145): Note 960: Violates MISRA 2004 Required Rule 10.6, Unsigned integer literals require a 'U' suffix
C:\Program Files\Texas Instruments\ndk_x_xx_xx_xxx\packages\ti\ndk\inc\socket.h(53): Note 960: Violates MISRA 2004 Required Rule 10.6, Unsigned integer literals require a 'U' suffix
C:\Program Files\Texas Instruments\ndk_x_xx_xx_xxx\packages\ti\ndk\inc\socket.h(159): Note 970: Use of modifier or type 'int' outside of a typedef [MISRA 2004 Rule 6.3] ......
As I cannot modify that ndk package .So I want to exclude that files from my linting process ...I got some old answers from stack Overflow but these are related with source files not for header files .
I am having problem in header files like usertype.h and socket.h etc etc
i tried to put -efile(960,usertype.h) option in my lint.lnt file but issue was still there .
Can you please tell me the solution for this ???
-Ashwin
If you get warnings numbered 900 and above, you are running on warning level 4, which is far too high for normal operation. I would start on warning level 1 (syntax only) and make sure everything runs properly. Then you can increase to 2 or 3, and selectively enable some individual warnings from the range 900+ and/or 1900+.
To skip certain parts in the checking process, simply remove the c/c++ source files from the configuration or command line. But make sure to retain the directories as include directories, since other files will need to include those interface headers.
The option -efile is not intended to suppress warnings within a file, but rather to suppress warnings about a file. Look in the description of the option in the manual for details.
The way to limit warnings in source code you are not responsible for is to declare that source code to be 'libraries'. The whole chapter 6 of the PC-Lint manual is devoted to this subject. You can start with -wlib(1) to use warning level 1 (syntax only) for library files, then define what you want to be considered library files with +libclass, +-libdir, and +-libh options. And if you want to see if a certain include file is considered to be a 'library'-header, run PC-Lint with the option -vf.