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
Related
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
I am trying to bootstrap GCC during OpenELEC compilation. I need to add libatomic for the target system so as to compile some packages.
When I try to add libatomic for the target system, I get a compilation error with:
/home/mathieu/tmp/OpenELEC.tv/build.OpenELEC-ci20.mips-8.0-devel/toolchain/mipsel-openelec-linux-gnu/bin/ld: cannot find crti.o: No such file or directory
/home/mathieu/tmp/OpenELEC.tv/build.OpenELEC-ci20.mips-8.0-devel/toolchain/mipsel-openelec-linux-gnu/bin/ld: cannot find -lc
/home/mathieu/tmp/OpenELEC.tv/build.OpenELEC-ci20.mips-8.0-devel/toolchain/mipsel-openelec-linux-gnu/bin/ld: cannot find crtn.o: No such file or directory
collect2: error: ld returned 1 exit status
Using the following package.mk file:
https://github.com/malaterre/OpenELEC.tv/blob/fd5a5558104ed38aee1c53bb6d31ba73e8eb6e57/packages/lang/gcc/package.mk
If that matter I am targetting a MIPS system, specifically the Creator CI20:
https://github.com/malaterre/OpenELEC.tv/blob/master/config/arch.mips
I am not clear about the OpenELEC build system, but it seems as if the host compiler and target compiler are build at the same time, while I would need to build binutils in between:
http://preshing.com/20141119/how-to-build-a-gcc-cross-compiler/
You might need to have a GCC built without libatomic to build one with libatomic. The intermediary compiler will serve to build your CRT (if you do not have it already) and libatomic, so that a second compiler can use these "prebuilt" things.
That was not hard at all. Basically one need to create first a minimal gcc (bootstrap) and then build the full one with libatomic:
https://github.com/malaterre/OpenELEC.tv/blob/70dbe25c1647f01eb83c108939c470437a2db259/packages/lang/gcc/package.mk
I'm trying to use make install, and I get error:
cannot find -lcurses
In my /usr/lib/curses/ I have two files: libcurses.so and libcurses.a.
So I do have that library, gcc just doesn't see it. I've read almost everything I can find but still couldn't make this work.
Any help would be appreciated.
This is output:
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: skipping incompatible /usr/lib/libcurses.so when searching for -lcurses
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: cannot find -lcurses
collect2: error: ld returned 1 exit status
Makefile:125: recipe for target 'samtools' failed
make: *** [samtools] Error 1
Note: I've read every similar topic on this website, so please, don't mark this as duplicate.
The linker says:
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: \
skipping incompatible /usr/lib/libcurses.so when searching for -lcurses
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: cannot find -lcurses
You are performing a 64-bit build, but the the only libcurses.so the linker
can find is 32-bit, so it is skipped.
It is unclear from your several postings how this 32-bit /usr/lib/libcurses.so got
there. The official latest openSUSE
curses runtime package is libncurses5-5.9-53.4.x86_64.rpm. The official latest developent package is ncurses-devel-5.9-53.4.x86_64.rpm.
If you install either of these packages, they do not place any 32-bit binaries under /usr/lib, so I surmise
that your /usr/lib/libcurses.so got there in some unorthodox way.
Delete this /usr/lib/libcurses.so. Install the ncurses-devel rpm from your distribution's package manager,
e.g.zypper install ncurses-devel. To make sure you have done it successfully, check that /usr/lib64/libncurses.so exists afterwards.
Then in your makefile change:
LIBCURSES= -lcurses
to:
LIBCURSES= -lncurses
You will find that this change is described in paragraph 3 of the samtools INSTALL file.
You need a development library for ncurses installed, i.e., ncurses-devel (for SuSE).
Without the development library, the shared libraries for ncurses are only present as runtime files.
The ncurses development package installs files or symbolic links to make these options work: -lcurses, -lncurses (since the former is standard). It also installs the file to make -lncursesw link, but OP is not using that.
That message
skipping incompatible /usr/lib/libcurses.so
makes it seem as if OP copied files from some other system rather than installing OpenSuSE packages.
The extra question in SuperUser (GCC ld: can't find -lcurses) gives more information, but not enough to see why the file /usr/lib/libcurses.so is incompatible. It may be conflicting with the development package, however.
I am a novice to cmake and boost so this question might be missing something obvious:
I am building a project with cmake on linux (ubuntu) and I am trying to use boost logging in that project. Here is what I do to generate the Makefile:
rm CMakeCache.txt
cmake ../ -DCMAKE_EXE_LINKER_FLAGS="-lboost_log -lboost_log_setup -lpthread -std=c++11" -DCMAKE_SHARED_LINKER_FLAGS="-lboost_log_setup -lboost_log -lpthread" -DCMAKE_MODULE_LINKER_FLAGS="-lboost_log_setup -lboost_log -lpthread" -DCMAKE_CXX_FLAGS="-DBOOST_LOG_DYN_LINK -std=c++11"
Compile goes through fine. (Some of these flags may be overkill -- I should only need the CMAKE_EXE_LINKER_FLAGS).
When I run the executable, I get the following unresolved reference:
-- ImportError: /home/mranga/gr-msod-sensor/gr-msod_sensor/build/lib/libgnuradio-msod_sensor.so: undefined symbol: _ZN5boost3log11v2_mt_posix3aux25unhandled_exception_countEv
What flags am I missing? My boost library is set up and LD_LIBRARY_PATH points to the right location.
When I manually built a test program using the same linker flags, it compiles and runs fine so boost is installed correctly. I hope I have not missed the obvious.
(Moved question from the GNU Radio mailing list -- sorry if you are reading this post for a second time).
I believe the order of libraries in the linker command line in -DCMAKE_EXE_LINKER_FLAGS is incorrect. boost_log_setup depends on boost_log, so boost_log_setup should go first.
You seem to be linking against the non-multithreaded version:
-lboost_log
but the run-time linker seems to explicitely look for the multithreaded variant (the Boost doc site on that):
_ZN5boost3log11v2_mt_posix3aux25unhandled_exception_countEv
^^
My guess hence is that you should try linking with
-lboost_log_mt
but the question whether that is right or not depends too much on your individual project to make it possible for me to clearly answer this.
I'm on freebsd and trying to run uhd from: http://www.ettus.com/download This should normally run under freebsd, but I encounter problems when I try to build it like specified here:
http://www.ettus.com/uhd_docs/manual/html/build.html#build-instructions-unix
I get:
[ 73%] Building CXX object examples/CMakeFiles/benchmark_rx_rate.dir/benchmark_rx_rate.cpp.o
Linking CXX executable benchmark_rx_rate
../lib/libuhd.so.003.000: undefined reference to `uhd::set_thread_priority(float, bool)'
collect2: ld returned 1 exit status
*** Error code 1
Now this seems to be a linker error, but how to get rid of it? I tried setting the path using ldconfig but this hasn't changed a thing. Maybe some of you have an idea where I could continue searching.
If i get it right, libuhd get's built earlier by this CMake script. If it's true, this error indicates bug in their CMakeLists.txt files.
It looks like you are building examples of using libuhd. I doubt you are need them. So, either look for switches in your CMakeCache.txt and regenerate Makefiles or hack CMakeLists.txt to not include examples dir.
Another thing you may try - set CMAKE_EXE_LINKER_FLAGS to -L/usr/local/include.
This is a perfect situation for creating a FreeBSD port. Since FreeBSD has its own consistent filesystem layout, compiler and linker flags often need to be modified (as noted by arrowdodger) slightly.
The ports system is a framework for persistently capturing those configuration changes and making any software package as easy to install as typing the commands:
cd /usr/ports/category/application-name && make install clean
In a perfect world, you would create the UHD port, submit it for review and addition to the tree. If you need help learning how to do that, the FreeBSD Porter's Handbook and the freebsd-ports mailing list are excellent resources.