I've checked out a ROS package that I have on my repository on a different PC (ubuntu).
The problem is that while rosmake (or make for that matter) from cli, in eclipse it gives me the following error.
/usr/bin/make all
rospack: error while loading shared libraries: librospack.so: cannot open shared object file: No such file or directory
Makefile:1: /cmake.mk: No such file or directory
make: * No rule to make target `/cmake.mk'. Stop.
I suppose it's problem is eclipse's build enviroment. How do I debug this?
Shouldn't it work out of the box?
It seems that because I was running eclipse from an icon it couldn't get the environment variables. I had to change the link to bash -i -c eclipse.
Related
I wonder if anyone can help me..
I'm having a problem trying to build 'Freechart' charting widget, downloadable from here:
https://sourceforge.net/projects/wxcode/files/Components/wxFreeChart/
Project: 'freechart-1.6.zip'
I'm using widgets 3.1.1 with a GCC compiler. I've built it with WX_SHARED=1, using the following build command:
mingw32-make -f makefile.gcc WX_DIR=C:\wxWidgets-3.1.1 WX_SHARED=1 WX_UNICODE=1 WX_MONOLITHIC=1 WX_DEBUG=1 WX_VERSION=31
It builds and the following .a and .dll files are generated in the lib/gcc_dll folder:
libwxcode_msw31ud_freechart.a
libwxcode_msw31ud_freechart.dll
However, when I try to build it with SHARED=0, using:
mingw32-make -f makefile.gcc WX_DIR=C:\wxWidgets-3.1.1 WX_SHARED=0 WX_UNICODE=1 WX_MONOLITHIC=1 WX_DEBUG=1 WX_VERSION=31
It throws the error:
C:/Program Files (x86)/CodeBlocks/MinGW/bin/../lib/gcc/mingw32/5.1.0/../../../../mingw32/bin/ld.exe: cannot find -lwxmsw31ud
The file exists in the widgets 3.1.1 lib directory, here:
C:\wxWidgets-3.1.1\lib\gcc_dll
There isn't an actual project file for freechart that can be opened in codeblocks, So, the widgets libwxmsw31ud.a file can't be set in the Project/Build options/Linker settings. Freechart is built in the command prompt. I'm not sure how to tell the compiler where to find this file.
As I said, the build works with SHARED=1. Any input would be much appreciated.
Paul
It looks like you did not build wxWidgets as a static library required by your build options due to the use of WX_SHARED=0, as you should have the outputs of this build in gcc_lib subdirectory and not the gcc_dll one. You need to either make sure that you build wxWidgets itself as static libraries (using SHARED=0 when building it) or use WX_SHARED=1 if you're fine with using wx DLLs.
BTW, there is absolutely no reason to use 4-year old wx 3.1.1, please use the much more recent 3.1.6.
I download POSIX Threads for Windows source code from https://sourceforge.net/projects/pthreads4w/files/.
Unzip it. In the directory, there several files for make:
Bmakefile Makefile Nmakefile GNUmakefile.in
If directly run mingw32-make, I get
Makefile:123: *** missing separator. Stop.
Open makefile in editor, the first line told me:
This makefile is compatible with MS nmake
Maybe it is not a standard makefile file?
So, I just delete makefile. and change the name of GNUmakefile.in into makefile. Then run 'mingw32-make' again, I get
process_begin: CreateProcess(NULL, #RC# --help, ...) failed.
mingw32-make: makefile:112: pipe: No error
makefile:180: #srcdir#/common.mk: No such file or directory
mingw32-make: *** No rule to make target '#srcdir#/common.mk'. Stop.
I don't really know how make actualy working. But if I want to compile it, what should I do?
===========================================================
UPDATE
There is README file, and it suggest how to build using MINGW. But seems all it told(like autoheader autoconf ) are not windows commands.
Building with MinGW
NOTE: All building and testing is done using makefiles. We use the
native make system for each toolchain, which is 'make' in this case.
We have found that Mingw builds of the GCE library variants can fail
when run on 64 bit systems, believed to be due to the DWARF2 exception
handling being a 32 bit mechanism. The GC variants are fine. MinGW64
offers SJLJ or SEH exception handling so choose one of those.
From the source directory:
run 'autoheader' to rewrite the config.h file
run 'autoconf' to rewrite the GNUmakefiles (library and tests)
run './configure' to create config.h and GNUmakefile.
run 'make' without arguments to list possible targets.
E.g.
$ autoheader
$ autoconf
$ ./configure
$ make realclean all-tests
===========================================================
UPDATE
Seems the MINGW I downloaded already contains pthreads library. I don't need to compile it now.
I would like to create a CMake project using cmake -i interactive mode, but came across the error:
cmake: error while loading shared libraries: libidn2.so.0: cannot open shared object file: No such file or directory
I've been following the tutorial https://learnopengl.com/, but use Manjaro Linux instead of Windows, so wanted to use the command line as explained in https://cmake.org/runningcmake/
On research, most examples suggested adding to the LD_LIBRARY_PATH. I attempted this, locating libidn2.so at /usr/lib and adding it to the relevant path. It had no affect whatsoever however.
Next I attempted uninstalling CMake in the package manager, and curiously the command still gave the same error message, even though given it was uninstalled, CMake should not be recognized as a command at all.
I have had problems with CMake on my machine in the past, having been unable to install and link the CGAL library using CMake, so it may be a symptom of a wider issue.
I found a solution to the problem after using which cmake. Turns out there was another set of the cmake commands that came with the operating system I found in /usr/local/bin/cmake.
It was solved by deleting the command files in this location, so the command files of the actual installation were run instead, which functioned correctly.
I'm trying to get SFML (www.sfml-dev.org) running under Eclipse which is running on Ubuntu 16.04, my c++ compiler is nvcc as this is a cuda project. I have my includes and libraries set up as follows:
The project builds fine, but when I run it I get the error message:
error while loading shared libraries: libsfml-window.so.2.4: cannot open shared object file: No such file or directory
This is weird, because the file exists (/home/timo/cuda-workspace/CudaTutorial/SFML/lib). Does anyone know how I can resolve this issue?
Well, in the end creating a conf file did it:
gksudo gedit /etc/ld.so.conf.d/sfml.conf
/lib/SFML/lib
sudo ldconfig
(I put the SFML build into lib in case I want to use it in another project).
I ran into a problem while trying to use Clion.
I imported a project, yet all off the headers and .cpp files are greyed out. The error shown is as in the title: "Cannot load CMake project: CMake executable is incorrect".Here is a screenshot of it.
It's worth noting that I'm working with kubuntu and have downloaded all of the following: gcc, g++, make, cmake, gdb.
I would love some help with solving this problem so I could start working with Clion.
Thanks in advance.
I just ran into this. Deleting the project's .idea directory and having clion recreate it fixed the issue for me.
Clion also reported that Bundled Cmake does not work in this enviroment
And when setting the actual path to the cmake binary it said it wasn't there when it was.
make a c executable project.
go to file->settings
Look for a setting where you can configure the path of Cmake on your system (maybe /usr/bin/cmake).
Clion hasn't found cmake executable
first case cmake isn't installed :
1.1. ubuntu : sudo apt-get install cmake
1.2. Go to Settings->Build,Execution,Deployement-> Toolchains:
set cmake executable to custom , and type : which cmake in your console
set field right to custom to dir of cmake
do same thing for gdb the apply
second case cmake is install then go to (1.2)
I am using WSL (wsl2 to be correct) and I had the same issue. Somehow CLion seems to have a problem with /usr/bin/cmake only being a link to the real cmake file. So to resolve this, follow each link till you hit the location of the executable
for windows users being new to linux:
which cmake (most probably shows /usr/bin/cmake)
cd /usr/bin/cmake
ls -la | grep cmake (shows something like 20 Mar 26 09:54 cmake -> /opt/cmake/bin/cmake)
do this till there is no link anymore
pass this path to clion
I already added this as a bug: https://youtrack.jetbrains.com/issue/CPP-20644