I've installed the Nana library and I've read from their website that the library needs some shared libraries to work.. So during linking (gcc) i need to put all links (-lXft, -l...).
Is there a solution to auto link shared libraries needed by Nana?
I am using ubuntu 18.04 and I've read that I can do that with Makefile but I haven't understood how.. I want to use Premake to organize my project so that I can say to Premake that it needs to include the Nana library and then Premake "smartly" find all shared libraries..
When I used Premake and I linked the Nana library (statically) the compiler gaves me a lot of errors...
all the errors say:
undefined reference to: X...
So I need to include all the shared libraries that Nana needs, but how?
gcc has no idea about inter-library dependencies. You need a build system (which would use gcc as the compiler) for that.
Now, the Nana library uses the CMake build system. Thus a good solution to the problem should be to get the authors of Nana to properly export the library's CMake targets, and distribute a .cmake file which you can then import if you also build with CMake.
Alternatively - perhaps such a CMake file already exists somewhere (I haven't been able to quickly find it though).
I would ask about this in the Nana forums.
Related
I would like to
build a binary that is relying on a shared library at runtime.
the library does not exist while compiling the binary.
the headers for the library are available
I would like to create a CMake project under those circumstances. Therefore I tried the following, but it will complain about the missing lib for sure:
cmake_minimum_required (VERSION 3.8)
project (example)
add_executable(${PROJECT_NAME}
main.c
)
target_link_libraries(${PROJECT_NAME}
PRIVATE
# system libs
lib_that_does_not_yet_exist
)
When removing the link instruction to lib_that_does_not_yet_exist, then I will get a undefined reference error.
Question: Is there any way to accomplish what I need?
Background: I am crosscompiling the binary, the lib is therefore having the wrong architecture to install it on the host. I know there may be some ways around that issue, but I am mainly interested in the above question.
I followed many tutorials to get boost installed, firstyly I downloaded boost and added path with:
path=%path%;
c:\program files (x86)\code block\mingw\bin
secondly I ran
bootstrap.bat gcc
and then
b2 toolset=gcc
but there is no such lib installed as UUID which I really need to my project. Is there any way to make it happen as I haven't found any specific help among all those topics and I'm getting really confused. I'm working on win10 if that makes any difference.
Did you read documentation?
Boost UUID library is header-only library. See Configuration:
The library does not require building or any special configuration to be used.
So you have to download boost library and unpack it to some place in your disk (for example to c:\boost). Path to boost library will be c:\boost\boost_1_62_0. Then you have to specify the compiler the place where the boost library is located. It is compiler or IDE specific way. But the common way is to use "Additional Include Directories" option of compiler. It is -I for GCC and /I for MS VC++. Last step is to write include directive in your c++ code. For example:
#include <boost/uuid/uuid.hpp>
For code example see Example and files in boost/libs/uuid/test/ folder
I am writing a Go wrapper for a C library in Go. The problem is, that the C library is not available on many Linux distributions, so I want a solution where i "go get github.com/me/mylibrary" does not require anybody to have the library installed.
One solution would be to just add the source of the library into a sub directory. Then when my project is build with go get I need to automatically build this library, too. But I have no idea how I can automate this.
Alternatively I could have a script that downloads the source, extracts and builds it
But I have no Idea how to connect these build steps with the go build tool.
linking a static library is also not the easiest.
#cgo linux LDFLAGS: ./MyLib/lib/libMyLib.a -lstdc++ -lm -lX11
works as long as i build from my library, but as soon as I want to build from another project the relative path is from that project and not from my library, so it fails.
As per http://golang.org/cmd/cgo/#hdr-Using_cgo_with_the_go_command
When the Go tool sees that one or more Go files use the special import
"C", it will look for other non-Go files in the directory and compile
them as part of the Go package. Any .c, .s, or .S files will be
compiled with the C compiler. Any .cc, .cpp, or .cxx files will be
compiled with the C++ compiler.
So you can include the C library source in your repository and go will build it automatically. That page also explains how to pass build flags to the compilers and probably anything else you might need to know.
[Shamelessly cross-posted from the CMake help list]
I'm trying to create binaries as statically as possible. The fortran code I've got has got X11 and quadmath as dependencies, and I've come across a number of issues (maybe each of these issues should be in a different question?):
My variables are currently
set(CMAKE_LIBRARY_PATH /usr/X11/lib /usr/X11/include/X11 ${CMAKE_LIBRARY_PATH})
find_package(X11 REQUIRED)
find_library(X11 NAMES X11.a PATHS /usr/X11/include/X11/ /usr/X11/lib)
find_library(X11_Xaw_LIB NAMES Xaw Xaw /usr/X11/include/X11/ /usr/X11/lib ${X11_LIB_SEARCH_PATH})
find_library(Xaw Xaw7 PATHS ${X11_LIB_SEARCH_PATH})
set(CMAKE_LIBRARY_PATH /usr/lib/gcc/x86_64-linux-gnu/4.7 /usr/lib/gcc/x86_64-linux-gnu/4.7/x32 /usr/lib/gcc/x86_64-linux-gnu/4.7/32 ${CMAKE_LIBRARY_PATH})
find_library(quadmath NAMES quadmath.a)
set(BUILD_SHARED_LIBS ON)
set(CMAKE_FIND_LIBRARY_SUFFIXES .a ${CMAKE_FIND_LIBRARY_SUFFIXES})
set(LINK_SEARCH_START_STATIC TRUE)
set(LINK_SEARCH_END_STATIC TRUE)
set(SHARED_LIBS OFF)
set(STATIC_LIBS ON)
set(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -static")
Using these, CMake attempts to build every program statically (as expected) - however, it fails because I don't have Xaw.a - I can't find out whether this actually should exist. I have installed the latest libxaw7-dev which I was expecting to fix it. One option would be to compile the X11 libraries myself, but I don't really want to do that...
if I comment out only set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -static"), then CMake compiles everything, but uses shared libraries for every program, even though I specify the location of .a X11 libraries in my find_library() calls. I was expecting CMake to use the .a files where it could and then only use shared libraries - is there a way to force this behaviour?
does anyone know yet of a fix for the bug described here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46539; whereby gfortran seemingly can't statically link libquadmath? I tried the fix using gcc but I can't get CMake to recognise the libgfortran flag:
cmake -DCMAKE_Fortran_COMPILER=gcc -DCMAKE_Fortran_FLAGS=-gfortran
results in
-- The Fortran compiler identification is unknown
-- Check for working Fortran compiler: /usr/bin/gcc
-- Check for working Fortran compiler: /usr/bin/gcc -- broken
CMake Error at /usr/share/cmake-2.8/Modules/CMakeTestFortranCompiler.cmake:54 (message):
The Fortran compiler "/usr/bin/gcc" is not able to compile a simple test program.
However, as you might have noticed, I set the location of the libquadmath.a; when I build a program which doesn't use X11 but does use quadmath when I use
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -static")
then the program does compile successfully (running ldd reports 'not a dynamic executable') - does this mean that the bug has been fixed, or does it only work because I set the location in CMake?
I was having a similar problem. Turns out that cmake was implicitly linking against libgfortran and libquadmath. To fix this I put the following in my top level CMakeLists.txt:
unset(CMAKE_Fortran_IMPLICIT_LINK_LIBRARIES)
I could then explicitly link again the libraries using:
SET_TARGET_PROPERTIES(main_f PROPERTIES LINKER_LANGUAGE "C"
LINK_FLAGS
"/usr/local/Cellar/gcc/7.1.0/lib/gcc/7/libgfortran.a
/usr/local/Cellar/gcc/7.1.0/lib/gcc/7/libquadmath.a -lm -lgcc"
)
The static version of libgfortran is necessary because the shared library also depends on libquadmath. The added "-lm" and "-lgcc" bring in the system dynamic versions of these libraries. On a mac system, you would want to use the full path to your libm.a as well.
I guess your questions are not that much related, I don't know the answer for all of them.
For your static linking problems, since you're using GCC, you can pass multiple -static and -dynamic flags to it:
set(CMAKE_EXE_LINKER_FLAGS "-static ${STATIC_LIBS} -dynamic ${EVERYTHING ELSE} -static ${MORE_STATIC_LIBS}")
I don't know why Xaw.a isn't available on your system, probably because the package maintainer of your Linux distribution didn't really make them available.
Also, compiling everything static might make things not compatible between all distros out there and you cripple the ability for others to use improved, up-to-date libraries with your program, it might not be what you want.
If you intend to make a self-contained package of your program, it might be better just to include the shared libraries you used together, like Dropbox and many other proprietary applications do (Humble Bundle games are other example).
I am able to build the shared object successfully using the holy native compiler "xlc" on AIX.It does build the shared object library but does not install the shared object library.
Configure command is:
./configure --prefix=/PATH/to/install --exec-prefix=/PATH/to/install --enable-shared --enable-static=no --enable-module=so --build=powerpc-ibm-aix5.3.0.0 --host=powerpc-ibm-aix5.3.0.0 LDFLAGS="-G -shared"
Any help would be appreciated?
So you are trying to compile to the shared library location.
I would suggest seeing if you can compile/link to your local directory.
If that works, try copying the new library to the correct directory. It may be that the oldshared library is open by some process and therefore can't be overwritten.
Are you getting any error messages?
I could install the shared library successfully when i had to exclusively export LDFLAGS as "-brtl -L/path/to/install".
Under AIX, there are two types of shared libraries, AIX style, and SysV compat libs.
AIX style libs are archvies that can contain static libraries as well as multiple versions of shared libraries, and have names like libFOO.a
SysV-compat libs have names like libFoo.so and are more like what you would find on Linux.
Libtool will build either type. If you want SysV-compat libs, add -Wl,-brtl to LDFLAGS.
My guess is that you see /PATH/to/install/lib/libFOO.a and are assuming that it's a static library, when in fact, it's an AIX shared library.