I built MongoDB C drivers from a tar distro on OSX (Mavericks). Built ok and installed to /usr/local/lib along with libbson. Made links to /usr/lib.
It built libbson-1.0.0.dylib, libbson-1.0.la, libmongoc-1.0.0.dylib, and libmongoc-1.0.la.
Not "*.a" files built tho, for whatever reason, by the makefile.
I added /usr/local/lib to my Eclipse project's lib dir params, and includes to /usr/local/include.
The includes were found during compile but linking failed because symbols from the libbson & libmongoc were not found. I'm winding about the lack of "*.a" files--not sure if Eclipse knows what to do with dylib files.
How can I make Eclipse find the needed libs?
Have you tried to add "-llibbson-1.0.0 -llibbson-1.0 -llibmongoc-1.0" to the linker flags ?
Related
I'm working on a buildroot-based linux for my actual project. I need to add the protobuf-c library and found that the library files, .a and .la, dissapear from the target directory after the "Finalizing target" step in buildroot, since it executes a command to arase all .a and .la files from target/usr/lib and target/lib, so they are empty on the target. Obviously after loading on the target files are still missing.
Can anyone help me on how I can find those files or how can I fix this?
I've tried installing other libraries from the buildroot menuconfig and the same happens, files are installd in /usr/lib directory, but at the end after the "Finalizing target" step they dissapear.
Thanks in advance
Buildroot will typically strip and install the shared libraries which end in .so
The static library ending in .a can be installed by implementing a post install hook in your package makefile. This hook looks like the following for an example package called "pack". In this case the following would be put into the pack.mk makefile :
define PACK_INSTALL_MOD
$(INSTALL) -D -m 755 $(#D)/.libs/libpack.a $(TARGET_DIR)/usr/lib/
endef
PACK_POST_INSTALL_TARGET_HOOKS += PACK_INSTALL_MOD
I have a Windows 7 64bit system with the latest MinGW (32bit) installed along with the Qt 5.5 SDK (again 32bit) which also ships with its own MinGW. Due to the fact that I'm not the only one using the system I can't remove the standalone MinGW.
My project is using qmake and is a plain C project (not C++). Everything builds fine but when I try to execute my binary in the command line I get that the application was unable to start due to a missing libgcc_s_dw2-1.dll on the system.
After looking into the issue I found that both the standalone MinGW and the one shipped alongside the Qt SDK have the mentioned DLL.
Standalone MinGW - libgcc_s_dw2-1.dll is located inside the bin subdirectory of the MinGW installation where the binaries are located (gcc, g++, gdb etc.)
Qt MinGW - libgcc_s_dw2-1.dll is located inside C:\Qt\Tools\mingw492_32\i686-w64-mingw32\lib subdirectory while the MinGW components' binaries are inside C:\Qt\Tools\mingw492_32\i686-w64-mingw32\bin.
I would like to know how to properly set my PATH variable so that:
The application starts properly
No conflicts with the standalone MinGW installation occur
Just a side-note: I've already checked other posts here on SO but was unable to find a solution (perhaps I've missed it). I have also tried LIBS += -static but the result is the same.
You just need to copy this dll with your executable, i.e.:
cp <path-to-qt-install-dir>\qt5.7.0\5.7\mingw53_32\bin\libgcc_s_dw2-1.dll <path-to-dest-dir>
You mat find that you have other dependencies, to see which other deps you have you can use: ldd <your-executable>. You only need to copy the qt specific dlls you can see these by:
ldd <executable> | grep -i qt
note
You can statically link it with:
linker commands like -static-libgcc or -static, but I think you start to hit LGPL issues and also you may need to statically compile qt from source - can't recall for this particular file.
note2
Sorry ldd is for linux, just realized you have windows, in which case you can use one or both of:
dependency walker: from here
<path-to-qt-bin-folder>\windeployqt.exe <path-to-your-executable>
I have mixed results with windeployqt, but if you have any plugins its quiet good for getting that part sorted.
I am working on a school project in a limited environment (archlinux) where I don't have root access. The subject says that I am allowed to use all libraries that are already installed. I am coding in C using gcc.
How to get a list of all those libraries ?
For those libraries managed by the pkg-config utility, the following command will show all installed libraries:
pkg-config --list-all | less
However, not all libraries are so managed so you may be forced to go through the /usr/lib and /usr/local/lib directories.
As noted, not all libraries necessarily use pkg-config. Given that this is ArchLinux, as a fallback you could learn to use the package manager, to list the installed packages. That is called pacman.
Anything that is installed as such on ArchLinux would be part of a package.
The query options can show you all of the files installed for given packages:
To list all files for a given package, use pacman -Qlpackage_name
To list all packages, use pacman -Q
(scripting that, to list all ".so" files which are installed, by package name would be an interesting exercise).
ls /lib /usr/lib /usr/local/lib
Is there anyone that can give me a simple run down of how to install the GSL library so that it'll work with XCode (5.1) on a Mac (Mavericks, 10.9)? I keep getting this error:
Undefined symbols for architecture x86_64:
"_gsl_matrix_add", referenced from:
_myProject in main.o
I initially installed GSL 1.16 in /Library/gsl-1.16
I did the whole ./configure, make, and make install
THINGS I HAVE TRIED TO FIX THIS:
1) Going to "Build Settings" in XCode and adding "/Library/gsl-1.16"
to both the library and header search paths
2) Creating a symbolic link from the ...usr/include path (... being the SDK (MacOSX 10.9) location XCode is using) to the Library path.
3) Adding "-lgsl" to the "Arguments passed on Launch" section of my project's scheme
4) Adding "-Wall -I/Library/include" to the "Arguments passed on Launch" section of my project's scheme
Nothing has worked. Xcode reports that it can find the headers, but it can't reference the methods associated with the header files. Truly interesting. I have no idea, I've done everything I can think of and Google.
From your description it is difficult to locate whether you set the build settings correctly. I installed GSL using macports and not sure how it would be like if installed directly from source. But I believe you need to figure out where the make install installs the GSL library and header to, since typically they are installed into different paths, which are not the path you run make install.
And since typically make install will install headers to /usr/local/include and libraries to /usr/local/lib, I guess it is possible that you set the wrong path to the libraries. Assume you figured out that your GSL library is in /usr/local/lib (and typically they should), you just need to do one of the two things (not both):
Change Library search path to /usr/local/lib. (and header search path to /usr/local/include as you did)
Change compiler arguments to -Wall -I/usr/local/include -L/usr/local/lib. (last two arguments start with capital i and capital L).
Here is the procedure how I install GSL using macports and set up it in Xcode to run a matrix addition:
Install macports if you haven't done it. Refer to https://www.macports.org/install.php .
In terminal, type sudo port install gsl and have several cups of coffee.
By default, macports installs librarys to /opt/local/lib and headers to /opt/local/include. So after you create a C++ project in Xcode, go to build settings, add the three settings below:
Library search paths: /opt/local/lib
Header search paths: /opt/local/include
Other linker flags: -lgsl (depending on what you want to do, you may also need to add -lgsl -lgslcblas and other flags.)
Now it is up and running. Include <gsl/gsl_matrix.h> and gsl_matrix is ready to use.
I'm having strange problems with my cmake cross-compiler projects.
My own libraries are found but not the (system) libraries from my toolchain.
Previously I was using KDevelop on debian squeeze machine.
now on my new machine with debian wheezy the configuring fails.
It does not find the system libraries like m or pthread.
On my old machine the following was working perfectly, but I do not remember that I did something special to make this work.
Here is one of my CMakeLists.txt files
cmake_minimum_required(VERSION 2.8)
SET(CMAKE_SYSTEM_NAME Linux)
SET(CMAKE_SYSTEM_VERSION 2.6.36.4)
SET(CMAKE_C_COMPILER arm-angstrom-linux-gnueabi-gcc)
SET(CMAKE_CXX_COMPILER arm-angstrom-linux-gnueabi-g++)
include_directories(../include
../../../sample/include)
project(testmain)
add_executable(testmain
some_c-source-file.c)
set(CMAKE_LIBRARY_PATH ../lib/arm-26/lib
../../../sample/lib/arm-26/lib)
find_library(LIBS_TEST NAMES akku)
find_library(LIBS_M NAMES m)
find_library(LIBS_PTHREAD NAMES pthread )
target_link_libraries(akkumain
${LIBS_TEST}
${LIBS_M}
${LIBS_PTHREAD})
set(CMAKE_C_FLAGS "-Wall -Werror")
set(CMAKE_C_FLAGS_DEBUG "-g3 -O2 -rdynamic")
set(CMAKE_C_FLAGS_RELEASE "-g0 -O0")
set(CMAKE_CXX_FLAGS "-Wall -Werror")
set(CMAKE_CXX_FLAGS_DEBUG "-g3 -O2 -rdynamic")
set(CMAKE_CXX_FLAGS_RELEASE "-g0 -O0")
This is the message displayed when trying to compile using KDevelop: (to repeat myself: this was working on my old machine)
/home/user/testmain/build> /usr/bin/cmake -DCMAKE_BUILD_TYPE=Debug /home/user/testmain/
-- The C compiler identification is GNU 4.3.3
-- The CXX compiler identification is GNU 4.3.3
-- Check for working C compiler: /usr/local/angstrom/arm/bin/arm-angstrom-linux-gnueabi-gcc
-- Check for working C compiler: /usr/local/angstrom/arm/bin/arm-angstrom-linux-gnueabi-gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/local/angstrom/arm/bin/arm-angstrom-linux-gnueabi-g++
-- Check for working CXX compiler: /usr/local/angstrom/arm/bin/arm-angstrom-linux-gnueabi-g++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
LIBS_M
linked by target "akkumain" in directory /home/user/testmain
LIBS_PTHREAD
linked by target "akkumain" in directory /home/user/testmain
So LIBS_TEST is found. But not libm or libpthread.
I tried this with different projects: All of my libraries are found, but none of the "system" libraries.
I already tried different things like
set(CMAKE_FIND_LIBRARY_PREFIXES lib )
set(CMAKE_FIND_LIBRARY_SUFFIXES .a )
and some more things I do not remember.
The only thing what IS WORKING is when I specify the directory manually:
find_library(ASTLIBS_M NAMES m PATHS /usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/lib)
After specifying this to my CMakeLists.txt the library is found and I can compile my project without any errors.
BUT: This is not what I want, because I have a LOT of projects and many libraries and I don't want to edit all my CMakeLists.txt... :(
Does anybody know what made my old machine find the system-libs without specifying anything special inside my IDE/CMake files?
Edit:
I just noticed for one of my executables that on Linker stage it throws some errors that it cannot find some symbols from glibc - seems there is something more wrong with my debian wheezy system. - I hope I can figure it out...
Edit:
Maybe I should give a short summary: My code compiles well, but all libraries from my toolchain are not found, but if I add the path to the libs of my toolchain manually it compiles but fails on linker stage.
Have you ever tried using a toolchain file? I also cross-compile to ARM and AVR a LOT and it works very well with no hassle (I also use KDevelop and it works beautifully along with CMake). The main point is specifying the path to your toolchain root filesystem through the CMAKE_FIND_ROOT_PATH variable. Try putting all this in a file, which I usually name after the architecture I'm cross-compiling to (in this case I called it arm-unknown-linux-gnueabi.cmake):
# the name of the target operating system
SET(CMAKE_SYSTEM_NAME Linux)
# which C and C++ compiler to use
SET(CMAKE_C_COMPILER arm-unknown-linux-gnueabi-gcc)
SET(CMAKE_CXX_COMPILER arm-unknown-linux-gnueabi-g++)
# here is the target environment located
SET(CMAKE_FIND_ROOT_PATH /home/claudio/TS-7400/rootfs)
# adjust the default behaviour of the FIND_XXX() commands:
# search headers and libraries in the target environment, search
# programs in the host environment
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY BOTH)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE BOTH)
Note the variables CMAKE_FIND_ROOT_PATH_MODE_xxx variables control where CMake will look for binaries, libraries and header files. I usually set PROGRAM to NEVER so it never uses binaries from your cross-architecture root filesystem, since they will not run on your host machine anyway. For libraries and header files BOTH means it will search first your specified ROOT_PATH and then if it doesn't find something it will go through your host machine system dirs.
That way, whenever you want to cross-compile a project all you have to do is to create a build directory (so it doesn't mix your sources with files created during build) and then run cmake from there specifying the toolchain file you want to use (I'm supposing your CMakeLists.txt is together with your toolchain file on the same dir your sources are located - project_sources_dir in my example):
cd project_sources_dir
mkdir build
cd build
cmake -DCMAKE_TOOLCHAIN_FILE=../arm-unknown-linux-gnueabi.cmake ..
The whole point of using a toolchain file is that, if you want to compile the exact same project for your host machine, you don't have to change a single line in your CMakeLists.txt. Just run cmake without specifying the toolchain file:
cd project_sources_dir
mkdir build
cd build
cmake ..
and your project is ready for compiling native for your host machine instead. If all that isn't enough, you can look for more details here on CMake Cross Compiling
There are certain default paths where CMake's find_library module searches. If your system libs on your old machine happen to be located in one such place, they will be found without any additional work needing to be done.
However, as your new machine's path to these libs seems to be "/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/lib", you'll need to tell CMake about this.
One such way, is as you have shown (adding the path explicitly). But in this case, the path is probably specific to just that machine - so you'd be better to only set that path when you invoke CMake on that machine. You can add it to CMAKE_PREFIX_PATH for example:
cmake . -DCMAKE_PREFIX_PATH=/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr
(Note: the path in this case get "lib" appended when find_library is called).
Or if you only want to affect the find_library search paths, and not all find_xxx modules, set CMAKE_LIBRARY_PATH
cmake . -DCMAKE_LIBRARY_PATH=/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/lib