I have installed ROHC library (http://rohc-lib.org) using following commands during installation:
autoreconf -if
./configure --enable-static=yes --enable-shared=no --disable-shared --prefix=/usr
make
make install
It successfully installed static (and only static) libraries in /usr/lib directory. It contains librohc.a and librohc.la and no shared-library (i.e. librohc.so*).
I am trying to link this library with OpenVPN. I added following lines in configure.ac of OpenVPN:
AC_CHECK_HEADERS(
[rohc/rohc.h rohc/rohc_comp.h rohc/rohc_decomp.h],
,
[AC_MSG_ERROR([ROHC headers not found])]
)
AC_CHECK_LIB(
[rohc],
[rohc_compress4],
,
[AC_MSG_ERROR([ROHC library not found])]
)
But when I run make in OpenVPN source directory, I get the following error:
/bin/sh ../../libtool --tag=CC --mode=link gcc -DPLUGIN_LIBDIR=\"/usr/local/lib/openvpn/plugins\" -Wall -Wno-unused-parameter -Wno-unused-function -g -O2 -std=c99 -lrt -o openvpn argv.o base64.o buffer.o clinat.o comp.o compstub.o comp-lz4.o crypto.o crypto_openssl.o crypto_mbedtls.o dhcp.o error.o event.o fdmisc.o forward.o fragment.o gremlin.o helper.o httpdigest.o lladdr.o init.o interval.o list.o lzo.o manage.o mbuf.o misc.o platform.o console.o console_builtin.o console_systemd.o mroute.o mss.o mstats.o mtcp.o mtu.o mudp.o multi.o ntlm.o occ.o pkcs11.o pkcs11_openssl.o pkcs11_mbedtls.o openvpn.o options.o otime.o packet_id.o perf.o pf.o ping.o plugin.o pool.o proto.o proxy.o ps.o push.o reliable.o route.o schedule.o session_id.o shaper.o sig.o socket.o socks.o ssl.o ssl_openssl.o ssl_mbedtls.o ssl_verify.o ssl_verify_openssl.o ssl_verify_mbedtls.o status.o tls_crypt.o tun.o win32.o rohc.o trunk.o cryptoapi.o ../../src/compat/libcompat.la -lnsl -lresolv -llzo2 -llz4 -lssl -lcrypto -ldl -lrohc
libtool: link: gcc -DPLUGIN_LIBDIR=\"/usr/local/lib/openvpn/plugins\" -Wall -Wno-unused-parameter -Wno-unused-function -g -O2 -std=c99 -o openvpn argv.o base64.o buffer.o clinat.o comp.o compstub.o comp-lz4.o crypto.o crypto_openssl.o crypto_mbedtls.o dhcp.o error.o event.o fdmisc.o forward.o fragment.o gremlin.o helper.o httpdigest.o lladdr.o init.o interval.o list.o lzo.o manage.o mbuf.o misc.o platform.o console.o console_builtin.o console_systemd.o mroute.o mss.o mstats.o mtcp.o mtu.o mudp.o multi.o ntlm.o occ.o pkcs11.o pkcs11_openssl.o pkcs11_mbedtls.o openvpn.o options.o otime.o packet_id.o perf.o pf.o ping.o plugin.o pool.o proto.o proxy.o ps.o push.o reliable.o route.o schedule.o session_id.o shaper.o sig.o socket.o socks.o ssl.o ssl_openssl.o ssl_mbedtls.o ssl_verify.o ssl_verify_openssl.o ssl_verify_mbedtls.o status.o tls_crypt.o tun.o win32.o rohc.o trunk.o cryptoapi.o ../../src/compat/.libs/libcompat.a -lrt -lnsl -lresolv -llzo2 -llz4 -lssl -lcrypto -ldl /usr/lib/librohc.so
gcc: /usr/lib/librohc.so: No such file or directory
Yes, /usr/lib/librohc.so does not exist, but /usr/lib/librohc.a exists. Why is it not linking with the static library /usr/lib/librohc.a at absence of .so ?
You may ask me why I am not installing shared libs of ROHC; answer is that I want to force static linking with ROHC, and when it is done I will uninstall ROHC libs.
If someone could show me how to do this static linking without installing ROHC first (like adding dependency to configure.ac or Makefile.am of OpenVPN), it would be better for me.
Note that, both OpenVPN and ROHC library require autotools.
I specified --libdir=/usr/lib64 with ./configure of ROHC library and finally the build system used the static library librohc.a when linking with OpenVPN. I installed ROHC with:
autoreconf -if
./configure --enable-static --disable-shared --prefix=/usr --libdir=/usr/lib64
make
make install
Now it installs the library as /usr/lib64/librohc.a and Compilation of OpenVPN successfully finds and links to it.
And surely, it took place in a 64 bit machine (CentOS 6). In a 32 bit environment (OpenWrt in a 32-bit MIPS router) where there is nothing like /usr/lib64, the problem in the question does not take place.
Related
I am trying to build freetype and harfbuzz. The latter depends on the former. Freetype builds with CMake, which I configured to install it in /opt/ossia-sdk.
I tried this as mentioned in Meson: how to make find_library() works with an unusual path? :
export LIBRARY_PATH=/opt/ossia-sdk/freetype
# also tried:
# export LIBRARY_PATH=/opt/ossia-sdk/freetype/lib
meson build -Dbuildtype=release -Ddefault_library=static -Dglib=disabled -Dgobject=disabled -Dicu=disabled -Ddocs=disabled -Dprefix=/opt/ossia-sdk/harfbuzz
Yet it still gets my system freetype, which I do not want.
meson-log.txt has the following:
libraries: =/opt/ossia-sdk/freetype/x86_64-pc-linux-gnu/11.1.0/:/opt/ossia-sdk/freetype/../lib/:/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/:/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../x86_64-pc-linux-gnu/lib/x86_64-pc-linux-gnu/11.1.0/:/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../x86_64-pc-linux-gnu/lib/../lib/:/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../x86_64-pc-linux-gnu/11.1.0/:/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../lib/:/lib/x86_64-pc-linux-gnu/11.1.0/:/lib/../lib/:/usr/lib/x86_64-pc-linux-gnu/11.1.0/:/usr/lib/../lib/:/opt/ossia-sdk/freetype/:/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../x86_64-pc-linux-gnu/lib/:/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../:/lib/:/usr/lib/
Build lines look like:
Command line: c++ -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/harfbuzz -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/sysprof-4 /home/jcelerier/ossia/sdk/Linux/harfbuzz/build/meson-private/tmps978npqc/testfile.cpp -o /home/jcelerier/ossia/sdk/Linux/harfbuzz/build/meson-private/tmps978npqc/output.exe -pthread -O3 -march=x86-64 -mtune=generic -D_FILE_OFFSET_BITS=64 -O0 -fpermissive -std=c++11 -fno-rtti -Wl,--start-group /usr/lib/libfreetype.so -Wl,--end-group
Any solution must not patch Freetype or harfbuzz's build scripts, I can only call them.
Problem
I'm trying to build and run a vulkan + glfw program with g++ on Windows. I installed gcc, glfw3, and vulkan using msys2's pacman.
When my program calls glfwCreateWindowSurface(instance, window, nullptr, &surface); it returns with VK_ERROR_EXTENSION_NOT_PRESENT.
What I did
Install msys2 and use pacman to install:
mingw-w64-x86_64-glfw
mingw-w64-x86_64-vulkan-headers
mingw-w64-x86_64-vulkan-loader
mingw-w64-x86_64-vulkan-validation-layers
Download part 5 of the vulkan-tutorial.com tutorial and build it using:
g++ -std=c++17 -O2 -g -c 05_window_surface.cpp -o main.o -lglfw3 -lvulkan
g++ -std=c++17 -O2 -g main.o -o main -lglfw3 -lvulkan
Following the tutorial's setup for Visual Studio works flawlessly however I would prefer to use a different development enviroment.
After looking into it more and finding this github issue: https://github.com/glfw/glfw/issues/1810, I have fixed my problem by changing my -lvulkan flag to -L/path/to/VulkanSDK/1.2.176.1/Lib -l:vulkan-1.lib
I'm building a shared library and an application using that lib on Cygwin. With GCC CMake creates a .dll.a to use when linking. Switching to clang I get
[ 34%] Built target xxx_shared
make[2]: *** No rule to make target 'src/libxxx.dll.a', needed by 'xxx.exe'. Stop.
Is this a bug in the clang CMake extension?
I'm using cmake --version 3.3.2
Yes, it seems to be a bug in CMake. Running make VERBOSE=1 reveals that with GCC:
/usr/bin/c++.exe -g -shared -Wl,--enable-auto-import -o XXX -Wl,-Bstatic -lm -Wl,-Bdynamic -lstdc++ -lcygwin -ladvapi32 -lshell32 -luser32 -lkernel32
while with clang:
/usr/bin/clang++ -fPIC -g -shared -o XXX -Wl,-Bstatic -lm -Wl,-Bdynamic -lstdc++ -lcygwin -ladvapi32 -lshell32 -luser32 -lkernel32
So it seems that somehow clang++ does not get the -Wl,--enable-auto-import flag. Manually running the corrected clang++ command correctly creates the expected .dll.a allowing the rest of the build to proceed as expected.
Haven't figured out why this happens yet, though. At this point I can't decipher CMakes platform extensions, which seems to set this for GCC.
Update: I've reported this here.
I'm building an SDL2/C++ program that needs to be portable to Windows, Mac, and Linux machines which may not have SDL installed.
I've read that static linking is the solution, but I'm not very good with compiling and don't know how to static link.
My program relies only on SDL2, GLU, and OpenGL. I'm compiling C++ with either MinGW (on Windows 8.1) or gcc (on Ubuntu 14.04) -- both of these OS's have SDL installed natively.
Here is my current makefile, derived from a sample makefile given to me by a professor of mine:
# Executable/file name
EXE=experiment
# MinGW
ifeq "$(OS)" "Windows_NT"
CFLG=-O3 -Wall -DUSEGLEW
LIBS= -lSDL2 -lglu32 -lopengl32
CLEAN=del *.exe *.o *.a
else
# OSX
ifeq "$(shell uname)" "Darwin"
CFLG=-O3 -Wall -Wno-deprecated-declarations
LIBS=-framework SDL2 -framework OpenGL
# Linux\Unix\Solaris
else
CFLG=-O3 -Wall
LIBS= `sdl2-config --cflags --libs` -lGLU -lGL -lm
endif
# OSX\Linux\Unix\Solaris
CLEAN=rm -f $(EXE) *.o *.a
endif
# Dependencies
$(EXE).o: $(EXE).cpp FORCE
.c.o:
gcc -c -o $# $(CFLG) $<
.cpp.o:
g++ -std=c++11 -c -o $# $(CFLG) $<
# Link
$(EXE):$(EXE).o
g++ -std=c++11 -O3 -o $# $^ $(LIBS)
# Clean
clean:
$(CLEAN)
# Force
FORCE:
To link with static library you either specify path to library file
gcc -o out_bin your_object_files.o path/to/lib.a -lfoo
or ask linker to use static version with -Bstatic linker flag. Usually you'll want to reset linking back to dynamic for the rest of the libraries, e.g. for static SDL2 and GLU but dynamic GL:
gcc -o out_bin your_object_files -Wl,-Bstatic -lSDL2 -lGLU -Wl,-Bdynamic -lGL
That of course implies that static versions of libraries are present in library search path list (.a libs for gcc on all specified platforms, although MSVC uses .lib for static libraries).
However you usually don't really want to do that at all. It is common practice for software to either depend on some libs (widespread on linux, with packages and dependendices lists) or bring required libraries with it. You can just distribute SDL dynamic library with your program and load it with LD_LIBRARY_PATH or relative rpath.
Please also note that newer SDL2 implements dynamic loading of functions which provides a way to override SDL with user-specified dynamic library, even if linked statically.
It wasn't related directly to static linking. When static linking, I had to include all of SDL's dependency libraries. Turns out, having -mwindows causes console communication to fail.
I have a GNU build system with autoconf-2.69, automake-1.14.1, libtool-2.4.2. I've configured with --host=i686-linux on a x86_64 RHEL6 host OS to build a 32-bit program. The libtool command seems to be:
/bin/sh ../libtool --tag=CXX --mode=link g++ -I/home/STools/RLX/boost/include/boost-1_44 -m32 -g3 -Wall -static -o engine engine-main.o ../components/librlxvm.la /home/STools/RLX/boost/include/boost-1_44/../../lib/libboost_program_options-gcc42-mt-1_44.a -lz -lpthread -ldl -lrt -ldl -lz -lm
But the real command is to search the 64-bit libraries not the 32-bit libraries as shown below:
libtool: link: g++ -I/home/STools/RLX/boost/include/boost-1_44 -m32 -g3 -Wall -o engine engine-main.o -L/home/robert_bu/src/gcc/gcc-4.2.2/build-x86_64/x86_64-unknown-linux-gnu/libstdc++-v3/src -L/home/robert_bu/src/gcc/gcc-4.2.2/build-x86_64/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/home/robert_bu/src/gcc/gcc-4.2.2/build-x86_64/./gcc ../components/.libs/librlxvm.a /home/STools/RLX/boost/include/boost-1_44/../../lib/libboost_program_options-gcc42-mt-1_44.a /home/STools/RLX/gcc-4.2.2-x86_64/lib/../lib64/libstdc++.so -L/lib/../lib64 -L/usr/lib/../lib64 -lc -lgcc_s -lrt -ldl -lz -lm -pthread -Wl,-rpath -Wl,/home/STools/RLX/gcc-4.2.2-x86_64/lib/../lib64 -Wl,-rpath -Wl,/home/STools/RLX/gcc-4.2.2-x86_64/lib/../lib64
The --host config seems to have no effect. Is there anyway to tell libtool that 32-bit libraries are what we want?
It seems that libtool uses "CC", "CXX" to check the library search path. After I set CC to "gcc -m32", and CXX to "g++ -m32", it works. So libtool does not add "-m32" automatically even if I try to build a 32-bit program on a 64-bit system.
You're being hit by the problem of libtool .la files expansion. In particular libstdc++.la is being expanded for you to a full path rather than a simple -lstdc++.
My suggestion is to remove .la file from the SDK you're using (/home/STools). This way libtool can't assume things for you. Usually the ones you have in the system are fine, because the libraries are already in the search path, so it does not need to use -rpath or the full path to the .so file.
Depending on how well the SDK was crafted, this might or might not work correctly, so take it with a grain of salt.