I would like to run on Colab a C++ library which requires a version of libstdc++.so which is newer than the one provided by the default g++ 7.x installed on Colab. Such requirement is due to C++17 features not supported by g++ 7.x.
In order to do so, I install a recent g++ compiler (and corresponding libstdc++.so) from a PPA. However, when I try to import libraries compiled with the updated g++ compiler it seems that the python runtime is not aware of the update to libstdc++.so, unless one restarts the runtime via "Runtime -> Restart runtime".
Since restarting the runtime is an ugly workaround, and might be disruptive for my end users, is there a better way to make the current runtime aware that libstdc++.so has changed?
I have prepared a standalone notebook which shows my problem on a simple case (using pybind11).
Thanks
To install and use recent libstdc++ do:
sudo add-apt-repository ppa:ubuntu-toolchain-r/test
sudo apt install libstdc++-9-dev.
Installed include files are inside /usr/include/c++/9/ and /usr/include/x86_64-linux-gnu/c++/9/.
Installed binary library files (.a/.so) are in /usr/lib/gcc/x86_64-linux-gnu/9/.
You can list installed files of package through dpkg -L libstdc++-9-dev.
Now you can run your program like:
LD_LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/9/ your_program_name
So that it gets correct path and correct .so file.
Issue with your Notebook was solved for me by adding to setup.py following options, after that your Notebook doesn't print any error:
extra_compile_args=["-std=c++11", '-static', '-static-libgcc', '-static-libstdc++'],
extra_link_args=['-static-libgcc', '-static-libstdc++'],
Also you can collect all necessary .so files into folder of your Python's module and package all into wheel .whl file. There is no need to APT-install all .so dependencies on every machine. I think for Python is more clean solution to ship all necessary .so files inside .whl.
Related
I have recently updated to Mojave and since then am experiencing linking problems to libraries (gsl, Cuba etc.) that I had installed with Homebrew.
When compiling my code, gcc (tried g++-6 and g++-8, also installed with brew) does not seem to search the directories where brew stores the header files for those libraries. The code compiled when I manually set the paths to
GSL_INCLUDE_PATH=/usr/local/include/gsl/
GSL_LIB_PATH=/usr/local/lib/
CUBA_PATH=/usr/local/include/
But since I am using this in all my make-files I do not want to do this every time...
Before I was using Sierra and I have included in my .bash_profile the following:
export PATH=/usr/local/bin:/usr/local/sbin:$PATH
export PATH="/usr/local/opt/coreutils/libexec/gnubin:$PATH"
This seemed to do the trick before. But now /usr/local/sbin did not exist anymore. I ran brew doctor which suggested:
You should create these directories and change their ownership to your account.
sudo mkdir -p /usr/local/Frameworks /usr/local/sbin
sudo chown -R $(whoami) /usr/local/Frameworks /usr/local/sbin
I did just that and reinstalled the libraries but it did not sort out the issue.
I have tried to include
export PATH=/usr/local/bin:/usr/local/sbin:/usr/local/include:/usr/local/lib:$PATH
in the bash-profile, but that did not help either. (Maybe I did it wrong, I am not familiar with setting paths) At this point I am not sure whether brew installs the libraries in a weird place or if gcc just does not look in the correct location.
I have installed Xcode and the command tools. I have tried everything I found (and could understand) that I found as solutions for related problems.
I would like for gcc to look in the directories that brew installs the libraries to by default.
I would be really grateful for a suggestion of a clean fix for this issue.
Please excuse the long essay; if you need additional information please do tell, this ist my first time asking for help here.
I've been playing with this library for the Raspberry Pi (Raspian/DietPi - Jessie) and ran into a peculiar situation. I made some local changes, built, and installed the library like so:
cmake ..
sudo make install
sudo ldconfig
However later I made a correction to the library then built and installed the library, but did not run the 'ldconfig' command. I ran my program that uses these dynamically linked libraries and it worked with the updated libraries.
However, I then realized I forgot 'sudo ldconfig' and after executing it, the program was clearly running with the previous library version. I repeated this several times and had to actually use 'ldconfig -p' to find where the .so files were and delete them so that the next ldconfig would use the latest files, and then the problem was resolved.
Why would 'sudo ldconfig' grab a previous version of these build libraries, and where would it grab them from?
You can add your current lib path to etc/ld.so.conf and then run ldconfig again.
Or you can add to LD_LIBRARY_PATH
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/new/path/newpath
I'm trying to install Loris package link which is a library also for Python (my language). I have installed the package through bash commands in my OSX 10.12 system following these steps:
cd to the directory containing the package's source code and type
./configure to configure the package for your system. If you're
using csh on an old version of System V, you might need to type
sh ./configure instead to prevent csh from trying to execute
configure itself.
Running `configure' takes awhile. While running, it prints some
messages telling which features it is checking for.
Type `make' to compile the package.
Optionally, type `make check' to run any self-tests that come with
the package.
Type `make install' to install the programs and any data files and
documentation.
You can remove the program binaries and object files from the
source code directory by typing make clean. To also remove the
files that configure created (so you can compile the package for
a different kind of computer), type make distclean. There is
also a make maintainer-clean target, but that is intended mainly
for the package's developers. If you use it, you may have to get
all sorts of other programs in order to regenerate files that came
with the distribution.
The problem is that when I run both python 2.7 IDLE and the Atom editor it says that the module named Loris was not found. By default, make install will install the package's files in
/usr/local/bin,/usr/local/man.
Is this the problem? How can I install properly this library?
I tried to compile FLANN with cmake, but the only result was a giant headache.
So I found here this solution through PCL repository and synaptic. The installation seems gone well, but now I don't know how to use the installed package.
Quoting FLANN's documentations :
An example of the compile command that must be used will look
something like this: g++ flann_example.cpp -I $FLANN_ROOT/include -o flann_example_cpp where $FLANN ROOT
is the library main directory.
But it's not clear to me where $FLANN_ROOT is.
The $FLANN_ROOT is a path where the library was installed. This is mostly relevant when you build and install manually (especially when installing to non-standard locations).
When installed by the packaging system (Synaptic - I guess Ubuntu?) the library headers will be most likely installed in '/usr/include' or '/usr/local/include'. Normally you do not have to use the -I then as those paths are examined by default.
I am new in Ubuntu/Linux and I've been working with java using the NetBeans IDE, so I don't have much experience with building c++ projects. But now I have to provide a proof of concept and I need to connect a C++ client with my ActiveMQ server. I downloaded The ActiveMQ-CPP API from this link, but I can't build/run it.
The download came with the files: Maklefile.am and Makefile.in. I searched it and I found that I need automake/autoconf to build it. I tried running ./configure but it says that it couldn't find such file or directory. I tried
sudo apt-get update
sudo apt-get install automake
sudo apt-get install autoconf
and a lot of other commands that I found on the Internet. None of then worked. I know that this question is really basic and it seems to be already answered somewhere else, but every attempt I've made failed. I think I'm missing something. I even tried the solution provided in the last message in this topic but it didn't work either.
Can anyone help me install autoconf/automake, or tell me how to use Makefile.am / Makefile.in to build the project I downloaded, or even suggest me some other way of building it?
Since you're open to other methods of building your project, I'm going to suggest CMake. It is a far better build system than autotools (at least from where I stand).
#CMakeLists.txt
project(MyProject CXX)
set_minimum_required(VERSION 2.8)
add_executable(foobar foo.cpp bar.cpp)
That example will build an executable called "foobar" by compiling and linking foo.cpp and bar.cpp. Put the above code in a file called CMakeLists.txt, then run the following commands:
cmake <path to project> #run in the folder you want to build in
make #this does the actual work
The really cool thing about CMake is that it generates a build system (Makefiles by default) but you can use it to generate project files for Eclipse, a Visual Studio solution, and a bunch of other things. If you want more information, I'd check out their documentation.
The "configure" script should be in your ActiveMQ-cpp source directory. From the Linux command line, you should be able to:
1) "cd" into your ActiveMQ* directory
2) "ls -l" to see the "configure" script
3) "./configure" to set things up for building the library\
4) "make" to actually build the library
This is mentioned in comments, but this particular point of confusion has been common for well over a decade and I think needs to be clarified as often as possible. You DO NOT need to have autoconf or automake installed to build a project that used those tools. The entire point of the autotools is to generate a build system that will build on a system using only the standard tools (make, a c compiler, sh, and few others.) Unfortunately, many developers release tarballs that do not build cleanly. If you unpack the tarball and it does not contain a configure script, or if the configure script is broken, that is a bug in the package. The solution is absolutely not to install autoconf/automake/libtool and try to produce a working configure script. The solution is to report the build error as a bug to the package maintainer.
The world would be a better place if Linux distributions stopped installing multiple versions of the autotools by default as less than .002% of the population needs those tools, and anyone who actually needs to have the tools should be capable of installing it themselves. Anyone incapable of acquiring and installing the tools has no business using them.