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.
Related
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.
I am trying to learn to make 2d games using c++ with the SFML library. I am using windows, but I would prefer to use the Atom text editor instead of Visual Studio. I did a lot of research on how to do this, but I still do not know how to use the SFML library with Atom. So, how would I go about implementing the SFML library in my c++ project written in Atom. Thank you!
This answer supposes that you've downloaded the 32-bit MinGW version of SFML, and you'd like to compile programs written in Atom from the command line1. Inside of the SFML folder you just downloaded, there are three folders which are important for us right now: bin, lib, and include.
The bin folder contains DLLs. In this answer I'm only going to talk about dynamic linking to SFML, since that's what I have experience with. To run any dynamically linked executable built using SFML, you'll need to copy all of the relevant DLLs into the same folder as the executable. (Which are the relevant ones? The easy solution is to just copy all of them.2)
The lib folder contains libraries (files with the .a extension). If you go to the folder where you installed MinGW (the default is C:\MinGW), and then follow the path \lib\gcc\mingw32\8.2.0, you should be in a folder with a few subfolders, some .o files, and a bunch of .a files. Copy into here all of the files from the SFML lib folder. Now MinGW knows about the SFML libraries.
Lastly, the include folder contains a folder named SFML, which contains all of the SFML header files. Copy the SFML folder. Now remember the folder that we dumped all of the .a files into in the last step? That folder should have a subfolder named include, which contains a folder named C++, which contains all of the standard C++ headers (iostream, algorithm, etc.). Into that C++ folder paste the SFML folder that we picked up just a second ago. (Not the contents of the folder, but rather the folder itself.) Now MinGW knows about the SFML headers, so we can safely type e.g. #include <SFML/Graphics.hpp>
To compile, for example, the file main.cpp at the end of this tutorial and dynamically link it with Atom, you would run the command g++ main.cpp -lsfml-graphics -lsfml-window -lsfml-system inside of cmd.exe.
Disclaimer: Copying the libraries and include folder is not the method recommended by SFML. Instead, they suggest using command line arguments to tell g++ where to look. But IMO (1) their method is more of a pain for first-time users, and (2) first-time users are unlikely to be using multiple compilers or multiple versions of SFML. (If you are using multiple compilers or multiple versions of SFML, you'll want to do it their way. In that case let me know and I can try to help.)
1) It's possible you're actually looking to compile directly in Atom at the click of a button (F5 by default?). If you already know how to compile non-SFML applications directly in Atom, then I think the above should be enough for you to compile SFML applications too, as long as you set your default compiler flags appropriately in Atom. (By which I mean: For the example above your flags should include -lsfml-graphics, -lsfml-window, and -lsfml-system, in that order).
2) To figure out what DLLs you need, you can add them all and start removing them until your application doesn't work. Alternatively, keep these three things in mind:
You always need openal32.dll
You need the DLLs that you linked to when compiling
You need the versions with "-d" (e.g. sfml-graphics-d-2.dll) if you're compiling in debug mode, and you need the versions without it otherwise
So in the case of the example above, you only need openal32.dll, sfml-graphics-2.dll, sfml-window-2.dll, and sfml-system-2.dll.
You need Atom Packages
So, iam currently developing a new package for SFML compile on Atom.
I just need to write the Docs and make it a Atom package, but take a look on the repo: https://github.com/brhaka/sfml-compiler
You can contribute to it, or just star :)
Iam working hard on it to release as soon as possible, so i suggest you to just wait a little bit. There's another package for that, but there's no documentation.
Your name is really cool!
I hope this can help you!
Brhaka
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've downloaded the midiIO library and in the readme it says:
edit the file Makefile.library and set the OSTYPE and OSSUBTYPE to match your hardware/os setup.
type "make library" to compile the library. It will be created as lib/libmidiio.a in unix.
edit the file Makefile.examples and set the OSTYPE and OSSUBTYPE to match your hardware/os setup.
Also, if you are using ALSA, then uncomment out the POSTFLAG to use the alsa library (-lasound).
type "make examples" to compile the example programs in the examples directory. The example programs will be place in the bin directory.
1 + 3 are fine but 2 + 4 are over my head. I've worked in a unix environment before and have used gcc with flags but I need to get this done in Windows. I typically use Visual Studio but don't know how to achieve this with that.. I've downloaded Dev-C++ if that's any use but I don't know what to do with the makefiles?
Ignore the makefiles and set up a fresh project in Visual C++. Make your target a static library (which will be a .lib file in Win32, not a .a file as in unix as you probably know). It is unlikely that the project will build out of the box, so you might have to deal with some compilation errors relating to unix-specific symbols. I took a quick look at the source code, and it looks fairly well-written, so I don't think you should have many problems building it directly in Windows.
Alternately, you could build the source using the real make tool in cygwin, but this means that you would need to distribute the cygwin library with your final product. This may or may not be more trouble than it's worth, especially if you are already using VC++ for the rest of your project's code.
I'm studying (well, trying to) C right now, but I'm limited to working in Windows XP. I've managed to set up and learn how to use Emacs and can compile simple C programs with gcc (from Emacs no less!), but I'm getting to the point where I'd like to install something like SDL to play around with it.
The thing is that the installation instructions for SDL indicate that, on a Win32 environment using MingW, I would need to use MSYS to run ./configure and make/make install to install SDL, like one would do on Linux. I noticed that when I unzipped the SDL-dev package (forgot the exact name, sorry) there were folders there that corresponded to a folder in the MinGW directory (SDL/include -> MinGW/include).
Am I right in saying that all the ./configure and make commands do is move these files from one directory to another? Couldn't I just move those files by hand and spare myself the trouble of installing and configuring MSYS (which, to be honest, confuses me greatly)?
The build process usually works like this: the configure script finds the appropriate settings for the compilation (like which features to enable, the paths to the required libraries, which compiler to use etc.) and creates a Makefile accordingly. make then compiles the source code to binaries. make install copies the created binaries, the headers, and the other files that belong to the library to the appropriate places.
You can't just copy the files from the source archive, because the source archive does not contain the binary files (or any other files that are created during the make step), so all you'd copy would be the headers, which aren't enough to use the library.
In most case, configure and make will discover the compiler/environment of your machine and build the suitable binary, respectively. Therefore, unfortunately, it will not be easy as moving/copying header files to new locations.
However, in some cases, the library can be the "header only" library. Which means you need only header files to use it.
I have no experience with MSYS and SDL. But the basics of configure and make is worth learning (especially if you are going to program any C/C++ in non-Windows environment.)