I have built some libraries (gtk3, qt5, ...) through the ports collection under FreeBSD 11.2. In order to test them I just built minimal examples. Each time the linker complains about not finding these libraries.
Correct me if I am wrong, but under FreeBSD, regular packages (those which are setup with pkg) are installed under /usr/include and /usr/lib, however ports lie, by default, under /usr/local/include and /usr/local/lib.
Is there a simple way to tell the compiler to search under these directories rather than having huge compilation commands with the -I and -L options?
Thank you for your answers.
Edit
Here is my CMakeLists.txt:
cmake_minimum_required(VERSION 3.12)
project(gtk-test)
set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} "${CMAKE_SOURCE_DIR}/cmake/modules/")
find_package(GTK3 REQUIRED)
include_directories(${GTK3_INCLUDE_DIRS})
link_directories(${GTK3_LIBRARY_DIRS})
add_executable(gtk-test gtk-test.c)
target_link_libraries(gtk-test ${GTK3_LIBRARIES})
I have solved the dependencies issue by grabbing the following CMake script:
https://github.com/eiskaltdcpp/eiskaltdcpp/blob/master/cmake/FindGTK3.cmake
However, another problem has pop up:
[100%] Linking C executable gtk-test
/usr/lib/crt1.o: In function `_start':
crt1.c:(.text+0x91): undefined reference to `main'
collect2: error: ld returned 1 exit status
Edit
I am stupid, I even did not notice that there was no main function in the sample. It works fine except that, by default, CMake cannot locate GTK3 library and its dependencies.
Here is the content of my CMake config scripts:
Qt5
Qt53DQuick
Qt53DRender
Qt5DataVisualization
Qt5Location
Qt5OpenGLExtensions
Qt5QuickTest
Qt5SerialBus
Qt5UiPlugin
Qt5WebKit
Qt5XmlPatterns
Qt53DAnimation
Qt53DQuickAnimation
Qt5Bluetooth
Qt5Designer
Qt5Multimedia
Qt5Positioning
Qt5QuickWidgets
Qt5SerialPort
Qt5UiTools
Qt5WebKitWidgets
assimp-4.1
Qt53DCore
Qt53DQuickExtras
Qt5Charts
Qt5Gamepad
Qt5MultimediaWidgets
Qt5PrintSupport
Qt5Script
Qt5Sql
Qt5WebChannel
Qt5WebSockets
harfbuzz
Qt53DExtras
Qt53DQuickInput
Qt5Concurrent
Qt5Gui
Qt5Network
Qt5Qml
Qt5ScriptTools
Qt5Svg
Qt5WebEngine
Qt5Widgets
libxml2
Qt53DInput
Qt53DQuickRender
Qt5Core
Qt5Help
Qt5Nfc
Qt5Quick
Qt5Scxml
Qt5Test
Qt5WebEngineCore
Qt5X11Extras
Qt53DLogic
Qt53DQuickScene2D
Qt5DBus
Qt5LinguistTools
Qt5OpenGL
Qt5QuickControls2
Qt5Sensors
Qt5TextToSpeech
Qt5WebEngineWidgets
Qt5Xml
Related
I use lapack in an exact diagonalization program.
Using otool -L V3.e I am told that I have linked to the library "/opt/local/lob/lapack/liblapack.3.dylib". In the very same directory is the library "liblapack.3.8.0.dylib". The implication here is that the latter is a new version of lapack and is therefore desirable.
I can't figure out how to link to one over the other. My current compiler flags for linking to this library is:
-0fast -I$(DIR) -L$(DIR) -llapack
Where $(DIR) is the directory shown above.
I don't have admin permission but can easily ask the person in charge of the MacPorts. So if the its possible to remove one of those libraries I can make that happen.
EDIT: In response to Gavin Portwood.
... -L$(DIR) -llapack3.8
For this one all module files compiled well but the linker failed with the following error:
ld: library not found for -llapack3.8
collect2: error: ld returned 1 exit status
make: *** [V3] Error 1
I tried a variant with 3.8.0 at the end instead of 3.8 and got the same result.
... -L$(DIR) -l:liblapack.3.dylib
Slightly confused about this one since I don't want to use the this library. But with this one I was given the same error as above. If I change it to `l:liblapack.3.8.0.dylib' I get the same error.
... -L$(DIR) /opt/local/lob/lapack/liblapack.3.dylib
This last one didn't give me an error but a warning. The warning is as follows:
warning: /opt/local/lib/lapack/liblapack.3.8.0.dylib: linker input file unused because linking not done
Note that I did correct your typo. The program seems to have run correctly but when I ran otool -L <exe> I was linking to liblapack.3.dylib. Also, my compiler is gfortran.
EDIT2: Directory contents /opt/local/lib/lapack/
cmake libcblas.3.dylib liblapacke.3.8.0.dylib
libblas.3.8.0.dylib libcblas.dylib liblapacke.3.dylib
libblas.3.dylib liblapack.3.8.0.dylib liblapacke.dylib
libblas.dylib liblapack.3.dylib pkgconfig
libcblas.3.8.0.dylib liblapack.dylib
EDITFINAL Turns out the directories were soft linked. See Comments on Gavin's answer.
Depending on your compiler and version, link with one of the following:
... -L$(DIR) -llapack3.8.0
... -L$(DIR) -l:liblapack.3.8.0.dylib
... -L$(DIR) /opt/local/lob/lapack/liblapack.3.8.0.dylib
I need to use OpenGL as a library in my project on my Ubuntu 15.04 64bit PC, which is built by CMake 3.0.2. I install packages: mesa-common-dev mesa-utils-extra libgl1-mesa-dev libglu1-mesa-dev libglapi-mesa libx11-dev libxi-dev libxinerama-dev libxcursor-dev libxrandr-dev
After run cmake and Makefile, I got these link error:
/usr/bin/ld: /home/user/CMU462/DrawSVG/asst1_drawsvg/lib/libglfw.a(x11_window.c.o): undefined reference to symbol 'XConvertSelection'
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libX11.so: error adding symbols: DSO missing from command line
I checked /usr/lib/x86_64-linux-gnu/libX11.so, it does exist.
I found a explanation, it seems I failed to link my project with X11 library. The answer says that add -lX11 option may fix this.
Alternatively I link
X11 library in CMakeLists.txt according to FindX11.cmake:
find_package(X11 REQUIRED)
message(STATUS "X11_FOUND = ${X11_FOUND}")
message(STATUS "X11_INCLUDE_DIR = ${X11_INCLUDE_DIR}")
message(STATUS "X11_LIBRARIES = ${X11_LIBRARIES}")
include_directories(${X11_INCLUDE_DIR})
link_directories(${X11_LIBRARIES})
target_link_libraries(MyProj ... ${X11_LIBRARIES})
Run cmake I got these output:
-- X11_FOUND = 1
-- X11_INCLUDE_DIR = /usr/include
-- X11_LIBRARIES = /usr/lib/x86_64-linux-gnu/libX11.so;/usr/lib/x86_64-linux-gnu/libXext.so
But I still got the error aforementioned.
QUESTION: The X11 library can be linked by
using target_link_libraries in CMakeLists.txt, or
adding -lX11 option directly to compiling command
What's the difference between them? Does the link in CMakeLists.txt directly lead to a -lX11 option in Makefile generated?
If so, did I do something wrong in CMakeLists.txt?
UPDATE
Let's take this project as example, following is my build procedure.
Install required libraries: Install the OpenGL and other relative libraries (the GLEW and GLFW library is provided in this project): mesa-common-dev mesa-utils-extra libgl1-mesa-dev libglu1-mesa-dev libglapi-mesa libxi-dev libxinerama-dev libxcursor-dev libxrandr-dev
Run CMake: Then use the provided CMakeLists.txt, everything goes right.
Make: When make the project, this error occurred:
/usr/bin/ld: /home/user/CMU462/DrawSVG/asst1_drawsvg/lib/libglfw.a(x11_window.c.o): undefined reference to symbol 'XConvertSelection'
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libX11.so: error adding symbols: DSO missing from command line
I have searched for many times, all of the answers say that the incorrect link of glfw3 and x11 lead to the error:
missing the -X11 option. However in line 26 of CMakeLists.txt exists this option
the libraries show arranged in order. I check the dependencies with pkg-config --libs command, all libraries are arranged in order in line 17 to 29 of CMakeLists.txt.
The only potential reason for this is the order of the compile options of libraries (line 17 to 29) and the target_link_libraries (line 116) of CMakeLists.txt.
Otherwise, there must be another error omitted by me during my procedure.
I downloaded tar 1.28 and am attempting to compile a static binary to use on system recovery media on Fedora Linux (x86_64). It doesn't have to include common libraries, such as libc or pthreads, but I'd like to eliminate dependencies on selinux, acl, attr, pcre and lzma, etc.
The README indicates I can use
./configure CC=gcc LDFLAGS=-static
but this creates a fully static binary (including libc), but is missing support for anything normally found in the shared libraries (SELinux, ACLs, etc). Reading the config.log shows failed attempts to find a static library for acl
So, I installed libselinux-devel-static RPM, and this time got the selinux support in there, but I can't find static libraries for anything else. Search results say that libacl.a is in libacl-devel, but not mine.
A fully static binary is ok, but really just want to get the odd-balls in there so I don't have to put the shared libraries on the media.
I was looking at this as well, and i would get the following error message:
CCLD tar
../gnu/libgnu.a(quotearg.o): In function `quote':
/home/anarcat/dist/tar-1.27.1/gnu/quotearg.c:968: multiple definition of `quote'
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../../lib/libacl.a(quote.o):(.text+0x0): first defined here
names.o: In function `gid_to_gname':
/home/anarcat/dist/tar-1.27.1/src/names.c:95: warning: Using 'getgrgid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
names.o: In function `gname_to_gid':
/home/anarcat/dist/tar-1.27.1/src/names.c:155: warning: Using 'getgrnam' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
names.o: In function `uname_to_uid':
/home/anarcat/dist/tar-1.27.1/src/names.c:125: warning: Using 'getpwnam' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
names.o: In function `uid_to_uname':
/home/anarcat/dist/tar-1.27.1/src/names.c:65: warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
../lib/libtar.a(rtapelib.o): In function `rmt_open__':
/home/anarcat/dist/tar-1.27.1/lib/rtapelib.c:428: warning: Using 'gethostbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
collect2: error: ld returned 1 exit status
Makefile:1304: recipe for target 'tar' failed
I don't quite get it, but apparently, "You cannot getpwnam and friends with the whole flexibility that glibc has without shared libraries".
So game over? unclear.
For Fedora you can enable Repository CERT Forensics Tools
and complete build dependencies with some static libs (non-exhaustive list)
zlib-static
libiconv-static
libffi-devel
gettext-devel
pcre-static
ncurses-static
nss-devel
glibc-static
libselinux-static
libsepol-static
libattr-devel
libacl-devel
if libacl.a is missing you have to download source first from:
git clone https://git.savannah.nongnu.org/git/attr.git
git clone https://git.savannah.nongnu.org/git/acl.git
and compile with (first libattr, then libacl, then tar):
./autogen.sh
./configure --prefix=/usr --libexecdir=/usr/lib --enable-static --disable-shared --disable-rpath
make CFLAGS='-static'
make install
I have some fortran programs that would not compile in old versions of gfortran. I have to run multiple instances of this program and am using another system (a cluster system) which has centos5_x64 with gcc-4.1 !!
Therefore I had to build new version of gcc; I built both gcc-4.8.3 and gcc-4.9.2 in my home folder. These programs use hdf5 and so the latter also has to be compiled using the same compiler. I tested the fortran programs after removing the hdf5 dependency on both gfortran-4.8.3 and 4.8.9 and they get built and execute properly. I also tested simple C/C++ programs (with basic i/o and arithmetic) with the new gcc/g++(s); they work fine. Before compiling hdf5 libraries I set these environment variables:
PATH=<GCCPATH>:$PATH
LD_LIBRARY_PATH=<GCCLIB>
LD_RUN_PATH=<GCCLIB>
export PATH
export LD_LIBRARY_PATH
export LD_RUN_PATH
HDF5 specific instructions
4.3.7. Specifying other libraries and headers
Configure searches the standard places (those places known by the
systems compiler) for include files and header files. However,
additional directories can be specified by using the CPPFLAGS
and/or LDFLAGS variables:
$ CPPFLAGS=-I/home/robb/include \
LDFLAGS=-L/home/robb/lib \
LDFLAGS=-L<GCCLIB>
CPPFLAGS=-I<GCCINCLUDE>
then configured as:
./configure --prefix=$HOME/HDF5 --enable-fortran
During make I get this error:
/usr/lib/../lib64/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
collect2: error: ld returned 1 exit status
This happens with both versions of gcc but not with the versions installed in the standard location (This happened in another system too which had gcc 4.4 installed). With general searching I got to know that this error is associated with the absence of a main() and in such cases -c flag has to be passed. However all examples of this error were from people's personal scripts and were not for libraries. Please let me know if I am missing something.
Upgrading the system OS is not a choice as of now.
As indicated in the comment by doqtor, I modified the Makefile post configure. It seems that CPPFLAGS and LDFLAGS were not set.
After setting the right CPPFLAGS and LDFLAGS in the Makefile, the compilation happened successfully.
Unfortunately I'm forced to use gcc-4.1 and I'm using debian wheezy. Since gcc-4.1 is not in repository I'm trying to build gcc from sources.
But I'm getting compiling error:
/usr/bin/ld: skipping incompatible /usr/lib/x86_64-linux-gnu/libc.so when searching for -lc
/usr/bin/ld: skipping incompatible /usr/lib/x86_64-linux-gnu/libc.a when searching for -lc
/usr/bin/ld: i386:x86-64 architecture of input file `/usr/lib/x86_64-linux-gnu/crti.o' is incompatible with i386 output
/usr/bin/ld: i386:x86-64 architecture of input file `/usr/lib/x86_64-linux-gnu/crtn.o' is incompatible with i386 output
It looks that ld is picking wrong version of libraries, but I checked my /usr/lib32 and /usr/lib/x86_64-linux-gnu/ and it contains those files:
/usr/lib32/libc.a
/usr/lib32/libc.so
/usr/lib32/crtn.o
/usr/lib32/crti.o
/usr/lib/x86_64-linux-gnu/libc.a
/usr/lib/x86_64-linux-gnu/libc.so
/usr/lib/x86_64-linux-gnu/crtn.o
/usr/lib/x86_64-linux-gnu/crti.o
And ld should have access to them
~$ echo $LIBRARY_PATH
/usr/lib/x86_64-linux-gnu:/usr/lib32/
So I have no idea where the problem is.
I managed to work around the problem.
Run configure with:
./configure --disable-multilib ...
But than I encountered another problem with makeinfo, if you have newer version >=4.10 than it might not be found by configure. So simple fix in generated makefile worked for me:
Change this line:
MAKEINFO = /home/lecopivo/Downloads/gcc412/gcc412/gcc-4.1.2/missing makeinfo
To this:
MAKEINFO = makeinfo
I found this helpful.
LD_LIBRARY_PATH is only for running programs already linked.
You probably need to set LDFLAGS when you configure gcc:
./configure LDFLAGS="-L/usr/lib32" .....
It might be LDFLAGS_FOR_HOST or LIBS or something like that though.
I had this problem recently and finally solved it this way:
ln -s /usr/lib32 /usr/lib/i386-linux-gnu
Notes:
I assumed you do not have /usr/lib/i386-linux-gnu directory in your 64bit linux. If this directory exists and is empty, please delete it and make the above link.
If the directory already exists and is not empty, you have to make links inside it for (32bit) libraries which cause build error one by one; e.g.:
ln -s /usr/lib32/crti.o /usr/lib/i386-linux-gnu/crti.o
ln -s /usr/lib32/crtn.o /usr/lib/i386-linux-gnu/crtn.o
...
If 32bit development libraries are not installed, you may have to install them first. I've searched different forums and found that installing following set of packages in ubuntu will provide them:
libc6-dev libc6-dev-i386
gcc-multilib g++-multilib
zlib1g-dev lib32z1-dev
libncurses5-dev lib32ncurses5-dev libncursesw5-dev lib32ncursesw5-dev
Also adjust LD_LIBRARY_PATH and LIBRARY_PATH variables so that they contain /usr/lib/i386-linux-gnu and /usr/lib/x86_64-linux-gnu (i.e. multiarch lib-dirs). I am not sure which one of above variables is effective, so I adjust both of them the same.
If you use ./configure --disable-multilib as it is frequently suggested on web, though gcc will be built, but when you want to use that gcc for compiling e.g. legacy grub, you probably get error of "gcc cannot build executable" (or such).
Optionally, you can make similar linking for these pair of libdirs:
ln -s /lib32 /lib/i386-linux-gnu
Doing so, I managed to compile gcc-3.4.6 in a Ubuntu 16.04.6-amd64 used for compiling old 32bit programs like SDL 1.2 and legacy GRUB4DOS 0.4.4.
Also take a look at my answer to similar (though opposite) error here.
Good luck.