Build errors but working so far
I'm getting all these undefined reference errors when building glew 2.0 with MSYS/mingw (mingw-developer-toolkit-2013072300-msys-bin.meta)
I'm not very familiar with building makefiles, but have followed the instructions on their documentation:
https://github.com/nigels-com/glew#msysmingw
$ mingw32-make
$ mingw32-make install
$ mingw32-make install.all
The odd thing is that glew appears to be working fine with this build after adding the generated .dll / .a / .h files to their respective folders & running a basic openGL test (couldn't get it to work previously because the library / binaries are built for visual studio).
Should I be worried about these errors ?
If you need additional info to help just let me know.
The Makefile references files in the config-subfolder. I digged my way through, and ended up commenting a line out (by prepending a #).
in file:
glew_2.0.0/config/Makefile.mingw
in line 9:
LDFLAGS.EXTRA += -nostdlib
However, I have yet to work with the libs built this way. I do not know if you will run into other problems with that approach. I can imagine that there's a reason for excluding stdlib.
Compiling worked fine besides the following errors. Don't know if they're relevant.
$ mingw32-make
process_begin: CreateProcess(NULL,mktemp -d /tmp/glew.XXXXXX, ...) failed.
[...]
$ mingw32-make install
process_begin: CreateProcess(NULL,mktemp -d /tmp/glew.XXXXXX, ...) failed.
[...]
$ mingw32-make install.all
process_begin: CreateProcess(NULL,mktemp -d /tmp/glew.XXXXXX, ...) failed.
Following files have been produced:
bin/visualinfo.exe
bin/glewinfo.exe
lib/glew32.dll
lib/libglew32.a
lib/libglew32.dll.a
Related
I am trying to troubleshoot a problem I have in using the library matplot++. I need someone to teach me how to fish here instead of giving me a fish, because I'm struggling to google search the right terms to solve my problem.
My folder structure is as follows
-music_vis
|-libs
|-3rd party
|-matplot
|-matplot.h
|-other_folders_for_matplot
|-wavs
|build.sh
|main.cpp
|thread_pool.hpp
build.sh is as follows right now:
g++ -Wall -lmatplot -I /$(pwd)/libs -g -o music_vis_cpp ./music_vis_main.cpp -lstdc++fs -std=c++17 -pthread
Everything 100% works in this shell script except for something within this section:
-lmatplot -I /$(pwd)/libs
For which I get the following error:
/usr/bin/ld: cannot find -lmatplot
collect2: error: ld returned 1 exit status
Is g++ spuriously looking in my /usr/bin/ for files? Shouldn't it be looking in $(pwd)/libs?
From what I have researched, I am also supposed to have .so files, but everything under the matplot folder is .cpp or .h files. Does this mean I installed the library incorrectly into my /lib/ folder? I cloned from github and simply copied into my /lib/ folder. Without the -lmatplot flag I get the following error:
Any thoughts, resources, guidance or guidelines on how to troubleshoot these problems in the future? Thanks friends.
I followed the instructions on the repo, but piggybacking off of Compiler not finding jpeg and png libraries , I added the following flag to the cmake. This created object files for me.
-DBUILD_SHARED_LIBS=ON
I was able to build a .so file by following the build instructions included in the matplot++ .md file, but supplying an extra flag -DBUILD_SHARED_LIBS=ON
From there, under the build folder, I found a .so file somewhere in the folder tree, moved that to my /lib/ directory, and ran the following shell script:
#!/bin/bash
g++ -I /$(pwd)/libs -L /$(pwd)/libs -Wall -g -o music_vis_cpp ./music_vis_main.cpp -lstdc++fs -std=c++17 -pthread -lmatplot
And this finally built my program. However it doesn't run because shared object file doesn't exist or something.
Edit: More steps to make the program run;
Create a folder on your filesystem you want to put your .so files into and then...
export LD_LIBRARY_PATH=/home/harrison/Documents/computer/cpp_packages/shared_object_lib/
I need to run this export line every time I restart my computer, so I just add it to my build script.
So the .so file is in two places, one necessary at build time and the other necessary at run time. My binaries can be run anywhere on my computer with this method.
So I follow the official tutorial for the installation : https://mongodb.github.io/mongo-cxx-driver/mongocxx-v3/installation/
Neverless, I can't use the produced libraries as static.
So I managed to compile the C version of the driver as described, I've enabled the flag --enable-static=yes with the ./configure before doing make && sudo make install and I got the libmongoc-1.0.a and the libbson-1.0.a which are static. So this far, everything it's alright.
Then I have done the cxx version of the driver, except that there is no configuration file as in the C version. So I've juste done a
cmake -DCMAKE_BUILD_TYPE=Release -DBSONCXX_POLY_USE_BOOST=1 -DCMAKE_INSTALL_PREFIX=/usr/local
from the build folder, followed by a make && sudo make install
So I got the libmongocxx.a and the libbsoncxx.a, but when I try to compile with them, I can't run the binary because I got the following error :
error while loading shared libraries: libmongocxx.so._noabi: cannot open shared object file: No such file or directory
So I understand that is because there is some symbols missing and then I need to use the shared library to run the binary but I don't want this to happend, I want the symbols within the binary that I can run it without any LD_PRELOAD.
Any suggestions ?
I had the same issue in an Ubuntu 16.04 and I run a apt-get update & apt-get upgrade and the problem was solved.
It seems that there were some update to the compiler and some libraries that prevent some test from reaching the shared libraries.
I have a similar question, and solved, now I compiled and run my binary with static libs successfully.
I write my build script using newlisp, but the static link options are very helpful, I paste it here.
c++ /to/your/path/site/code/back_end/builder/object/files1.cc.o ... /to/your/path/site/code/back_end/builder/object/files10.cc.o -o bin/site -static-libgcc -static-libstdc++ -L/usr/lib -lpthread -l:libmongocxx.a -l:libbsoncxx.a -l:libmongoc-1.0.a -l:libbson-1.0.a -lrt -lssl -lcrypto -lsasl2 -l:libboost_log.a -l:libboost_log_setup.a -l:libboost_system.a -l:libboost_thread.a -l:libboost_filesystem.a -lcppcms -lbooster -lcurl -ljsoncpp
I'm getting an ld error when attempting to compile an sfml program on ubuntu 16.04. This is apparently a known issue, and there is supposed to be a workaround, but I don't understand what is it...
http://web.archive.org/web/20160509014317/https://gitlab.peach-bun.com/pinion/SFML/commit/3383b4a472f0bd16a8161fb8760cd3e6333f1782.patch
The error spat out by ld is
hidden symbol `__cpu_model' in /usr/lib/gcc/x86_64-linux-gnu/4.9/libgcc.a(cpuinfo.o) is referenced by DSO
There is no relevant code to this - as I understand it this error is produced on all ubuntu 16.04 systems with g++ 5, if the program to be linked contains objects such as sf::Texture and sf::Sprite. (I don't know any more detail than this.)
I have tried also compiling with g++ 4.9, but the same error occurs.
My compile line is g++-4.9 --std=c++11 -Wall main.cpp -lsfml-graphics -lsfml-window -lsfml-system -o a.out
Has anyone else experienced this error and resolved it successfully?
I've had to fix this issue several times. Instead of applying the patch, you can manually fix it by editing the file SFML/src/SFML/Graphics/CMakeLists.txt. At line 149, you will find the following:
if(SFML_COMPILER_GCC)
set_source_files_properties(${SRCROOT}/ImageLoader.cpp PROPERTIES COMPILE_FLAGS -fno-strict-aliasing)
endif()
After the endif(), insert the following:
if(SFML_COMPILER_GCC AND BUILD_SHARED_LIBS)
list(APPEND GRAPHICS_EXT_LIBS "-lgcc_s -lgcc")
endif()
Then, in the top-level SFML folder, run the following:
mkdir build && cd build
cmake .. -DSFML_BUILD_EXAMPLES=ON -DSFML_BUILD_DOCS=ON
make
sudo make install
sudo ldconfig
This will get it built and installed without the compiler error. (Note: Remove the -D flags from cmake if you don't want docs or examples)
I ran this in the SFML source directory before running the standard cmake...make:
curl https://gitlab.peach-bun.com/pinion/SFML/commit/3383b4a472f0bd16a8161fb8760cd3e6333f1782.patch \
| patch -p1
and that solved the problem
I've got the same linker error when trying to build SFML 2.4.2 with examples, specifically with opengl and shader ones.
Inspired by the #Joshua solution, I tried to change the compiler from GCC to Clang. It worked.
I am sharing here because it seems to be a simpler solution if you have no restrictions to use Clang.
Just download SFML and change to its directory. And...
mkdir build && cd build
cmake .. -DSFML_BUILD_EXAMPLES=ON -DCMAKE_CXX_COMPILER=clang++
make
sudo make install
sudo ldconfig
Removing -fvisibility=hidden from compiler options worked for me.
Gooday everyone
I'm fairly new to ubuntu C programing although I'm
rather experienced in C programing in windows.
I have recently come accross a number of codes written
in 2005 which I'm interested in learning how they work.
Those codes needs BOOST library to compile, however they won't
compile on the newest BOOST version present on my ubuntu 12.04.
I set the gcc compiler on lenient so that it ignores all those error
messages. The code did compile and ran afterwards.
However, when I used GDB debugger to watch how the program flows
I noticed that there are likely errors in the way the program runs
due to using a different BOOST version rather than it's original. Hence
I like to install the BOOST version corresponding to the code I downloaded.
To do that, I installed Ubuntu 5.04 and BOOST 1.33.0 which seemed to have been created in late 2005. I downloaded it
but I didnt found any detailed instruction on how to install it.
Only vague description on using BOOST jam, I played around with BOOST
jam for quite awhile without success.
And this old BOOST does not have installation commands like
"sudo apt-install boost-dev" style option
Thus I like to ask if anyone can give a easy to understand step by step instruction
on how to install the BOOST library downloaded from the above link.
like.....
step1: download boost jam from boost webpage
step2: unpack it in home/boost/ then type make configure
...and so on...
Big thanks for any useful info.
New Contents appended here
in response to the comments given
Hi, I went through the info given by your link and
managed to run the boost library examples given by your link.
That is, I can compile a single cpp file with the command
g++ -I boost_1_33_0 test.cpp -o test
(I'm keeping the boost library and the cpp file to be compiled in the
same folder)
However, the program package I'm interested in is build with make (not cmake).
I have some experience writting cmake files but not make files.
And I do not see any link to boost library command in the make file of the
program package. The readme file only has one sentence that says I
need to have boost installed without explaining what that meant.
I assume it means that either I have to build and do makeinstall the boost or
I could add some lines in the makefile for a link. I thought
maybe you can quickly point out whats missing in the makefile.
The readme file:
To compile, go into the moses directory and do 'make'. You'll need the
latest boost libraries. If compilation still fails for weird reasons,
you could try g++ with the -fpermissive (newer versions reject lots of
code that was ok with older ones). If you are going to be making
changes and recompiling frequently you'll probably want to disable -O3
in the makefile (I use templates liberally, so -O3 really speeds up
the code, but really slows down compilation).
And the makefile:
CC = g++
PROJ_NAME = moses
LINK_FLAGS = -Wall -Iutils/ -Itrees/ -Irewrite -I./ -Imodeling/ -Ifitness/ \
-Ialignment/ -Isim/ -Ilocal/ -O3
COMP_FLAGS = -Wall -Wno-sign-compare -Iutils/ -Itrees/ -Irewrite -I./ \
-Imodeling/ -Ifitness/ -Ialignment/ -Isim/ -Ilocal/ -O3
src := $(wildcard *.cc) $(wildcard utils/*.cc) $(wildcard trees/*.cc) $(wildcard modeling/*.cc) $(wildcard fitness/*.cc) $(wildcard alignment/*.cc) $(wildcard main/*.cc) $(wildcard rewrite/*.cc) $(wildcard sim/*.cc) $(wildcard local/*.cc)
obj := $(patsubst %.cc,%.o,$(src))
all: $(PROJ_NAME)
%.o: %.cc
$(CC) $(COMP_FLAGS) $< -c -o $#
$(PROJ_NAME): $(obj)
$(CC) $(LINK_FLAGS) $^ -o $(PROJ_NAME)
run:
$(PROJ_NAME)
clean:
find -regex ".*~\|.*\.o"|xargs rm -f
rm -f $(PROJ_NAME)
rm -f $(PROJ_NAME).exe*
depend:
makedepend -Y -- $(COMP_FLAGS) -- $(src)
utils/exceptions.o: utils/exceptions.h utils/utils.h
utils/io_util.o: utils/io_util.h utils/tree.h utils/basic_types.h
# ......lots more lines like that.........
I have an old instruction flying around here for Boost 1.34.1, which reads like this (project-specific stuff cut away):
unpack boost sources
cd into tools/jam/src
run ./build.sh to build bjam
cd into the main source directory
tools/jam/src/bin.linux/bjam threading=multi --layout=system --toolset=gcc --without-python variant=release --prefix=/usr/local install
The --without-python was necessary as the target system didn't have Python installed, which caused the build to fail messily.
Obviously you can / need to fiddle with the individual settings (like threading support, release vs. debug variant) to suit your needs, but it should be a good starting point.
If you need ICU support (for Boost.Regex and Boost.Locale), it gets more complicated...
Note that the build process has changed over the years; you shouldn't use the same procedure for more up-to-date boost versions. It's just what I used back then.
Edit:
As for the second part of your question, the Makefile doesn't need to refer to Boost explicitly if boost is installed in the standard system directories.
You do not have to state -I /usr/include for compilation as that is searched automatically; the same goes for -L /usr/lib during linkage.
The fact that the author of the Makefile copied the compiler flags into the linker flags verbatim doesn't really help intuitivity either... ;-)
If you have Boost in a custom directory (either the headers only, or by stating a custom directory in the --prefix option of my build instructions), you need to make the following modifications (look for "boost"):
LINK_FLAGS = -Wall -Iutils/ -Itrees/ -Irewrite -I./ -Imodeling/ -Ifitness/ \
-Ialignment/ -Isim/ -Ilocal/ -L /path/to/boost/libs -O3
COMP_FLAGS = -Wall -Wno-sign-compare -Iutils/ -Itrees/ -Irewrite -I./ \
-Imodeling/ -Ifitness/ -Ialignment/ -Isim/ -Ilocal/ \
-I /path/to/boost/includes -O3
That should do the trick. As the Makefile does not link any of the Boost binaries (e.g. -l boost_program_options or somesuch), it seems that it makes use of the Boost headers only, which would make the -L /path/to/boost/libs part (and, actually, the whole compilation step detailed above) superfluous. You should be able to get away with simply unpacking the sources and giving the header directory as additional include directory using -I /path/to/boost/headers.
I'm trying to call R from c++ on linux via RInside, I compiled R-2.15.1 from source with gcc version 4.5.3 (Debian 4.5.3-1) , I don't have sudo rights to use apt-get install. I'm using OpenBlas and a system optimized lapack. The blas and lapack libraries work fine for many scalapack applications
I installed R with
./configure --with-blas="-I/lib/OpenBLAS-v0.2.3-0/xianyi-OpenBLAS-48f075c/install/include -L/lib/OpenBLAS-v0.2.3-0/xianyi-OpenBLAS-48f075c/install/lib -lopenblas -lgfortran" --with-lapack="/usr/lib/liblapack.so -lgfortran" --enable-BLAS-shlib=yes --enable-R-shlib --enable-R-static-lib --prefix= .
which installed and runs fine,I ran make check with no errors, also all the packages (Rcpp and RInside) installed fine..
however when i use the given RInside makefile , the basic hello world example from /standard/rinside_sample0.cpp compiles! but it does not run and i get the following error
./rinside_sample0: error while loading shared libraries: libRblas.so: cannot open shared object file: No such file or directory
the file libRblas.so exists and is in the R/lib folder,
when i try to link it manually with the g++ command the make file creates or linking as follows i get a segmentation fault
/R/lib/libRblas.so ./hello_world
Segmentation fault
EDIT: heres how the example make file tries to compile an example, (which compiles fine) but won't run with the above missing libRblas.so error
g++ -I/nfs/user03/jimmie21/libs/lib64/R/include -I/nfs/user03/jimmie21/libs/lib64/R/library/Rcpp/include -I/nfs/user03/jimmie21/libs/lib64/R/library/RInside/include -g -O2 -Wall -I/usr/local/include hello_world.cpp -L/nfs/user03/jimmie21/libs/lib64/R/lib -lR -L/nfs/user03/jimmie21/libs/lib64/R/lib -lRblas -L/nfs/user03/jimmie21/libs/lib64/R/lib -lRlapack -L/nfs/user03/jimmie21/libs/lib64/R/lib -lRblas -L/nfs/user03/jimmie21/libs/lib64/R/library/Rcpp/lib -lRcpp -Wl,-rpath,/nfs/user03/jimmie21/libs/lib64/R/library/Rcpp/lib -L/nfs/user03/jimmie21/libs/lib64/R/library/RInside/lib -lRInside -Wl,-rpath,/nfs/user03/jimmie21/libs/lib64/R/library/RInside/lib -o hello_world
Couple of things:
Reproducible examples, please
You have a non-standard setup
With the script from 1), try it on a standard setting as that is how Rcpp / RInside get developed and tested (on Ubuntu / Debian)
The Rcpp test suite now contains almost 800 unit tests from around 350 unit test functions. These do not seg.fault, so the issue is at your end. Similarly, RInside has dozens of examples in the four examples/ subdirectories. This also works.
It may be as easy as tweaking the Makefile / Makevars files to make sure you get your libraries in all cases. But we can't tell as there is nothing reproducible here.
Edit If you want to link with libRblas.so then you have a completely non-standard setup as the R packages for Debian / Ubuntu as use the external BLAS. Again, not an RInside issue.
I fixed the problem by adding the R install path lib ../R/lib: to the beginning of LD_LIBRARY_PATH after that all the examples compiled and run fine