Let's say I have a library lib1.so created like that:
gcc 1.cpp -o lib1.so -shared
And I have another library lib2.so created in this way:
gcc 2.cpp -o lib2.so -shared -L. -l1
But linking against lib2.so
gcc main.cpp -o main -L. -l2
gives a warning:
warning: lib1.so, needed by lib2.so, not found (try using -rpath or -rpath-link)
But AFAIK the use of rpath is discouraged because then the library can not be moved to another location.
How do I link "main" against "lib2.so" without specifying "lib1.so" and rpath?
The RPATH header in the binary takes precedence so even if the library has no RPATH header, it will still be found IF you have copied it to the directory mentioned in -rpath
Related
I'm having trouble getting Qt to statically link its libraries when cross compiling from my Linux machine to windows. I added this to my config to make compile statically.
win32:CONFIG += -static
And by looking at the output of make it seems to have passed the flags correctly (omitting object files to make it short)
i686-w64-mingw32-g++ -static -static-libstdc++ -static-libgcc -Wl,-subsystem,windows -mthreads [exe and object files] /usr/i686-w64-mingw32/lib/libQt5Widgets.dll.a -ldwmapi -luxtheme /usr/i686-w64-mingw32/lib/libQt5Gui.dll.a -lopengl32 -lgdi32 -lcomdlg32 -loleaut32 -limm32 -ljpeg -lpng -L/usr/i686-w64-mingw32/lib -lfreetype -lbz2 -lharfbuzz -lm -lintl -lglib-2.0 -lshlwapi -lpcre -lgraphite2 /usr/i686-w64-mingw32/lib/libQt5Core.dll.a -lz -lpcre2-16 -liconv -lversion -lnetapi32 -luserenv -lole32 -luuid -lwinmm -lws2_32 -ladvapi32 -lshell32 -luser32 -lkernel32 /usr/i686-w64-mingw32/lib/libglu32.a /usr/i686-w64-mingw32/lib/libopengl32.a /usr/i686-w64-mingw32/lib/libgdi32.a /usr/i686-w64-mingw32/lib/libuser32.a -lmingw32 /usr/i686-w64-mingw32/lib/libqt5main.a -lshell32
As you can see the static flags are being passed to the compiler correctly, however I tried running the resulting exe in both WINE, and on a windows machine but in both cases it tells me that it failed to find the Qt dlls. The wine error log had more info so that's the one im providing
0009:err:module:import_dll Library Qt5Core.dll (which is needed by L"Z:\\home\\zee\\mapper\\release\\mapper.exe") not found
0009:err:module:import_dll Library Qt5Gui.dll (which is needed by L"Z:\\home\\zee\\mapper\\release\\mapper.exe") not found
0009:err:module:import_dll Library Qt5Widgets.dll (which is needed by L"Z:\\home\\zee\\mapper\\release\\mapper.exe") not found
0009:err:module:LdrInitializeThunk Importing dlls for L"Z:\\home\\zee\\mapper\\release\\mapper.exe" failed, status c0000135
I'm running on an Arch Linux machine with the latest qt5base aur package (5.13.1), and the latest mignw package (g++ 9.2.0)
Your compiler command line has both static and dynamic libraries. For instance: "/usr/i686-w64-mingw32/lib/libQt5Core.dll.a" is the import library for the dynamic "Qt5Core.dll". The right file to be linked in static mode would be "libQt5Core.a". Your problem looks similar to this report of the mingw project: https://github.com/msys2/MINGW-packages/issues/4970
I'm trying to run a make file to install qserver on my OSX machine.
The make file gives me an error when I try to run. see code below:
make
/Library/Frameworks/R.framework/Resources/bin/R CMD gcc -g -O -fpic -m64 -shared -D KXVER=3 -I. -I/Library/Frameworks/R.framework/Resources/share/include base.c c.o -lpthread -L/Library/Frameworks/R.framework/Resources/share/lib -lR -o qserver.so
/Library/Frameworks/R.framework/Resources/bin/R: /Library/Frameworks/R.framework/Resources/bin/R: cannot execute binary file
make: *** [all] Error 126
Hoping someone can give me a pointer here on how to fix it.
Do you have the right version of gcc? I build with gcc-4.8 and have no issues. I recall a thread on the kdb list that mentioned the build required some features available only in later gcc versions. Give that a try.
[EDIT]
Nevermind, just saw that the error says the R binary was not found. Edit the make file to use the appropriate path for your R installation. If you don't have R installed, I suggest installing with homebrew:
brew tap homebrew/science
brew install r
After that you can replace the path in the Makefile as appropriate. I personally changed the Makefile to use $(shell R RHOME) to find the R home path, rather than assume a specific location.
JPC was partially right about gcc.
My system had two different versions of gcc loaded and the default was the standard one. I changed the makefile to run 'gcc-4.8'.
Once I finished that I got a new error: the make file couldn't locate my 'R.h' file...so i just had to reference where my r h-files were located....once I did that the make problem executed.
I was looking at the verbose=TRUE when I tried to sourceCpp a Rcpp file. The last output is:
DIR: C:/Users/xyz/AppData/Local/Temp/RtmpmielLn/sourcecpp_226416891d0e
C:/PROGRA~1/R/R-31~1.0/bin/x64/R CMD SHLIB -o "sourceCpp_22129.dll" --preclean "myfile.cpp"
g++ -m64 -I"C:/PROGRA~1/R/R-31~1.0/include" -DNDEBUG -I"C:/Users/xyz/Documents/R/win-library/3.1/Rcpp/include" -I"d:/RCompile/CRANpkg/extralibs64/local/include" -O2 -Wall -mtune=core2 -c myfile.cpp -o myfile.o
g++ -m64 -shared -s -static-libgcc -o sourceCpp_22129.dll tmp.def myfile.o -Ld:/RCompile/CRANpkg/extralibs64/local/lib/x64 -Ld:/RCompile/CRANpkg/extralibs64/local/lib -LC:/PROGRA~1/R/R-31~1.0/bin/x64 -lR
I have a few questions regarding this:
the 1nd g++ command refers to -I"d:/RCompile/CRANpkg/extralibs64/local/include" and the 2nd command refers to -Ld:/RCompile/CRANpkg/extralibs64/local/lib/x64 and -Ld:/RCompile/CRANpkg/extralibs64/local/lib . But I don't have a D: drive, or a RCompile folder anywhere. What do these things refer to?
I tried to manually run the 1st g++ which ran file and created myfun.o file, but when I tried to manually run the 2nd g++ it gave me an error saying that it couldn't find the tmp.def file. I couldn't find the tmp.def file anywhere on my drives. Where would this tmp.def file located?
I looked under the hood of sourceCpp function. if I directly run the definition of cmd in the sourceCpp function: C:/PROGRA~1/R/R-31~1.0/bin/x64/R CMD SHLIB -o "sourceCpp_22129.dll" --preclean "myfile.cpp" on Windows' command window , I noticed that it does not include -I"C:/Users/xyz/Documents/R/win-library/3.1/Rcpp/include" and the R CMD SHLIB gives me an error.
How does the system(cmd, ..) within the sourceCpp function include this? The value of the cmd variable in the sourceCpp didn't include -I"C:/Users/xyz/Documents/R/win-library/3.1/Rcpp/include"
the 1nd g++ command refers to -I"d:/RCompile/CRANpkg/extralibs64/local/include" and the 2nd command refers to -Ld:/RCompile/CRANpkg/extralibs64/local/lib/x64 and -Ld:/RCompile/CRANpkg/extralibs64/local/lib . But I don't have a D: drive, or a RCompile folder anywhere. What do these things refer to?
AFAIK these are left in as part of the CRAN R Windows distribution; when R binaries are built on Windows they use something in these library paths on the build servers (but stay baked into R anyhow). You can safely ignore it, but it is a bit odd. Unused / non-existent directories passed through gcc / g++ are just ignored.
I tried to manually run the 1st g++ which ran file and created myfun.o file, but when I tried to manually run the 2nd g++ it gave me an error saying that it couldn't find the tmp.def file. I couldn't find the tmp.def file anywhere on my drives. Where would this tmp.def file located?
tmp.def, as it sounds, is a temporary definition file created by R CMD SHLIB on Windows. If you just re-run what you see it does not get generated, so I suppose R does something behind the curtains to generate it. If you are curious about where it's generated, see share/make/winshlib.mk in the R sources.
I looked under the hood of sourceCpp function. if I directly run the definition of cmd in the sourceCpp function: C:/PROGRA~1/R/R-31~1.0/bin/x64/R CMD SHLIB -o "sourceCpp_22129.dll" --preclean "myfile.cpp" on Windows' command window , I noticed that it does not include -I"C:/Users/xyz/Documents/R/win-library/3.1/Rcpp/include" and the R CMD SHLIB gives me an error.
This is because sourceCpp is setting the appropriate environment flags behind the scenes for you as well -- in this case, the CXXFLAGS environment variable. This gets automatically done on package installs as well when the LinkingTo: entry is specified in the DESCRIPTION file.
I had a very similar g++ compilation command as posted in the question, and the compilation of a very simple C function didn't work for me.
The reason it didn't work is the following option shown in the g++ command:
-I"d:/RCompile/CRANpkg/extralibs64/local/include"
which adds an include directory on a drive that does not exist on my computer. Apparently non-existent directories listed in the -I option are ignored by g++ (as stated by Kevin Ushey) but this seems not to be the case for non-existent drives.
The error message I received was that the sdtlib.h header file was not found:
C:/PROGRA~1/R/R-32~1.0/include/R.h:28:20: fatal error:
d:/RCompile/r-compiling/local/local320/include/stdlib.h: Input/output
error #include
In order to remove the offending -I option from the g++ command I had to edit the Makeconf file located in $(R_HOME}/etc$(R_ARCH) (in my case C:\Program Files\R\R-3.2.0\etc\x64) and comment out the line:
LOCAL_SOFT = d:/RCompile/r-compiling/local/local320
How to create a .so and .a file in UNIX. Do we have any standard utility for it?
*.a - archive library
to create it compile your sources:
gcc -c -o foo.o foo.c
gcc -c -o boo.o boo.c
ar -rsc yourlib.a foo.o boo.o
so - position independent code shared library
gcc -fPIC -shared -soname,libfoo.so.1 -o libfoo.so.1.0 foo.c boo.c
#create shared library
gcc -Os -fPIC -c test.c
gcc -shared test.so test.o
#create static library
gcc -Os -c test.c
ar rcs test.a test.o
The .a is also called a static library, and the .so is also called a dynamically loaded library.
I like the Program Library HOWTO.
This HOWTO for programmers discusses
how to create and use program
libraries on Linux. This includes
static libraries, shared libraries,
and dynamically loaded libraries.
The Yo Linux tutorial is also useful.
This tutorial discusses the philosophy
behind libraries and the creation and
use of C/C++ library "shared
components" and "plug-ins". The
various technologies and methodologies
used and insight to their appropriate
application, is also discussed. In
this tutorial, all libraries are
created using the GNU Linux compiler.
Take a look at this Makefile I wrote when I was new to C. It clearly shows how to generate and correctly link .a and .so files from a simple demo source.
Compiling on Fedora 10.
I am using qt for the first time. I started by creating a simple GUI application with all the default settings. When I tried to build the project I got the following error messages.
However, when I did a search for -lfreetype I found it in the following directory.
/usr/lib/libfreetype.so.6
/usr/lib/libfreetype.so.6.3.18
Is there anyway to resolve this issue?
Many thanks for any advice
Running build steps for project test1...
Creating gdb macros library...
Configuration unchanged, skipping QMake step.
Starting: /usr/bin/make debug -w
make: Entering directory `/home/steve/projects/qt/test1/test1'
/usr/bin/make -f Makefile.Debug
make[1]: Entering directory `/home/steve/projects/qt/test1/test1'
g++ -Wl,-rpath,/opt/qtsdk-2009.01/qt/lib -o test1 debug/main.o
debug/mainwindow.o debug/moc_mainwindow.o
-L/opt/qtsdk-2009.01/qt/lib
-lQtGui -L/opt/qtsdk-2009.01/qt/lib -L/usr/X11R6/lib
-pthread -lfreetype
-lgobject-2.0 -lSM -lICE -pthread -pthread
-lXrender -lfontconfig
-lXext -lX11 -lQtCore -lm -pthread -lgthread-2.0 -lrt
-lglib-2.0 -ldl -lpthread
/usr/bin/ld: cannot find -lfreetype
collect2: ld returned 1 exit status
make[1]: *** [test1] Error 1
make[1]: Leaving directory `/home/steve/projects/qt/test1/test1'
make: *** [debug] Error 2
make: Leaving directory `/home/steve/projects/qt/test1/test1'
Exited with code 2.
Error while building project test1
When executing build step 'Make'
You have to install the freetype-devel package. The devel package contains the header files which in the case of freetype shoud be located at: /usr/include/freetype.
I had the same problem on Ubuntu 8.10, QT 4.5. I "fixed" it with the following bizarre hack:
After the build fails, rename the QT lib directory to something else - e.g. "mv ../../qtsdk-2009.01/qt/lib ../../qtsdk-2009.01/qt/lib2"
Run "make" again, and it will fail again.
Restore the lib directory
Run "make" again, and now it works.
I have no idea why this happens.
Install freetype1-dev libgtk2.0-dev
and it will compile ok.
On Ubuntu 9.04, installing freetype1-dev & libgtk2.0-dev solves this problem.
But to surprise everyone the hack mentioned by Ross also works, I would really like to know how and why.. M looking into the source code of QTcreator to see if i can find out the reason why. If any one already know the reason, please let me know.
Thanks..
Just installed a newly fresh ubuntu 9.04 (dell D820)- installed qt creator nothing else - same problem
use option from S R that works because it needs libgtk2.0-dev (this will also load freetype6 ) installed from package manager.
Same effect you will see if you also install qt designer from package manager (it will install all the right packages
regards
Nico
I had same problems with Elive, freetype1-dev and libgtk2.0-dev and for the /usr/bin/ld: cannot find -lSM thing xorg-dev fixed the problem.
The first thing you have to make sure is that you have libfreetype.so installed in your computer. Use the command 'locate libfreetype.so', and you may find there is a '/usr/lib/libfreetype.so.6' in the result. The compile software can't identify libfreetype.so.6 as a shared library, so, you have to make a symbolic link to the target. Use the command 'ln -s /usr/lib/libfreetype.so.6 /usr/lib/libfreetype.so', when you compile the program again, you will find the error had gone. You can also solve the errors likely. Good Luck!