When I try to use the cl -LD test.c -test.dll, it says can not open "python26.lib", why this happens?? thank you. (I was trying to generate a dll file by this command so that python could call it)
Taken from this link - Hope this will help you -
This is caused by the following lines in the file c:\Python26\include
\pyconfig.h
# ifdef _DEBUG
# pragma comment(lib,"python26_d.lib")
# else
# pragma comment(lib,"python26.lib")
# endif /* _DEBUG */
So please:
Provide python26_d.lib in the
installer.
or
Remove this automatic "pragma
comment lib" from pyconfig.h, since
I can't disable it from the outside
(as far as I know).
Related
I'm able to run clang-tidy with my source file clang-tidy -p build/compile_commands.json filename.h and it works as expected. When I open the file through vim I get errors with the first #includes, which happens if I leave the -p option off the invocation.
In my vimrc I tried setting g:ale_c_build_dir to build and that didn't work, so I tried setting g:ale_cpp_clangtidy_extra_options with the -p argument above and that didn't work. I'm able to confirm that these values are being set properly with ALEInfo, they're just not being used in the clang-tidy invocation apparently.
I am currently trying to set ALE up with clang-tidy myself, and eventually got it working with the following config:
let g:ale_linters = {
\ 'cpp': ['clangtidy'],
\ 'c': ['clangtidy'],
\}
let g:ale_fixers={
\ 'cpp': ['clang-format'],
\ '*': ['remove_trailing_lines', 'trim_whitespace'],
\}
let g:ale_cpp_clangtidy_checks = []
let g:ale_cpp_clangtidy_executable = 'clang-tidy'
let g:ale_c_parse_compile_commands=1
let g:ale_cpp_clangtidy_extra_options = ''
let g:ale_cpp_clangtidy_options = ''
let g:ale_set_balloons=1
let g:ale_linters_explicit=1
let g:airline#extensions#ale#enabled=1
As you can see, i have skipped setting g:ale_c_build_dir_names or g:ale_c_build_dir, since the defaults should do the job just fine (see excerpts from documentation below), given that your compile_commands.json resides in build or bin directory of the root of your project. One thing i have noticed is that linting with clang-tidy when used as ALE's linter is very slow.
g:ale_c_build_dir_names
Type: List
Default: ['build', 'bin']
A list of directory names to be used when searching upwards from cpp
files to discover compilation databases with. For directory named 'foo',
ALE will search for 'foo/compile_commands.json' in all directories on and above
the directory containing the cpp file to find path to compilation database.
This feature is useful for the clang tools wrapped around LibTooling (namely
here, clang-tidy)
And:
g:ale_c_build_dir
Type: String
Default: ''
For programs that can read compile_commands.json files, this option can be
set to the directory containing the file for the project. ALE will try to
determine the location of compile_commands.json automatically, but if your
file exists in some other directory, you can set this option so ALE will
know where it is.
This directory will be searched instead of g:ale_c_build_dir_names.
I have a project, I built it with intel compiler. I want use the clang-tidy to help detect code problems.
I am using CMake to generate compile_commands.json and I'm getting the follow error when I using clang-tidy:
$ run-clang-tidy
# output
# ...
clang-tidy-6.0 -header-filter=^/home/xuhui/temp/build/.* -p=/home/xuhui/temp/build /home/xuhui/temp/main.cpp
1 warning and 1 error generated.
Error while processing /home/xuhui/temp/main.cpp.
error: unknown argument: '-w2' [clang-diagnostic-error]
warning: unknown warning option '-Wno-maybe-uninitialized'; did you mean '-Wno-uninitialized'? [clang-diagnostic-unknown-warning-option]
Actually, there is a very simliar question exist: clang-tidy reporting unknown warnings
However, when I try to using the method refered above, there is no help. The warning can be suppressed but error still exist.
$ run-clang-tidy -extra-arg=-Wno-unknown-warning-option
# output
# ...
clang-tidy-6.0 -header-filter=^/home/xuhui/temp/build/.* -extra-arg=-Wno-unknown-warning-option -p=/home/xuhui/temp/build /home/xuhui/temp/main.cpp
1 error generated.
Error while processing /home/xuhui/temp/main.cpp.
error: unknown argument: '-w2' [clang-diagnostic-error]
How can I deal with the error?
-w2 options is used to control warning in intel compiler.
Although the problem occurs to me because of the intel compiler, but may be other compiler's options can also leads to the problem.
Appendix
The follow code snippets can help reproduce the problem.
// CMakeLists.txt
SET(CMAKE_CXX_COMPILER "icc")
SET(CMAKE_CXX_COMPILER "icpc")
project(test)
# leads to warning, can be settled by refer link
add_compile_options("-Wno-maybe-uninitialized")
# leads to error, can not be settled by refer link
add_compile_options("-w2")
add_executable(a.out main.cpp)
set(CMAKE_EXPORT_COMPILE_COMMANDS ON)
// main.cpp
#include <iostream>
int main()
{
std::cout << "hello!" << std::endl;
return 0;
}
the above code can generate compile_commands.json like follows:
[
{
"directory": "/home/xuhui/temp/build",
"command": "/opt/intel/compilers_and_libraries_2019.0.117/linux/bin/intel64/icpc -Wno-maybe-uninitialized -w2 -o CMakeFiles/a.out.dir/main.o -c /home/xuhui/temp/main.cpp",
"file": "/home/xuhui/temp/main.cpp"
}
]
Thanks for your time.
This is not a clang-tidy error per se. Clang-diagnostic-error is basically a compiler error. Clang has made unknown arguments a hard error some time ago and it cannot be degraded to a warning. There used to be -Qunused-arguments but that doesn't work in Clang 11 AFAIK.
You will have to remove the argument before passing the compile commands to clang-tidy, I suggest CMake - remove a compile flag for a single translation unit.
#pablo285 already give the perfect answer.
He said that:
have to remove the argument before passing the compile commands to
clang-tidy
He already provide a link to demonstate how to modify CMakeLists.txt to remove argument.
Also, we can do some modification directly on compile_commands.json to remove argument.
A script to tidy code can be written as follows:
# tidy_code.sh
cd build
cmake ..
# do modification on compile_commands.json to remove argument which clang can not recognized
# replace '-w2' to ' '
sed -i 's/-w2/ /g' compile_commands.json
# using clang tidy
run-clang-tidy -checks='*' -extra-arg=-Wno-unknown-warning-option
I am trying to build the AWS C++ SDK on Solaris, but I cannot do so successfully.
I found this open issue on the AWS C++ SDK page that says it is possible, but there is no guide on it and I am hoping somebody here can help.
Here is the command I use to build it:
$ cmake ../aws-sdk-cpp/ -DCMAKE_BUILD_TYPE=Debug -DBUILD_ONLY="s3"
Here is the output:
-- TARGET_ARCH not specified; inferring host OS to be platform compilation target
-- Building AWS libraries as shared objects
-- Generating linux build config
-- Building project version: 1.7.134
-- Configuring done
-- Generating done
-- Build files have been written to: /workspace/dmoini/sdk_build/.deps
gmake: Warning: File 'Makefile' has modification time 267 s in the future
gmake[1]: Warning: File 'CMakeFiles/Makefile2' has modification time 267 s in the future
gmake[2]: Warning: File 'CMakeFiles/AwsCCommon.dir/progress.make' has modification time 267 s in the future
gmake[2]: warning: Clock skew detected. Your build may be incomplete.
gmake[2]: Warning: File 'CMakeFiles/AwsCCommon.dir/progress.make' has modification time 267 s in the future
[ 4%] Performing build step for 'AwsCCommon'
[ 1%] Building C object CMakeFiles/aws-c-common.dir/source/array_list.c.o
In file included from /usr/include/stdio.h:37:0,
from /workspace/dmoini/sdk_build/.deps/build/src/AwsCCommon/include/aws/common/common.h:22,
from /workspace/dmoini/sdk_build/.deps/build/src/AwsCCommon/include/aws/common/array_list.h:18,
from /workspace/dmoini/sdk_build/.deps/build/src/AwsCCommon/source/array_list.c:16:
/opt/gcc-5.1.0/lib/gcc/i386-pc-solaris2.11/5.1.0/include-fixed/sys/feature_tests.h:405:2: error: #error "Compiler or options invalid for pre-UNIX 03 X/Open applications and pre-2001 POSIX applications"
#error "Compiler or options invalid for pre-UNIX 03 X/Open applications \
^
gmake[5]: *** [CMakeFiles/aws-c-common.dir/build.make:63: CMakeFiles/aws-c-common.dir/source/array_list.c.o] Error 1
gmake[4]: *** [CMakeFiles/Makefile2:484: CMakeFiles/aws-c-common.dir/all] Error 2
gmake[3]: *** [Makefile:139: all] Error 2
gmake[2]: *** [CMakeFiles/AwsCCommon.dir/build.make:112: build/src/AwsCCommon-stamp/AwsCCommon-build] Error 2
gmake[1]: *** [CMakeFiles/Makefile2:68: CMakeFiles/AwsCCommon.dir/all] Error 2
gmake: *** [Makefile:84: all] Error 2
CMake Error at CMakeLists.txt:193 (message):
Failed to build third-party libraries.
Additionally, here is my system information:
$ uname -a
SunOS bld-dmoini-01-sv4b 5.11 omnios-r151020-4151d05 i86pc i386 i86pc
Any and all help/guidance is greatly appreciated.
I've successfully completed compiling the AWS C++ SDK on a stock install of Solaris 11.4, and found several issues that could cause the problems noted.
Start with a clean source tree.
Remove -Werror
The first thing do to is remove the -Werror compiler options. The version of OpenSSL installed by default on Solaris 11.4 has quite a few deprecated functions, and the -Werror option causes the build to fail when it runs into those deprecations. I used this find command run from the topmost directory of the AWS SDK source tree to remove all the -Werror options:
vi `find . | xargs grep -l Werror`
You'll get about three or four files, only two of which are actually setting the -Werror as a compiler option. Just remove the "-Werror" strings from those files.
Fix the POSIX defines
Then run cmake . in the topmost directory. It will fail because the cmake files that it downloads will have improper POSIX command-line options - -D_POSIX_C_SOURCE=200809L -D_XOPEN_SOURCE=500. That 500 is wrong. _POSIX_C_SOURCE=200809L corresponds to _XOPEN_SOURCE=700. _XOPEN_SOURCE=500 is SUSv2, circa 1997. It's not proper to compile a SUSv2 application with C99.
Per 2.2.1 Strictly Conforming POSIX Application, paragraph 8:
For the C programming language, shall define _POSIX_C_SOURCE to be 200809L before any header is included
and 2.2.4 Strictly Conforming XSI Application, paragraph 8:
For the C programming language, shall define _XOPEN_SOURCE to be 700 before any header is included
Per the Illumos sys/feature_tests.h file (based on OpenSolaris, which was also the basis for Solaris 11):
* Feature Test Macro Specification
* ------------------------------------------------ -------------
* _XOPEN_SOURCE XPG3
* _XOPEN_SOURCE && _XOPEN_VERSION = 4 XPG4
* _XOPEN_SOURCE && _XOPEN_SOURCE_EXTENDED = 1 XPG4v2
* _XOPEN_SOURCE = 500 XPG5
* _XOPEN_SOURCE = 600 (or POSIX_C_SOURCE=200112L) XPG6
* _XOPEN_SOURCE = 700 (or POSIX_C_SOURCE=200809L) XPG7
The files cmake downloads via git need to be edited:
vi `find .deps | xargs grep -l XOPEN_SOURCE`
Change any -D_XOPEN_SOURCE=500 to -D_XOPEN_SOURCE=700 and rerun cmake .. It should complete successfully this time.
Then run gmake. (I find gmake works much better on Solaris for just about all open source projects, as many open source projects use GNU-specific make extensions.)
Now you get to fix any broken source code you run into.
Fix broken source code
1
The file aws-sdk-cpp/aws-cpp-sdk-core/source/platform/linux-shared/OSVersionInfo.cpp has the following wrong code:
Aws::String ComputeOSVersionString()
{
utsname name;
int32_t success = uname(&name);
Per POSIX, the correct type is struct utsname, not just utsname:
int uname(struct utsname *name);
The AWS code needs to be:
Aws::String ComputeOSVersionString()
{
struct utsname name;
int success = uname(&name);
And no, I'm most certainly not impressed with the quality of the AWS code, given this, umm, laugher:
while (!feof(outputStream))
Yes, an actual while (!feof()) loop...
2
The file aws-sdk-cpp/aws-cpp-sdk-mediaconvert/include/aws/mediaconvert/model/M2tsSegmentationMarkers.h uses an enumeration with the value EBP, which conflicts with the EBP register #define in /usr/include/sys/regset.h.
I just changed it to EBP_HASH as that seems to match the code somewhat:
vi `find . | xargs grep -l EBP`
3
The file aws-sdk-cpp/aws-cpp-sdk-route53domains/include/aws/route53domains/model/CountryCode.h creates an enumeration value ES that conflicts with the ES register #define in /usr/include/sys/regset.h. I just added
#ifdef ES
#undef ES
#endif
and the compile continued. I don't know if that #undef could have broken anything.
4
The file aws-sdk-cpp/aws-cpp-sdk-waf/include/aws/waf/model/GeoMatchConstraintValue.h has ES, GS, and SS enumeration value that conflict with the ES, GS, and SS register #define's in /usr/include/sys/regset.h.
Again, I just added a few more #undef's:
#ifdef ES
#undef ES
#endif
#ifdef GS
#undef GS
#endif
#ifdef SS
#undef SS
#endif
I'm really wondering why sys/regset.h is being #include'd in just about everything in the AWS SDK.
5
Same problem in aws-sdk-cpp/aws-cpp-sdk-waf-regional/include/aws/waf-regional/model/GeoMatchConstraintValue.h. Same fix, add:
#ifdef ES
#undef ES
#endif
#ifdef GS
#undef GS
#endif
#ifdef SS
#undef SS
#endif
Note that compiling on SPARC hardware means the #define value from sys/regset.h will be completely different, and any errors will be completely different.
6
The file aws-sdk-cpp/aws-cpp-sdk-core-tests/utils/FileSystemUtilsTest.cpp incorrectly assumes the POSIX NAME_MAX value is defined. Per the POSIX Pathname Variable Values standard (bolding mine):
Pathname Variable Values
The values in the following list may be constants within an
implementation or may vary from one pathname to another. For example,
file systems or directories may have different characteristics.
A definition of one of the symbolic constants in the following list
shall be omitted from the <limits.h> header on specific
implementations where the corresponding value is equal to or greater
than the stated minimum, but where the value can vary depending on the
file to which it is applied. The actual value supported for a specific
pathname shall be provided by the pathconf() function.
Again: the "definition ... shall be omitted ... where the value can vary".
The AWS code wrongly assumes NAME_MAX must be #define'd.
I just hardcoded a value of 255 to get past this point, although using something like _POSIX_NAME_MAX or _XOPEN_NAME_MAX is probably better.
7
File aws-sdk-cpp/ws-cpp-sdk-core-tests/http/HttpClientTest.cpp seems to be incorrectly assuming a std::shared_ptr will be 8 bytes. This question and answer provides a good example of how that's wrong.
I just ignored this error as it's just a test and continued with gmake -i, which completed successfully outside of this one error.
I have a library that interfaces against ImageMagick 6. During compilation I get the below compilation warnings (promoted to errors by me).
I am aware that explicitly defining these values during compilation using -DMAGICKCORE_QUANTUM_DEPTH=16 -DMAGICKCORE_HDRI_ENABLE=0 will solve the issue (on my specific installation), however, as I am writing my CMake configuration files to be as portable as I can make them, this feels way to brittle and I really hope there is a better way.
Which brings me back to my question: Is there a way to determine MAGICKCORE_HDRI_ENABLE and MAGICKCORE_QUANTUM_DEPTH using cmake, bash or similar for the specific version of the library I am linking against?
/usr/include/ImageMagick-6/magick/magick-config.h:29:3: error: #warning "you should set MAGICKCORE_QUANTUM_DEPTH to sensible default set it to configure time default" [-Werror=cpp]
# warning "you should set MAGICKCORE_QUANTUM_DEPTH to sensible default set it to configure time default"
^
/usr/include/ImageMagick-6/magick/magick-config.h:30:3: error: #warning "this is an obsolete behavior please fix your makefile" [-Werror=cpp]
# warning "this is an obsolete behavior please fix your makefile"
^
/usr/include/ImageMagick-6/magick/magick-config.h:52:3: error: #warning "you should set MAGICKCORE_HDRI_ENABLE to sensible default set it to configure time default" [-Werror=cpp]
# warning "you should set MAGICKCORE_HDRI_ENABLE to sensible default set it to configure time default"
^
/usr/include/ImageMagick-6/magick/magick-config.h:53:3: error: #warning "this is an obsolete behavior please fix yours makefile" [-Werror=cpp]
# warning "this is an obsolete behavior please fix yours makefile"
^
cc1plus: all warnings being treated as errors
While writing the question I came across an answer to this. I'll summarize it here as the other questions regarding this angle it slightly differently.
Imagemagick ships with an utility called Magick++-config on my installation (Ubuntu 16.04) I found this utility under /usr/lib/x86_64-linux-gnu/ImageMagick-6.8.9/bin-Q16/Magick++-config. Below is the cmake code snipped I ended up using to extract the relevant build options.
find_package(ImageMagick 6.7 COMPONENTS Magick++ MagickCore)
if(ImageMagick_FOUND)
# Find Imagemagick Library directory
get_filename_component(MAGICK_LIB_DIR ${ImageMagick_MagickCore_LIBRARY} DIRECTORY)
# Find where Magick++-config lives
file(GLOB_RECURSE MAGICK_CONFIG FOLLOW_SYMLINKS ${MAGICK_LIB_DIR}/Magick++-config)
# Ask about CXX and lib flags/locations
set(MAGICK_CONFIG ${MAGICK_CONFIG} CACHE string "Path to Magick++-config utility")
execute_process(COMMAND "${MAGICK_CONFIG}" "--cxxflags" OUTPUT_VARIABLE MAGICK_CXX_FLAGS)
execute_process(COMMAND "${MAGICK_CONFIG}" "--libs" OUTPUT_VARIABLE MAGICK_LD_FLAGS)
# Add these to cache
set(MAGICK_CXX_FLAGS "${MAGICK_CXX_FLAGS}" CACHE string "ImageMagick configuration specific compilation flags." )
set(MAGICK_LD_FLAGS "${MAGICK_LD_FLAGS}" CACHE string "ImageMagick configuration specific linking flags.")
# Split into list:
string(REGEX MATCHALL "([^\ ]+)" MAGICK_CXX_FLAGS "${MAGICK_CXX_FLAGS}")
string(REGEX MATCHALL "([^\ ]+)" MAGICK_LD_FLAGS "${MAGICK_LD_FLAGS}")
# Remove trailing whitespace (CMAKE warns about this)
string(STRIP "${MAGICK_CXX_FLAGS}" MAGICK_CXX_FLAGS)
string(STRIP "${MAGICK_LD_FLAGS}" MAGICK_LD_FLAGS)
target_compile_options(<project> ${MAGICK_CXX_FLAGS})
target_link_libraries(<project> ${MAGICK_LD_FLAGS})
endif(ImageMagick_FOUND)
Source
This is for a shared config file that should include another file if it exists, but still work otherwise. If I do
Include foo.conf
and foo.conf doesn't exist, apache will complain:
could not open document config file /etc/httpd/conf/foo.conf
I came up with a clever solution, though there may be a better way. Put one of the characters in brackets so Apache will treat it as a glob pattern, which is allowed to match zero files without causing an error. E.g.:
Include foo.con[f]
According to http://httpd.apache.org/docs/2.4/mod/core.html#include you could use "IncludeOptional":
Alternatively, the following command will just be ignored in case of missing files or directories:
IncludeOptional conf/vhosts/*/*.conf
IncludeOptional foo.conf
Apache httpd version 2.3.6 and later
https://httpd.apache.org/docs/2.4/mod/core.html#includeoptional
I tried the same as Wouter Van Vliet, but I still got errors. Then I found this link. I added this snippet to my /etc/apache2/apache2.conf and it works like a charm!
Note: You need mod_perl for it!
Here is the code:
<perl>
use File::stat;
foreach $file (glob '/srv/www/vhosts/*/conf/vhost.conf') {
my $stat = stat($file);
if ($stat->uid != 0 || $stat->gid != 0) {
warn "$file is not owned by root:root, skipping!\n";
next;
}
if ($stat->mode & 0002) {
warn "$file is world-writable, skipping!\n";
next;
}
push #Include, $file;
}
</perl>