I'm working with a bit of a legacy cpp code base. This code base is reliant on Poco, more specifically Poco/MySQL.
When loading Poco via Cmake, it attempts to find the MySQL include and libs. I have the source code of MySQL in a folder nearby, and am attempting to link it in the CMake. While I was able to get the include directory linked correctly, it's still not finding mysqlclient(_r) and I have no idea why. I'm currently attempting in on Mac, but I'd like to make it cross platform as well.
FindMySQL.cmake:
find_library(MYSQL_LIB NAMES mysqlclient_r
PATHS
/usr/lib/mysql
/usr/local/lib/mysql
/usr/local/mysql/lib
/usr/local/mysql/lib/mysql
/opt/mysql/mysql/lib
/opt/mysql/mysql/lib/mysql
$ENV{MYSQL_DIR}/libmysql_r/.libs
$ENV{MYSQL_DIR}/lib
$ENV{MYSQL_DIR}/lib/mysql
${CMAKE_CURRENT_SOURCE_DIR}/../../mysql/lib
${CMAKE_CURRENT_SOURCE_DIR}/../../mysql/libmysql)
message("${MYSQL_LIB}") # MYSQL_LIB-NOTFOUND
https://github.com/mysql/mysql-server
That's the MySQL source I'm attempting to build.
After a very long time I found the answer.
Changing it to include_library instead worked fine as it was an include only library.
Related
I'm creating a library for the first time. So far it's working from the IDE (Qt Creator), but not from the terminal when I run its testing program manually.
There are two parts to my project, the library, and the sandbox for testing it. I've created a project in Qt Creator that includes two subprojects (one to build the lib, and one to build the tester) and both compile without errors. When I run the sandbox from the IDE the library is dynamically linked to the sandbox, the function greeting() is loaded in from it, then called, and prints "Welcome to the library!" to std::cout. However, if I open the build folder in the terminal and run the sandbox directly using ./sandbox I get:
./sandbox: error while loading shared libraries: libengine.so.1: cannot open shared object file: No such file or directory
I took this to mean that I needed to properly install my custom library, libengine.so.1. When I looked up how to do that I found that I just needed to copy the library files in to either, /usr/lib or /usr/local/lib, but neither of those worked and I'm still getting the above error. In the past, that simple solution did work for me when compiling a 3rd party library (SDL, I think) and I don't know what I'm missing that would mean it wouldn't work now. So far I haven't yet found any more detailed information and I don't know what I'm doing wrong or have missed.
How do I make my sandbox program see its companion library when I run it directly from the command line?
NOTE: I'm specifically asking about Linux/Ubuntu. If I later run into problems under Windows I'll be back. :-)
Short Answer
I ran in to multiple problems all at once.
First problem: Broken symbolic links (they're like shortcuts in Windows).
Second: My lib needed to be copied in to a different system directory than is generally recommended.
Third: Qt Creator and QMake made passing custom linker options difficult.
The Details
When Qt Creator compiles my library it automatically creates three symbolic links to it with different layouts of the version numbers.
> ll
lib-engine.so -> lib-engine.so.0.1.0
lib-engine.so.0 -> lib-engine.so.0.1.0
lib-engine.so.0.1 -> lib-engine.so.0.1.0
lib-engine.so.0.1.0 (original library file)
For some reason (I don't know why) each time I moved the links in to a system directory like usr/local/lib the links would break. I didn't notice this at first, or even think to check, because that's never happened to me before. Moving a link has always worked in the past. To get around this I just manually created the links within the directories they would reside in.
Broken links aside, putting the library in to usr/local/lib still didn't work, but usr/lib and /usr/lib/x86_64-linux-gnu (recommended in the blog linked below) did work!
Those fixes actually came after a different fix I looked in to after reading this blog and this article it linked to.
There it said to add -Wl,-rpath,'$ORIGIN/lib' to the gcc build options to embed a library search path in to the application itself. This set of options would allow me to put my library files where ever I wanted (specifically, in a directory called /lib in the application's working directory).
Unfortunately, that had two problems of its own. First, Qt Creator doesn't (from what I can tell) allow you to specify custom build options for individual subprojects through the GUI, so I had to figure out how to add linker options using the project file, assuming that was possible, which it was.
Second, QMake messed up the gcc options, embedding in to my application Library rpath: [RIGIN/lib] instead of Library rpath: [lib] like it's supposed to.
In the end, changing the proposed linker options of...
-Wl,-rpath,'$ORIGIN/lib'
... to the following QMake project file line...
QMAKE_LFLAGS += -Wl,-rpath,'lib'
... work out nicely. Using both fixes I can now either install my library on my system or put it in to a /lib folder and the program will run.
I'm just trying to follow along with the c++ graphics tutorial from MakingGamesWithBen about SDL mixer, an audio system. I got the development library from:
SDL_Mixer Development Library Download.
It's the SDL2_mixer-devel-2.0.2-VC.zip folder under development libraries for Visual C++. I've done all the same steps as what he is showing, though I've been using x64 instead of x86. When I try running the project though, it gives me the error
"SDL_AudioStreamFlush could not be located in the dynamic link library [file path] SDL2_mixer.dll". I'm not using the function SDL_AudioStreamFlush in my code at all, which is what perplexes me about this. I honestly don't have any clue how to fix this, and online documentation doesn't seem to help. Any assistance would be much appreciated, because I have tried looking on sites for other similar questions, but nothing I can use. Below should be a dropbox link to my entire solution.
https://www.dropbox.com/sh/0blrourluyjpsca/AACs4bHdZs83q_R8lSjFINIEa?dl=0
I have the same problem when using SDL_mixer and SDL_ttf.
When I change the old SDL2.dll in my folder (I put them all: header files, library files, and binary files in one directory) with the newest one (the one that is in the lib/X86/SDL2.dll) it works.
I'm trying to write a program in C++ to write static arrays and matrices to .mat files so that I can load them into Matlab, and I'd also like to be able to read them. I've done a lot of reading and I'm aware that there's some framework I need to properly set up in XCode in order for things to work. I'm using Matlab R2015b and Xcode 7.3.
I'm modeling my code initially to be simple like what the author mentions in Reading data from matlab files into C but I can't locate my libraries. The folder /glnxa64/ does not exist on my machine. I know that my headers I want to include are in applications/MatlabR2015/extern/include for mat.h, matrix.h.
I have two problems: Under my project settings in XCode, what do I modify to make sure my project finds mat.h and matrix.h, is it under the "Precompiled Headers Cache Path" or elsewhere? Also, where do I find those library files and how do I link them in XCode, is it just under the Project Build Phase link binary with libraries?
Thanks for the help!
I found the solution to the second part of my question. The first part was just me messing with the project build settings instead of the target build settings.
The folder for the libraries that Matlab has depends on what operating system and version of Matlab you're on. Opening matlabR2015b.app by making the finder show package contents, then navigating to applications/MatlabR2015b.app/bin/maci64/ is where the library binaries are located on my machine. The name maci64 changes depending on the OS (since I'm on a mac 64-bit OS, I believe that's where my path name came from) and manually paging through the list of libraries found it, since using the file search doesn't really work inside a package.
My code still won't compile because it looks like I need to include all of the right codependent libraries, and I don't know which other ones I need (I only included libmex.dylib and libmat.dylib), but I found where the libraries are stored.
I am new to the XCode environment so apologies if this sounds trivial.
I am trying to use a third party library using for OpenCV that helps me do some blob analysis, CCL etc. Hosted here
I have searched a lot but there doesn't seem to be much documentation on how to go about adding and using these new libraries. I am using XCode 4.5.2, OpenCV 2.4.2.
When I simply add all the header files to the project folder and #include them in the source code, it fails to compile. I have also tried adding the "Header Paths" but it doesn't help. What am I missing?
I have tried to follow the instructions (compiling it using the terminal but it doesn't compile too) I am not clear on how or when exactly to use CMAKE.
Any help will be appreciated. Thank you.
I would suggest you using CvBlob on google code which is different from the one on willowgarage, I have got recently confused with this so take a look at this question for alternative blob analysis libraries.
Moreover, CvBlob has also a good support community here. (Search on "[cvblobslib]" or on "[blob] [opencv]")
Try this: cvBlob: OSX installation
Once you get it compiled, you need to include the library under Link Binary with Libraries in Build Phases. (This screenshot shows the core, imgproc, and highgui libraries. Your cvBlob library would go in the same place.)
I'm using MinGW 4.5.1 for compiling a client application (C++, Windows XP) utilizing the newest version of Boost 1_47. For some reason that I can't seem to determine, when I go to compile using the boost::asio::signal_set type I get a compile error (boost::asio::signal_set does not define a type), and when trying to explicitly include either of the associated signal_set headers, I get complaints of no file can be found (despite the file indeed being where expected). I have tried including files within the same level of the directory tree without issue, it only seems to hang on the signal_set.hpp file (although no complaints when using the full header asio.hpp which has it as an include). I get the same behavior when trying to use boost 1_46_1 as well.
Might anyone have any insights as to what is going on?
The issue I had was that I was not properly including the boost headers as I thought I was. Usually I have the boost installation in some directory on the hard drive, say C:\Boost\some_boost_version. Whereas I thought I was pointing to the new boost version's includes at C:\Boost\boost-1_47\boost, there was not a level inside the directory tree for \boost, everything was in C:\Boost\boost-1_47. By adding a new directory (created C:\Boost\boost-1_47\boost) and putting the includes within that, my problem was resolved. Something I overlooked when I retooled my build scripts for build the boost libraries on my machine.