I am trying to install Poco on Mac. I downloaded the basic edition from here. As per the instructions, I did configure, then did make. It took a long time, but it succeeded (my make version is 3.81).
After this, when I did sudo make install, it finished pretty quickly. But as per the documentation, which states that I should have the libraries installed in /usr/local, I don't see them. The /user/local/include/Poco has all necessary header files, and /user/local/lib has lot of dynamic libraries like libPocoFoundationd.30.dylib, etc, but I don't see the libraries which I need to use.
How do I get them? My system is OS X 10.10, Yosemite.
If you have the entries like libPoco*.30.dylib (dynamic library binary) and libPoco*.dylib (link to the library), that's it. If you are looking for the static libraries, they are not built by default. To build static libraries, do
configure --static
and, after make install, in /usr/local/lib you will find libPoco*.a etc.
Related
I'm trying to build wxWidgets library into a custom path on a Fedora 27 operative system.
I achieved the wx-config file path recognition and works with the cmake execution. Also, I load libraries and include dirs based on modified wxWidgets finder cmake file that sets thewx-config custom path successfully.
But cmake does not load my wxWidgets configuration. I mean, wx_gtk2u_jpeg-3.1 builded lib could not be founded (suposed to be /usr/lib/libwx_gtk2u_jpeg-3.1.so). I need jpeg dependency from wxWidgets for my project.
I'm sure that problem is not about cmake files. However, the problem is wxWidgets compilation because cmake can found the other builded dependencies into /usr/lib/
I actually installed the libjpeg-turbo-devel package that includes the libjpeg.h needed for wxWidgets building without success of libwx_gtk2u_jpeg-3.1.so creation.
The weirdest part is that $ wx-config --libs shows the wx_gtk2u_jpeg-3.1 lib to be linked and the hint paths that it should be founded.
wxWidgets commands for building:
$ ./configure --with-libjpeg=builtin --with-libpng=builtin --with-libtiff=builtin --with-zlib=builtin --with-expat=builtin --enable-webviewwebkit=no --prefix=/opt/cpp_dependencies/2018Q1/usr'
$ make -j 4
$ make install
You can check out my cmake files, the cmake output and wxWidgets building output in order to reproducing it: https://gist.github.com/jjalvarezl/b70accae269ef56c56010bedf157c27f
You can see line 1543 of wxWidgets building output file that jpeg library is buildin, and, 1564 of same file, the make install command that installs all libwx_<lib_name>.so libraries into final /usr/lib path. Anyway, no one contains the needed library.
Please show the exact error message, as it's not clear what the actual problem is. What I can say, is that the different built-in versions of 3rd party libraries, such as libjpeg, are always static libraries, even when wxWidgets themselves are shared. I.e. you're never going to have libwx_gtk2u_jpeg-3.1.so, only .a.
I'd also strongly recommend using system versions of the 3rd party libraries under Unix systems. This means that your wxWidgets applications will get security updates from your OS vendor and you don't risk running into any incompatibilities due to using 2 different versions of the same library in your application.
I'm making a conda package that is C++ code that is dependent on libboost and libopencv, and is then exposed to Python wrappers. I have libboost and libopencv installed on my system in a particular way.
I want to redistribute these libraries along with my package (this is for internal use only). I use plain make.
I'm not sure how to package my code in a way that shared libraries are copied and used from within the package. So that even if I send my package to a computer with no dependencies installed, it will still run. I want to prioritize my shared libraries even if there are other system libraries installed. Think of it as a standalone package.
I'm not sure if I have to use CMake to build my stuff in the right way - does anyone have any example that I can use?
Say, I want to write a program in C++ in Linux and I need some specific libraries. There are 2 ways of getting these libraries:
Using the command line--> apt-get install library
Downloading and extracting a .zip or .tar file from their website.
Now my questions are:
For the first method I have seen libraries being downloaded with apt-get install library and apt-get install library-dev. I know dev means development or developer, but what is the difference between installing the dev and not installing the dev? What does dev do, exactly?
For the second method, do I need to build the libraries using a compiler? Because I have seen tutorials doing it but the OS used was usually Windows, do I only have to build them on Windows and not Linux?
Also, say I can only use the 2nd method for a certain library and not the first one. After extracting, what am I supposed to do? Is there any default way of installing a library manually or is each library different?
Finally, when I use the first method where is the library installed to? Is it /usr/local/lib, /usr/lib or /usr/include? Because when I have to link to these libraries in the Linker's settings I only write their name, not the path so I assume there is already a default path for libraries to be in.
One last question: Is there any default way of installing and using libraries in general or does that depend on what I want to do, programming language, etc...?
The second method is very broad because it depends entirely on the how the project is designed including the build system used etc. Things get a little more conformant when you use a distribution's managed packages.
If you want to develop a program that uses the library you need the library-dev package that usually contains the C/C++/etc.. header files.
Many development package conform to a standard tool that helps your build system find the libraries header and binary files.
For example libcurl uses the pkg-config system so its compiler components can be found from the command line like this:
pkg-config libcurl --libs # print the library link flags
You can then add that to your Makefile (or whatever build system you use):
program:
g++ -o program program.cpp $(shell pkg-config libcurl --libs)
The $(shell pkg-config libcurl --libs) part adds the correct compiler flags to link with the library.
Not all dev packaged use pkg-config. Some come with their own tools (like mysql_config) while others let you guess and try to figure it all out for yourself (looking at you libclang).
In my C++ project, I'm compiling and linking against a library that makes use of OpenSSL.
I need to compile this project for my BeagleBone which has openssl installed by default. I have downloaded libssl-dev on my development machine.
Thus, I can compile the project fine if I'm compiling for my development machine on x86_64, but I am not able to successfully cross compile:
/usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/../../../../arm-linux-gnueabihf/bin/ld: cannot find -lssl
/usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/../../../../arm-linux-gnueabihf/bin/ld: cannot find -lcrypto
This indicates I need to have armhf binaries for OpenSSL, which seems a bit of a waste really since I have them on my BeagleBone if it can just be patient and wait until I deploy it.
Is the only way around this cross-compiling OpenSSL myself? Where would I then need to install the .so files (I guess make install would be a bad idea?)
This indicates I need to have armhf binaries for OpenSSL
Correct.
which seems a bit of a waste really since I have them on my BeagleBone if it can just be patient and wait until I deploy it.
You appear to think that shared libraries are only needed at runtime, but that is not the case.
ELF stands for executable and linking format. The .so is very much needed at static link time to construct various tables in the main executable, which will then be used by the loader at runtime to resolve references from the main executable to the .so.
If you are familiar with Win32, you can think of .so as a combination of Win32 .LIB and .DLL packed into a single file.
I want to build an autotools project which is making use of the boost libraries program_options and iostreams. Therefor I install those libraries:
sudo aptitude install libboost-iostreams-dev libboost-program_options-dev
Now ./configure is fine and the progam compiles. However the linking fails:
/usr/bin/ld: cannot find -lboost_program_options-mt
/usr/bin/ld: cannot find -lboost_iostreams-mt
This is a well documented issue and can be fixed either by fixing the autotools stuff or by linking boost_program_options to boost_program_options-mt and so forth. I choose to do the latter since this is not my project. However I am failing to locate the libraries installed in Ubuntu:
locate *boost*
returns a list of documentation and package information and some boost libraries I am not looking for. locate *program_options* is empty. The library is not under /usr/lib or /lib ... Any ideas?
For me they are under /usr/lib64 in ubuntu 13.04. But I would use boost m4
to let autotool take care of these dependencies automatically. So by including boost m4 in your configure.in, you can specify which boost modules and versions you require. Morever it would also find the required paths for you.
sometimes its impossible, especially for smaller apps and custom projects,
for future, boost includes are in /usr/include/boost ,
of course it depends on system type and distribution