First of all, I’m not an expert in build libraries from the source with cmake and all this stuff. But unfortunately I have to. I followed up the steps mention in the INSTALL document of the libssh and read a few archived mails but nothing helps me out. It sounds so easy on the web, but I didn’t bring it to work. Here is what I’ve done so far:
Download source from (Version 0.7.5) from libssh git
As mentioned in INSTALL file, download and install cmake (Version 3.9.1)
As mentioned in INSTALL file, download and install OpenSSL (Version 1.0.2)
Ignore zlib, because its optional
Everything is installed in the default paths. Now starts cmake-gui.exe and set source code to …/src folder and binaries to …/build folder, press ‘Configure’ button, with Visual Studio 12 2013 Win64.
Now the first error is generated: install Library TARGETS given no DESTINATION. Okay, checks make file which use variable LIB_INSTALL_DIR to set the path, in my case the path is empty. Add item to cmake-gui named LIB_INSTALL_DIR with path to ../build dir.
Fine, configuration works, generate works, open project works. Try to build ‘ALL_BUILD’ ends up in error: C1083: Cannot open include file: 'config.h': No such file or directory. Searched my whole disk for the file, nothing found. I believe cmake have to generate this file, guessing right? Or is this file missing? Hope someone can help me out! Or maybe have a link to an already compiled lib? Doesn’t understand why libssh doesn’t offers a download, x64 is quite normal today.
Initial inspiration is often the right one, the missing config.h is normally generated by cmake.
If you using cmake-gui.exe, it expects an path to the source, heading is ‘Where is the source code:’. I thought this means the path to the source code files, which are located under …/src, but this is wrong. I need to the set the path to the root folder, in my case … and everything works like a charm.
Also need to change back to OpenSSL version 1.0.2, because somewhere around 30 function declarations has changed.
Related
I am trying to build a project via cmake in qtcreator, but am having trouble with the external package dependencies.
There have been several packages that it could not find, but I added symlinks to the actual file locations into the directory cmake was looking in, afetr which they worked fine.
However, this one library libopencv_viz.so.3.2.0 isn't cooperationg with me. I added the symlink and visually verified that the file/link is in the correct location, but cmake is still telling me that it cannot find the file, and I have no clue how to solve this. As I stated in a prior post, I am still just learning cmake right now, so I have absolutely no clue why it would not be able to find a package that is verifiably in the correct location.
CMake Error at /usr/share/OpenCV/OpenCVModules.cmake:192 (message):
The imported target "opencv_viz" references the file
"/usr/lib/x86_64-linux-gnu/libopencv_viz.so.3.2.0"
but this file does not exist. Possible reasons include:
The file was deleted, renamed, or moved to another location.
An install or uninstall procedure did not complete successfully.
The installation package was faulty and contained
"/usr/share/OpenCV/OpenCVModules.cmake"
but not all the files it references.
Creating symlinks by hand suggests you have an incomplete installation. Clean up your manual symlinks, and figure out what's wrong with your installation.
It is normal on Linux that the .so.x.y.z with the full numeric version is the runtime library. That is, the file that is required for applications to run. The version number ensures that the application loads the same library that it was built against.
The .so symlink to .so.x.y.z is for the build chain. When the compiler (linker, really) goes to link against libopencv_viz, it will search for libopencv_viz.so, resolve the symlink to versioned file, and link that.
Many distributions (including Ubuntu) separate the runtime libraries from the development components. My guess is that you've installed the package named libopencv-viz3.2, but not the one named libopencv-viz-dev.
I tried to compile (build) GLEW source code with CMake and Visual Studio 2019 for get binaries. In directory (disk) C:\ I created folder GL and inside it, placed unzipped glew-2.1.0. In C:\GL\, I created the folder build. Because I found the file "CMakeLists.txt" in 3 folders,
C:\GL\glew-2.1.0\build\conan\test_package
C:\GL\glew-2.1.0\build\cmake
C:\GL\glew-2.1.0\build\cmake\testbuild
I tested all 3 paths in "Browse Source..." text box in CMake. In "Browse Build..." text box I pasted C:/GL/build.
In all 3 tests CMake responded:
"CMake Error: The source
"C:/GL/glew-2.1.0/build/cmake/CMakeLists.txt"
does not match the source
"C:/GL/glew-2.1.0/build/cmake/testbuild/CMakeLists.txt"
used to generate cache. Re-run cmake with a different source directory."
that is "file CMakeLists.txt in 2nd path does not match file of same name in 3rd path".
If you change the top-level source directory on which CMake runs, you should first delete your CMake cache (File > Delete Cache in CMake GUI), and run CMake from scratch to avoid these errors.
Have you tried the CMake instructions on the GLEW Github here? Try running these commands from the command line:
> cd C:/GL/glew-2.1.0/build
> cmake ./cmake
Though this deviates from the typical out-of-source build CMake idiom, this is how GLEW intends the build system be created. So on your system:
Source directory: C:/GL/glew-2.1.0/build/cmake
Build directory: C:/GL/glew-2.1.0/build
Note, the GLEW build instructions warn about the use of CMake for building this repo:
The cmake build is mostly contributer maintained. Due to the multitude of use cases this is maintained on a best effort basis. Pull requests are welcome.
Thus, you may have better luck following the typical Windows build approaches recommended here.
According to Mr. squareskittles answer-comment to my comment to his answer, that I have tested successfully, correct answer is that the folder to accommodate binaries should be C:/GL/glew-2.1.0/build or any folder you have created in glew-2.1.0. It is peculiarity of glew though. With GLFW you can create accommodating binaries folder outside it. However according to Mr.squareskittles's edit in his answer which I have tested successfully, if you delete Cashe (in CMake GUI, click File > Delete Cashe) you can create accommodating binaries folder outside glew-2.1.0. Regards.
I am trying to use MariaDB in my visual studio project, so after looking at the documentation, I installed MariaDB and downloaded the source code for the C/C++ connector.
I got the include folder linked to the project, so I am able to make calls to the functions there, but it won't build because the linker fails to find the function definitions (obviously). I have looked all over and cannot find any solid directions on building the .lib files I need. I have found two sources that say that I need to just build the mariadb_connector_c.sln, but that file does not exist in the source code that I got, nor does it exist on their Git repo: https://github.com/MariaDB/mariadb-connector-c
The closest thing that I have found is the appveyor.yml file they provided, which contains the following: Contents of YML File
Is there anybody out there who has done this before? I can't find anything online or in the files they provided pertaining to this.
UPDATE:
I found the answer thanks to some of the replies. I needed to run the source code through cmake in order to get the .sln that I could then build to get the .lib files I need to link to the project.
The answer is a generic answer for any cmake project
Install CMake. make sure cmake.exe is in PATH (Windows installer offers this option). Install Visual Studio, and make sure C/C++ compiler is installed
start command line prompt
Execute "cmake . && cmake --build ." in the command line prompt.
That#s it.
Using OSX and vim...
Downloaded SDL2 from the website, then moved the SDL2.framework into /Library/Frameworks/
Using tutorial code, and Makefile... SDL.h is not found.
Makefile: g++sdl-config --cflags --libssdltest.cpp -o sdltest
I've read numerous things about pointing the compiler to the framework, but everything I've tried doesn't seem to work, and I thought /Library/Frameworks/ was the default area for the compiler to look
Got it to work.
Getting this to work took multiple tries, but the root of the issue for each try was that most of the Tutorials I was looking at were for SDL1.2 when I was using SDL2.
This changed flags in the make file, directories to search in and other things. Interestingly, I could never get the compiler to see SDL.h when it was in the /Library/Frameworks/ directory. However using Macports to install SDL2 allowed me to point the compiler to where Macports installed SDL2 header files - /opt/local/include/SDL2
That seems to have done it for me
Thank you for your question, because I was having similar difficulties! There seems to be a dearth of detailed and helpful tutorials on how to install SDL2 using Macports.
I got it working! Here are the steps:
Visit this link to find the Macports package appropriate for your version of Mac OS X. Install the version you need, and once that is done, proceed to step 2.
https://www.macports.org/install.php
After installation is done, visit this link to find the SDL2 port.
https://www.macports.org/ports.php?by=name&substr=libsdl
The one I needed was the third from the top, called libsdl2. I will be providing the name for you so feel free to visit the link simply for your own edification.
Open the Terminal, and type sudo port install libsdl2. If all goes to plan, you should see it installing and updating. Once it is complete, you should have a functional installation of the SDL2 Header files, (ending in .h), Static Library files (ending in .a) and Dynamic Library files (which contain dylib). You may have to do some poking around in Finder to locate where it installed.
The advantage of this workaround is the ability to use SDL with other IDE's besides Xcode, Eclipse for instance. Whereas Xcode requires you to assign a path of /Library/Frameworks, this technique should allow you to use the IDE of your choosing.
The final step is going into your IDE and assigning the build paths to these newly installed and compiled SDL files. For instance, the paths for mine are /opt/local/include and /opt/local/lib. Be mindful of the fact that your path may differ from these, but these examples should give you an idea of where to look.
Hopefully this is helpful for somebody!
I have a problem using libclang:
I built libclang locally. It resides somewhere like clang-llvm/…/libclang.3.4.dylib.
Then I developed a foundation tool using that dylib. (exactly: I copied a version to my project folder and linked against this.) The foundation tool works fine. But, of course, at load time it uses the dylib in my local build folder. This is unacceptable, because the user of the tool has to install clang to use my tool.
So I copied libclang.3.4.dylib to a location inside /usr/…/libclang.3.4.dylib and changed the installation path to that location using install_name_path -id /usr/…/libclang.3.4.dylib /usr/…/libclang.3.4.dylib.
After that my tool finds the dylib there but does not work since the parser cannot find stdarg.h any more in the file, that is parsed by my tool.
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:12:10: fatal error: 'stdarg.h' file not found
How can I set the installation path of libclang.3.4.dylib to something public?
Amin, my good friend.
<sarcasm>
From what you wrote it should be OBVIOUS to EVERYONE that you have to create a release build of your tool and NOT a debug build. Xcode should have told you that in the form of CLEAR and EASY to understand error messages.
</sarcasm>
Solution: Use a release build of your tool instead of a debug build.
:)