When I compile the sources from just a directory it's OK. But if I do it from dmg image I got this:
$ make
"/Volumes/:Users:me:develop:macos_build_script:myApp:myApp_Release:myApp/myApp.app/Contents/MacOS/devkit-x86/sysroots/i386-pokysdk-darwin/usr/bin/i586-poky-linux/i586-poky-linux-g++" -std=c++11 -Wall -O2 --sysroot="/Volumes/:Users:me:develop:macos_build_script:myApp:myApp_Release:myApp/myApp.app/Contents/MacOS/devkit-x86/sysroots/core2-32-poky-linux" -c -MD main.cpp -I/Volumes/:Users:me:develop:macos_build_script:myApp:myApp_Release:myApp/myApp.app/Contents/MacOS/devkit-x86/sysroots/core2-32-poky-linux/usr/include/c++/4.9.1 -I/Volumes/:Users:me:develop:macos_build_script:myApp:myApp_Release:myApp/myApp.app/Contents/MacOS/devkit-x86/sysroots/core2-32-poky-linux/usr/include/c++/4.9.1/i586-poky-linux -o main.o
"/Volumes/:Users:me:develop:macos_build_script:myApp:myApp_Release:myApp/myApp.app/Contents/MacOS/devkit-x86/sysroots/i386-pokysdk-darwin/usr/bin/i586-poky-linux/i586-poky-linux-g++" -std=c++11 -Wall -O2 --sysroot="/Volumes/:Users:me:develop:macos_build_script:myApp:myApp_Release:myApp/myApp.app/Contents/MacOS/devkit-x86/sysroots/core2-32-poky-linux" main.o -I/Volumes/:Users:me:develop:macos_build_script:myApp:myApp_Release:myApp/myApp.app/Contents/MacOS/devkit-x86/sysroots/core2-32-poky-linux/usr/include/c++/4.9.1 -I/Volumes/:Users:me:develop:macos_build_script:myApp:myApp_Release:myApp/myApp.app/Contents/MacOS/devkit-x86/sysroots/core2-32-poky-linux/usr/include/c++/4.9.1/i586-poky-linux -lopencv_core -lopencv_highgui -lopencv_imgproc -lzmq -o aaa.bin
collect2: fatal error: cannot find 'ld'
compilation terminated.
make: *** [aaa] Error 1
After this error I unpack contents from *.dmg then run it and compilation completes successful.
Why and what I need to do to make it work from dmg?
My *.dmg contains an application and a cross-compiler. Source files for compilation are outside and created by this application. It is simple IDE.
Finaly I find out the cause of this problem. It is two bug-or-features one in macdeployqt and one in g++.
When I wrote my building script I thought it will be good to get dmg image in same directory from which I run my script. And I added a command with absolute path:
macdeployqt /Users/me/develop/macos_build_script/myApp/myApp_Release/myApp/myApp.app -dmg
The image was built and my app ran well. But. Silently macdeployqt made a name for dmg mount point from absolute path. The absolute path became a single directory name with colons instead slashes:
:Users:me:develop:macos_build_script:myApp:myApp_Release:myApp. The root of dmg did not contain this directory, it only appears when dmg image is mounted.
Then this directory with colons will be part of variables of makefile.
Cross-compilator i586-poky-linux-g++ builds an object files when paths with colons present. And I thought it's all ok with g++ if it using this coloned paths for object files. I thought the cause somwhere in other place. But I was wrong.
Backslashing of colons din't help.
In some moment I builded the dmg image by hands from a directory in which myApp.app bundle subdirectory placed with this short command:
macdeployqt myApp.app -dmg
And the problem is gone. The mount point of dmg image now is just /Volumes/myApp. I do nothing except jump to dir where myApp.app is and making the relative path.
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.
I installed boost_1_55_0 under /usr/local/boost_1_55_0, and in my makefile I set the linking flag as:
CC = g++
CFLAGS = -I ./ -I/usr/local/boost_1_55_0 -w -std=c++11
LFLAGS = -L./ -lm -lpthread -L/usr/local/boost_1_55_0/lib -lboost_regex
I encountered nothing during compile time, but I got:
./$(exec): error while loading shared libraries:
libboost_regex.so.1.55.0: cannot open shared object file: No such file
or directory
I'm pretty sure I cleaned all old files and compiled again, I also granted access to read the files in usr/local/boost_1_55_0 by sudo chmod -R +x /usr/local/boost_1_55_0 just in case I banned access to read. However, I still got this error. I also tried to move boost_1_55_0 in /usr/lib/ but it does not work either.
I've also read this question: Compiling issue with boost and tried both solutions under this question, but neither of them works for me. Can someone figure out a different solution?
As the error implies, your executable is unable to find the shared library. Add the .so file (or all of them, if you want to be safe) that was generated by the boost build process to the same directory where your program's executable is getting generated, and try running the program again.
I manually cleaned the executable files and compiled it again, and it somehow solved my problem. I am guessing there must be some config in my system messed up so that the executable would invisibly linked to some outdated directory and cause this problem.
I have written a few programs and while trying to compile them using g++,as thus,
$ g++ minIni.c device_datum.cpp fanuc_axis.cpp fanuc_path.cpp service.cpp condition.cpp cutting_tool.cpp string_buffer.cpp logger.cpp client.cpp server.cpp adapter.cpp fanuc_adapter.cpp FanucAdapter.cpp -L/usr/local/lib/ -lfwlib32 -lpthread -o adapter
I keep getting the following error:
/usr/bin/ld: cannot find -lfwlib32
collect2: error: ld returned 1 exit status
fwlib32.h is the library I am trying to include. The shared object file libfwlib32.so is present in /usr/local/lib as well as /usr/lib. But I am unable link to it. I have tried all the solutions offered by similar questions including
$ export LIBRARY_PATH=/usr/local/lib/
$ export LD_LIBRARY_PATH=/usr/local/lib
I have done the above for /usr/lib as well, but still the same error.
I have tried using the -L option in the command line but I still get the error.
I even created a new folder called lib, pasted libfwlib32.so.1.0.1 into it and ran
$ ln -s ~/lib/libfwlib32.so.1.0.1 ~/lib/libfwlib32.so
on the console to create a new .so file and gave ~/lib as argument to -L option on the command line. It made no difference. I am at the point of tearing my hair out so any help will be appreciated.
Thanks alot!
You should put -l option in the very last as:
$ g++ minIni.c device_datum.cpp fanuc_axis.cpp fanuc_path.cpp service.cpp condition.cpp cutting_tool.cpp string_buffer.cpp logger.cpp client.cpp server.cpp adapter.cpp fanuc_adapter.cpp FanucAdapter.cpp -L/usr/local/lib/ -o adapter -lfwlib32 -lpthread
Note: Please make sure that all the header and source file are in the same folder.
Note that specifying -L~/lib won't work as the ~ will not be expanded by the shell. Also you can't add a space between -L and ~/lib. Instead you must specify it as a relative or absolute path.
Have you checked that the libfwlib32.so symlink exists in /usr/local/lib (or /usr/lib) in addition to the libfwlib32.so.1.0.1 file?
Another possibility is that the library is the wrong architecture (ie. 32-bit while your system is 64-bit), but then ld should print a message about skipping incompatible library. You can check the architecture of the library by running 'file libfwlib32.so.1.0.1'.
The error message suggests that -lfwlib32 is being interpreted as a filename not as a -l parameter. Put all the parameters before the files to be compiled
g++ -m32 -L/usr/local/lib/ -lfwlib32 -lpthread -o adapter minIni.c device_datum.cpp fanuc_axis.cpp fanuc_path.cpp service.cpp condition.cpp cutting_tool.cpp string_buffer.cpp logger.cpp client.cpp server.cpp adapter.cpp fanuc_adapter.cpp FanucAdapter.cpp
As has been pointed out by #Erik Johannessen, libfwlib32.so is a 32bit library, so you need to add -m32 to build a 32bit executable.
I have a R package that I'm working on that contains code written in C and C++ under the src folder. Currently, the package compiles and works on Rstudio as it follows the default directory structure. As the project builds, I want to be able to organize my code under src, within subfolders. Following directions from "Writing R extensions" - Compiling under sub-directories, I have made a folder called 'test'(/src/test) which now contains all my files(*.c, *.cpp, *.h) and modified my Makevars like so -
SOURCES_C = $(wildcard test/*.c)
SOURCES_CPP = $(wildcard test/*.cpp)
PKG_CPPFLAGS= -I${R_HOME}/include -I.
PKG_LIBS = -L${R_HOME}/lib
CXX_STD = CXX11
OBJECTS =$(SOURCES_CPP:.cpp=.o) $(SOURCES_C:.c=.o)
all : $(SHLIB)
#PKG_CFLAGS= -Wall
clean : rm -f *.o
I want to be able to compile the program in this state, where the C/C++ files are under subfolders inside src. Using the aforementioned Makevars -> the separate object files are being built from the test folder with the correct flags and compiler, for all C/CPP files. However, there are some discrepancies with the build command for the shared object. This is the log when compiling the files under src/test which fails with an undefined symbol error.
gcc -std=gnu99 -shared -L/usr/local/lib64 -o BioCro.so test/BBox.o test/Climate.o test/Compound.o test/Grid.o test/LeafOptics.o test/Maths.o test/Normal.o test/Point3D.o test/Ray.o test/Triangle.o test/Vector3D.o test/runFastTracer.o test/Assigncropcent.o test/AuxBioCro.o test/AuxCropGro.o test/AuxMaizeGro.o test/AuxcaneGro.o test/Auxcropcent.o test/AuxwillowGro.o test/BioCro.o test/CalculateBiogeochem.o test/Calculate_Soil_Layer_Temperature.o test/CanA.o test/CanAC_3D.o test/Century.o test/Copy_CropCent_To_DayCent_Structure.o test/Copy_SoilWater_BioCro_To_CropCent.o test/CropGro.o test/CropGro_c.o test/Filling_BioCro_SoilStructure.o test/assignManagement.o test/c3CanA.o test/c3EvapoTrans.o test/c3photo.o test/c4photo.o test/caneGro.o test/createNULLc3tree.o test/cropcent.o test/dailywillow.o test/denitrify.o test/diffusiv.o test/eC4photo.o test/getIdirIdiff.o test/getsoilprop.o test/leachdly.o test/maizeGro.o test/methane.o test/microclimate_for_3Dcanopy.o test/nitrify.o test/nox_pulse.o test/pi_funcs.o test/printcropcentoutput.o test/test_mainC.o test/tgmodel.o test/tracegas.o test/update_3Dcanopy_structure.o test/wfps.o test/willowCent.o test/willowGro.o -L/usr/local/R-3.1.0/lib64/R/lib -L/usr/local/R-3.1.0/lib64/R/lib -lR
installing to /home/vashist1/R/x86_64-unknown-linux-gnu-library/3.1/BioCro/
** R
** data
** inst
** preparing package for lazy loading
** help
*** installing help indices
** building package indices
** installing vignettes
** testing if installed package can be loaded
Error in dyn.load(file, DLLpath = DLLpath, ...) :
unable to load shared object '/home/vashist1/R/x86_64-unknown-linux-gnu-library/3.1/BioCro/libs/BioCro.so':
/home/vashist1/R/x86_64-unknown-linux-gnu-library/3.1/BioCro/libs/BioCro.so:
undefined symbol: _ZTVN10__cxxabiv117__class_type_infoE
Error: loading failed
Compared with the successful log which builds successfully!
g++ -shared -L/usr/local/lib64 -o BioCro.so Assigncropcent.o AuxBioCro.o AuxCropGro.o AuxMaizeGro.o AuxcaneGro.o Auxcropcent.o AuxwillowGro.o BBox.o BioCro.o CalculateBiogeochem.o Calculate_Soil_Layer_Temperature.o CanA.o CanAC_3D.o Century.o Climate.o Compound.o Copy_CropCent_To_DayCent_Structure.o Copy_SoilWater_BioCro_To_CropCent.o CropGro.o CropGro_c.o Filling_BioCro_SoilStructure.o Grid.o LeafOptics.o Maths.o Normal.o Point3D.o Ray.o Triangle.o Vector3D.o assignManagement.o c3CanA.o c3EvapoTrans.o c3photo.o c4photo.o caneGro.o createNULLc3tree.o cropcent.o dailywillow.o denitrify.o diffusiv.o eC4photo.o getIdirIdiff.o getsoilprop.o leachdly.o maizeGro.o methane.o microclimate_for_3Dcanopy.o nitrify.o nox_pulse.o pi_funcs.o printcropcentoutput.o runFastTracer.o test_mainC.o tgmodel.o tracegas.o update_3Dcanopy_structure.o wfps.o willowCent.o willowGro.o -L/usr/local/R-3.1.0/lib64/R/lib -lR
installing to /home/vashist1/R/x86_64-unknown-linux-gnu-library/3.1/BioCro/libs
1) The shared object compiles using g++ under default conditions, whereas under subdirectory conditions the compiler used is gcc. Can I change that behaviour via Makevars?
2) Further research allowed me to find that the undefined symbol error is a linking error fixed by the -L/-l flag. However, the -L flag is the same for both build commands. Is there any other library I am failing to link which is linked by default?
I ran into the same issue. Looking at the example of the RSiena package mentioned as an example in "Writing R Extensions" section 1.2.1.3 I noticed that that package still has some .cpp files not in a subdirectory. So I added a dummy.cpp file in src/ with the following contents:
void dummy (void)
{
}
After this g++ was correctly used for the linking step and the .so file was created as expected.
In my case it turns out that I don't need to change the Makevars files as I first mentioned in my answer. Even without the change below (so only having the dummy.cpp file present in src/) linking is done correctly.
I'll leave it in in case it may help someone else with a (slightly) different setup.
And add the corresponding .o file in the list of $(OBJECTS) variable in the Makevars file:
OBJECTS = $(SOURCES:.cpp=.o) dummy.o
I tried to compile sfml 2.0.
At first I wrote this command:
g++ -c sprite.cpp -I sfml/include
Every files are on my desktop now and the folder that contains the sfml files is called sfml and it is on my desktop also.
After this command, I wrote:
g++ -o sprite sprite.o -L sfml/lib -lsfml-graphics -lsfml-window -lsfml-system
After this, I simply did:
./sprite
The problem is here. When I try to run it i get:
./sprite: error while loading shared libraries: libsfml-graphics.so.2: cannot open shared object file: No such file or directory
The loader could not find the library libsfml-graphics.so.2. It seems that this library is located under sfml/lib.
Once solution consists in adding the location to the environment variable LD_LIBRARY_PATH and exporting it before running your executable:
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:sfml/lib