As i see from this question, libgit2 is now supporting use of ssh repository urls.
But how to force it to work? as i understood from CMakeLists file, SSH support will be enabled automatically if libssh2 library will be detected.
IF(NOT LIBSSH2_LIBRARY)
FIND_PACKAGE(LIBSSH2 QUIET)
ENDIF()
IF (LIBSSH2_FOUND)
MESSAGE("libssh2 was detected!")
ADD_DEFINITIONS(-DGIT_SSH)
INCLUDE_DIRECTORIES(${LIBSSH2_INCLUDE_DIR})
SET(SSH_LIBRARIES ${LIBSSH2_LIBRARIES})
ENDIF()
As it has to be, i saw the "libssh2 was detected" message.
However, the macro GIT_SSH after cmake work is still undefined, and all of SSH stuff is unavailable.
For example, code git_cred_ssh_keyfile_passphrase kf_pass; does not compile.
I get such error:
'git_cred_ssh_keyfile_passphrase' was not declared in this scope,
i.e. GIT_SSH is undefined because this structure is declared in #ifdef GIT_SSH ... #endif block.
Maybe i'm do something in a wrong way?
Related
Looking around on the net I have seen a lot of code like this:
include(FindPkgConfig)
pkg_search_module(SDL2 REQUIRED sdl2)
target_include_directories(app SYSTEM PUBLIC ${SDL2_INCLUDE_DIRS})
target_link_libraries(app ${SDL2_LIBRARIES})
However that seems to be the wrong way about doing it, as it only uses the include directories and libraries, but ignored defines, library paths and other flags that might be returned by pkg-config.
What would be the correct way to do this and ensure that all compile and link flags returned by pkg-config are used by the compiled app? And is there a single command to accomplish this, i.e. something like target_use(app SDL2)?
ref:
include()
FindPkgConfig
First of, the call:
include(FindPkgConfig)
should be replaced with:
find_package(PkgConfig)
The find_package() call is more flexible and allows options such as REQUIRED, that do things automatically that one would have to do manually with include().
Secondly, manually calling pkg-config should be avoid when possible. CMake comes with a rich set of package definitions, found in Linux under /usr/share/cmake-3.0/Modules/Find*cmake. These provide more options and choice for the user than a raw call to pkg_search_module().
As for the mentioned hypothetical target_use() command, CMake already has that built-in in a way with PUBLIC|PRIVATE|INTERFACE. A call like target_include_directories(mytarget PUBLIC ...) will cause the include directories to be automatically used in every target that uses mytarget, e.g. target_link_libraries(myapp mytarget). However this mechanism seems to be only for libraries created within the CMakeLists.txt file and does not work for libraries acquired with pkg_search_module(). The call add_library(bar SHARED IMPORTED) might be used for that, but I haven't yet looked into that.
As for the main question, this here works in most cases:
find_package(PkgConfig REQUIRED)
pkg_check_modules(SDL2 REQUIRED sdl2)
...
target_link_libraries(testapp ${SDL2_LIBRARIES})
target_include_directories(testapp PUBLIC ${SDL2_INCLUDE_DIRS})
target_compile_options(testapp PUBLIC ${SDL2_CFLAGS_OTHER})
The SDL2_CFLAGS_OTHER contains defines and other flags necessary for a successful compile. The flags SDL2_LIBRARY_DIRS and SDL2_LDFLAGS_OTHER are however still ignored, no idea how often that would become a problem.
More documentation here http://www.cmake.org/cmake/help/latest/module/FindPkgConfig.html
If you're using cmake and pkg-config in a pretty normal way, this solution works.
If, however, you have a library that exists in some development directory (such as /home/me/hack/lib), then using other methods seen here fail to configure the linker paths. Libraries that are not found under the typical install locations would result in linker errors, like /usr/bin/ld: cannot find -lmy-hacking-library-1.0. This solution fixes the linker error for that case.
Another issue could be that the pkg-config files are not installed in the normal place, and the pkg-config paths for the project need to be added using the PKG_CONFIG_PATH environment variable while cmake is running (see other Stack Overflow questions regarding this). This solution also works well when you use the correct pkg-config path.
Using IMPORTED_TARGET is key to solving the issues above. This solution is an improvement on this earlier answer and boils down to this final version of a working CMakeLists.txt:
cmake_minimum_required(VERSION 3.14)
project(ya-project C)
# the `pkg_check_modules` function is created with this call
find_package(PkgConfig REQUIRED)
# these calls create special `PkgConfig::<MODULE>` variables
pkg_check_modules(MY_PKG REQUIRED IMPORTED_TARGET any-package)
pkg_check_modules(YOUR_PKG REQUIRED IMPORTED_TARGET ya-package)
add_executable(program-name file.c ya.c)
target_link_libraries(program-name PUBLIC
PkgConfig::MY_PKG
PkgConfig::YOUR_PKG)
Note that target_link_libraries does more than change the linker commands. It also propagates other PUBLIC properties of specified targets like compiler flags, compiler defines, include paths, etc., so, use the PUBLIC keyword with caution.
It's rare that one would only need to link with SDL2. The currently popular answer uses pkg_search_module() which checks for given modules and uses the first working one.
It is more likely that you want to link with SDL2 and SDL2_Mixer and SDL2_TTF, etc... pkg_check_modules() checks for all the given modules.
# sdl2 linking variables
find_package(PkgConfig REQUIRED)
pkg_check_modules(SDL2 REQUIRED sdl2 SDL2_ttf SDL2_mixer SDL2_image)
# your app
file(GLOB SRC "my_app/*.c")
add_executable(my_app ${SRC})
target_link_libraries(my_app ${SDL2_LIBRARIES})
target_include_directories(my_app PUBLIC ${SDL2_INCLUDE_DIRS})
target_compile_options(my_app PUBLIC ${SDL2_CFLAGS_OTHER})
Disclaimer: I would have simply commented on Grumbel's self answer if I had enough street creds with stackoverflow.
Most of the available answers fail to configure the headers for the pkg-config library. After meditating on the Documentation for FindPkgConfig I came up with a solution that provides those also:
include(FindPkgConfig)
if(NOT PKG_CONFIG_FOUND)
message(FATAL_ERROR "pkg-config not found!" )
endif()
pkg_check_modules(<some-lib> REQUIRED IMPORTED_TARGET <some-lib>)
target_link_libraries(<my-target> PkgConfig::<some-lib>)
(Substitute your target in place of <my-target> and whatever library in place of <some-lib>, accordingly.)
The IMPORTED_TARGET option seems to be key and makes everything then available under the PkgConfig:: namespace. This was all that was required and also all that should be required.
There is no such command as target_use. But I know several projects that have written such a command for their internal use. But every project want to pass additional flags or defines, thus it does not make sense to have it in general CMake. Another reason not to have it are C++ templated libraries like Eigen, there is no library but you only have a bunch of include files.
The described way is often correct. It might differ for some libraries, then you'll have to add _LDFLAGS or _CFLAGS. One more reason for not having target_use. If it does not work for you, ask a new question specific about SDL2 or whatever library you want use.
If you are looking to add definitions from the library as well, the add_definitions instruction is there for that. Documentation can be found here, along with more ways to add compiler flags.
The following code snippet uses this instruction to add GTKGL to the project:
pkg_check_modules(GTKGL REQUIRED gtkglext-1.0)
include_directories(${GTKGL_INCLUDE_DIRS})
link_directories(${GTKGL_LIBRARY_DIRS})
add_definitions(${GTKGL_CFLAGS_OTHER})
set(LIBS ${LIBS} ${GTKGL_LIBRARIES})
target_link_libraries([insert name of program] ${LIBS})
I want to compile the sqlite amalgamation to create a database which is protected by a password via user authentication.
I followed this tutorial: https://www.sqlite.org/howtocompile.html
And also the documentation by SQLite for the user_authentication: https://www.sqlite.org/src/doc/trunk/ext/userauth/user-auth.txt
When I try to compile it without the extra compile-time option "-DSQLITE_USER_AUTHENTICATION" and without adding the other documents it works. When I try to compile it with I get the error C2129 at sqlite.c and error C1083 at userauth.c
In this directory are the following files:
shell.c
sqlite3.c
sqlite3.h
sqlite3ext.h
sqlite3userauth.h
userauth.c
cl -DSQLITE_USER_AUTHENTICATION shell.c sqlite3.c userauth.c -Fesqlite3.exe
Following output:
shell.c
sqlite3.c
sqlite3.c(222878): error C2129: static function 'void sqlite3CryptFunc(sqlite3_context *,int,sqlite3_value **)' declared but not defined
sqlite3.c(16263): note: see declaration of 'sqlite3CryptFunc'
userauth.c
userauth.c(26): fatal error C1083: Cannot open include file: 'sqliteInt.h': No such file or directory
Generating Code...
In case there is something like C#'s db.SetPassword("MyPW") available in c, that would be perfect!
I followed [...] the documentation by SQLite for the user_authentication: https://www.sqlite.org/src/doc/trunk/ext/userauth/user-auth.txt
Well no, it doesn't look like you did. Those docs say
Activate the user authentication logic by including the
ext/userauth/userauth.c source code file in the build and adding the
-DSQLITE_USER_AUTHENTICATION compile-time option. The ext/userauth/sqlite3userauth.h header file is available to
applications to define the interface.
When using the SQLite amalgamation, it is sufficient to append the
ext/userauth/userauth.c source file onto the end of the amalgamation.
You are using the amalgamation, so you should append [the contents of] userauth.c to the amalgamation. That is, copy its contents to the end of sqlite3.c. From your directory listing and command line, it appears that you are instead attempting to build it as a separate source file, to be linked to the main one at the end. That's not equivalent, and in particular, it differs with respect to the effect on the scope of static functions and variables, which is exactly what your compiler is complaining about.
It's unclear whether -DSQLITE_USER_AUTHENTICATION should also be used with the amalgamation. A literal reading of the SQLite docs suggests not, but I would be inclined to guess that it actually is required either way if you want to enable the feature.
The error about the missing header is a little concerning, and it is possible that you will see it again. If you do, it may be sufficient to simply remove or comment out the corresponding #include directive, as all the needed declarations from that header, which is among the main sources, should already be included in the amalgamation.
I am attempting to build a project that comes with an automake/autoconf build system. This is a well-used project, so I'm skeptical about a problem with the configure scripts, makefiles, or code as I received them. It is likely some kind of environment, path, flag, etc problem - something on my end with simply running the right commands with the right parameters.
The configuration step seems to complete in a satisfactory way. When I run make, I'm shown a set of errors primarily of these types:
error: ‘TRUE’ undeclared here (not in a function)
error: ‘struct work’ has no member named ‘version’
error: expected ‘)’ before ‘PRIu64’
Let's focus on the last one, which I have spent time researching - and I suspect all the errors are related to missing definitions. Apparently the print-friendly extended definitions from the C standard library header file inttypes.h is not being found. However, in the configure step everything is claimed to be in order:
configure:4930: checking for inttypes.h
configure:4930: /usr/bin/x86_64-linux-gnu-gcc -c -g -O2 conftest.c >&5
configure:4930: $? = 0
configure:4930: result: yes
All the INTTYPES flags are set correctly if I look in confdefs.h, config.h, config.log Output Variables, etc:
HAVE_INTTYPES_H='1'
#define HAVE_INTTYPES_H 1
The problem is the same whether doing a native build, or cross-compiling (for arm-linux-gnueabihf, aka armhf).
The source .c file in question does have config.h included as you'd expect, which by my understanding via the m4 macros mechanic should be adding an
#include <inttypes.h>
line. Yes, as you may be inclined to ask, if I enter this line myself into the .c file it appears to work and the PRIu64 errors go away.
I'm left with wondering how to debug this type of problem - essentially, everything I am aware of tells me I've done the configure properly, but I'm left with a bogus make process. Aside from trying every ./configure tweak and trick I can find, I've started looking at the auto-generated Makefile.in itself, but nothing so far. Also looking into how I can get the C pre-processor to tell me which header files it's actually inserting.
EDIT: I've confirmed that the -DHAVE_CONFIG_H mechanic looks good through configure, config.log, Makefile, etc.
autoconf does not automatically produce #include directives. You need to do that on your own based on the HAVE_* macros. So you'll have to add something like this:
#ifdef HAVE_INTTYPES_H
# include <inttypes.h>
#endif
If these lines show up in confdefs.h, a temporary header file used by configure scripts, this does excuse your application from performing these #includes. If configure writes them to confdefs.h, this is solely for the benefit of other configure tests, and not for application use.
First, run make -n for the target that failed. This is probably some .o file; you may need some tweaking to get its path correctly.
Now you have the command used to compile your file. If you don't find the problem by meditating on this command, try to run it, adding the -E to force preprocessor output text instead of invoking the compiler.
Note that now the .o file will be text, and you must rebuild it without -E later.
You may find some preprocessor flags useful to get more details: -dM or -dD, or others.
I am trying to write a Linux kernel module with CLion. This is the cmake file:
cmake_minimum_required(VERSION 3.5)
project(labs)
set(KERNEL_HEADERS
/home/alex/Developer/linux/include
/home/alex/Developer/linux/arch/x86/include
/home/alex/Developer/linux/arch/x86/include/generated
/home/alex/Developer/linux/include/uapi
/home/alex/Developer/linux/include/generated/uapi
/home/alex/Developer/linux/arch/x86/include/uapi
/home/alex/Developer/linux/arch/x86/include/generated/uapi
)
set(MY_MODULE_SOURCES
chapter_03/lab_01/hello.c
)
add_definitions(-imacros /home/alex/Developer/linux/include/linux/kconfig.h)
add_definitions(-D__KERNEL__)
add_definitions(-DMODULE)
add_definitions(-std=gnu89)
include_directories(${KERNEL_HEADERS})
add_custom_target(labs COMMAND $(MAKE) -C ${labs_SOURCE_DIR}
PWD=${labs_SOURCE_DIR})
add_library(dummylib ${MY_MODULE_SOURCES})
The actual building of the kernel module is done with the externally called makefile using "add_custom_target". The "dummylib" is only there so that CLion actually starts to parse the header files and gives me auto completion. With my supplied definitions it does even compile the "dummylib" successfully (look at the screenshot). It is no kernel module though, but that does not matter ;)
My problem is the error you see in the screenshot. Somehow it says that it can't resolve all the macros defined in the kernel headers. Functions, structs and plain defines ( "MODULE_SIG_STRING ") do work (as you see). I do not understand why the editor says it cannot resolve the macro but can still build it. What is more strange is that I can even jump to the declaration using STRG+B of the marked macros. Clearly something is going wrong. The macros are really defined within linux/module.h.
Update
When I set -std=c89 instead of -std=gnu89 the editor recognizes the macros but the "dummylib" of course fails to build since the kernel needs the gnu extensions. I guess this is a bug in CLion. I posted it at the Jetbrains Bugtracker: https://youtrack.jetbrains.com/issue/CPP-6875
I am new to openssl, and I downloaded openssl-fips-2.0.1 codes from openssl, however, I was not able to trace to the definition of FIPS_mode_set() as stated in the documentation and security policy. I did find, however, fips_set_mode() in fips.c, but they are not referring to the same, am I right?
Where is the definition?
Please advise me.
FIPS_mode_set() code not found in openssl package
You have to know how to ask...
openssl-1.0.1f$ grep -R FIPS_mode_set *
apps/openssl.c: if (!FIPS_mode_set(1)) {
CHANGES: *) Functions FIPS_mode_set() and FIPS_mode() which call the underlying
crypto/cpt_err.c:{ERR_FUNC(CRYPTO_F_FIPS_MODE_SET), "FIPS_mode_set"},
crypto/evp/evp_cnf.c: if (!FIPS_mode() && !FIPS_mode_set(1))
crypto/crypto.h:int FIPS_mode_set(int r);
crypto/o_fips.c:int FIPS_mode_set(int r)
Binary file fips_premain_dso matches
ssl/ssltest.c: if(!FIPS_mode_set(1))
util/libeay.num:FIPS_mode_set 3253 EXIST::FUNCTION:
openssl-1.0.1f$
The declaration is in crypto/crypto.h and the definition is in crypto/o_fips.c. Here's from o_fips.c:
int FIPS_mode_set(int r)
{
OPENSSL_init();
#ifdef OPENSSL_FIPS
#ifndef FIPS_AUTH_USER_PASS
#define FIPS_AUTH_USER_PASS "Default FIPS Crypto User Password"
#endif
if (!FIPS_module_mode_set(r, FIPS_AUTH_USER_PASS))
return 0;
if (r)
RAND_set_rand_method(FIPS_rand_get_method());
else
RAND_set_rand_method(NULL);
return 1;
#else
if (r == 0)
return 1;
CRYPTOerr(CRYPTO_F_FIPS_MODE_SET, CRYPTO_R_FIPS_MODE_NOT_SUPPORTED);
return 0;
#endif
}
If you were looking for FIPS_mode_set to enter into "FIPS mode" with special setup or switch some algorithms, that does not happen at this step.
It happens earlier when linking. What happens under the hood is fipsld is you compiler, and it looks for an invocation of LD. If LD is not invoked, then fipsld just calls your regular compiler (probably /usr/bin/gcc). If it sees an invocation of LD, then it does three things.
First, it compiles fips_premin.c. Then it calls the real ld to perform the final link with all your object file and the fips_premain.o it produced. Finally, it calls incore to swap in the FIPS Object Module, calculate the signature over the relevant text and data (relevant means the FIPS code and data), and then embeds the signature in the executable.
The signature is generated with an HMAC, and the key is embedded in the executable. There's nothing special about it, and its constant across all executables throughout the world. Here's the key used: etaonrishdlcupfm.
If you are not taking special steps when build your executable, then you are probably missing some steps. Here are the steps to use fipsld and incore:
$ export CC=`find /usr/local -name fipsld`
$ echo $CC
/usr/local/ssl/fips-2.0/bin/fipsld
$ export FIPSLD_CC=`find /usr/bin -name gcc`
$ echo $FIPSLD_CC
/usr/bin/gcc
Now, do a standard config and make. Sometimes you have to do config, then adjust CC and FIPSLD_CC, and then run make because some config files choke on the arrangement. Sometimes you have to open a Makefile after config and change CC to /usr/local/ssl/fips-2.0/bin/fipsld. There's lots of ways to do it in an effort to work around particular packaging.
I downloaded openssl-fips-2.0.1 codes from openssl, however, I was not able to trace to the definition of FIPS_mode_set()
openssl-fips-NNN provides the FIPS validated cryptography if you build the FIPS Object Module according to the Security Policy. You can find the OpenSSL FIPS 1402- Security Policy at here.
If all you did was download and build openssl-fips-NNN, then you are probably not using FIPS validated cryptography. There's a procedure to follow, and that includes getting a "trusted" copy of the source code. You can download and verify a signature, but you need a FIPS validated signature checker, which creates a chicken-and-the-egg problem because you can't build it from sources. So the practical solution is to order the CD from the OpenSSL Foundation. Its bizarre, but its the truth. See, for example, the OpenSSL FIPS User Guide or the OpenSSL FIPS Security Policy, Appendix B, Controlled Distribution File Fingerprint.
Once you have the FIPS Object Module built and installed, you can build the FIPS Capable version of the library. The FIPS Capable OpenSSL will use the FIPS Object Module, if available. Think of it as a "pluggable" architecture.
The FIPS Capable version of the library is simply openssl-NNN, such as openssl-1.0.1e and openssl-1.0.1f. Its what you know and love.
You might also consider something like ctags as a source code browser to help you find things and jump around. See Exuberant Ctags on Sourceforge.
Please refer header file crypto.h. I am able to find its definition there at line 566 as follows:
int FIPS_mode_set(int r);
Documentation clearly mention that it is in header file <openssl/crypto.h>.
So, in your code, include openssl/crypto.h to include the definition of this function. If you face other problem, you can browse through questions of OpenSSL that may help you.
For linkage FIPS_mode_set() should be available from libcrypto (*.a for static linkage and *.so for run-time linkage).
libcrypto.a/.so comes with your distro's openssl's developer package, or as a result of bulding openssl-x.y.z yourself.
You find the sources for FIPS_mode_set() in the sources for openssl-x.y.z, in the file crypto/o_fips.c.