I'm creating a library libgdata that has some tests and non-installed programs. I am running into the problem that once I've installed the library once, the programs seem to be linking to the installed version and not the local version in ../src/libgdata.la any longer.
What could cause this? Am I doing something horribly wrong?
Here is what my test/Makefile.am looks like:
INCLUDES = -I$(top_srcdir)/src/ -I$(top_srcdir)/test/
# libapiutil contains all of our dependencies!
AM_CXXFLAGS = $(APIUTIL_CFLAGS)
AM_LDFLAGS = $(APIUTIL_LIBS)
LDADD = $(top_builddir)/src/libgdata.la
noinst_PROGRAMS = gdatacalendar gdatayoutube
gdatacalendar_SOURCES = gdatacalendar.cc
gdatayoutube_SOURCES = gdatayoutube.cc
TESTS = check_bare
check_PROGRAMS = $(TESTS)
check_bare_SOURCES = check_bare.cc
(libapiutil is another library that has some helper stuff for dealing with libcurl and libxml++)
So, for instance, if I run the tests without having installed anything, everything works fine. I can make changes locally and they are picked up by these programs right away.
If I install the package, these programs will compile (it seems like it does actually look locally for the headers), but once I run the program it complains about missing symbols.
As far as I can tell, it is linking against the newly built library (../src/libgdata.la) based on the make output, so I'm not sure why this would be happening. If i remove the installed files, the local changes to src/* are picked up just fine.
I've included the make output for gdatacalendar below.
g++ -DHAVE_CONFIG_H -I. -I.. -I../src/ -I../test/ -I/home/altern8/workspaces/4355/dev-install/include -I/usr/include/libxml++-2.6 -I/usr/lib/libxml++-2.6/include -I/usr/include/libxml2 -I/usr/include/glibmm-2.4 -I/usr/lib/glibmm-2.4/include -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -g -O2 -MT gdatacalendar.o -MD -MP -MF .deps/gdatacalendar.Tpo -c -o gdatacalendar.o gdatacalendar.cc
mv -f .deps/gdatacalendar.Tpo .deps/gdatacalendar.Po
/bin/bash ../libtool --tag=CXX --mode=link g++ -I/home/altern8/workspaces/4355/dev-install/include -I/usr/include/libxml++-2.6 -I/usr/lib/libxml++-2.6/include -I/usr/include/libxml2 -I/usr/include/glibmm-2.4 -I/usr/lib/glibmm-2.4/include -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -g -O2 -L/home/altern8/workspaces/4355/dev-install/lib -lapiutil -lcurl -lgssapi_krb5 -lxml++-2.6 -lxml2 -lglibmm-2.4 -lgobject-2.0 -lsigc-2.0 -lglib-2.0 -o gdatacalendar gdatacalendar.o ../src/libgdata.la
mkdir .libs
g++ -I/home/altern8/workspaces/4355/dev-install/include -I/usr/include/libxml++-2.6 -I/usr/lib/libxml++-2.6/include -I/usr/include/libxml2 -I/usr/include/glibmm-2.4 -I/usr/lib/glibmm-2.4/include -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -g -O2 -o .libs/gdatacalendar gdatacalendar.o -L/home/altern8/workspaces/4355/dev-install/lib /home/altern8/workspaces/4355/dev-install/lib/libapiutil.so /usr/lib/libcurl.so -lgssapi_krb5 /usr/lib/libxml++-2.6.so /usr/lib/libxml2.so /usr/lib/libglibmm-2.4.so /usr/lib/libgobject-2.0.so /usr/lib/libsigc-2.0.so /usr/lib/libglib-2.0.so ../src/.libs/libgdata.so -Wl,--rpath -Wl,/home/altern8/workspaces/4355/dev-install/lib
creating gdatacalendar
Help. :)
UPDATE
I get the following messages when I try to run the calendar program when I've added the addCommonRequestHeader() method to the Service class after I had installed the library without the addCommonRequestHeader() method.
/home/altern8/workspaces/4355/libgdata/test/.libs/lt-gdatacalendar:
symbol lookup error:
/home/altern8/workspaces/4355/libgdata/test/.libs/lt-gdatacalendar:
undefined symbol:
_ZN55gdata7service7Service22addCommonRequestHeaderERKSsS4_
Eugene's suggestion to try setting the $LD_LIBRARY_PATH variable did not help.
UPDATE 2
I did two tests. First, I did this after blowing away my dev-install directory (--prefix) and in that case, it creates test/.libs/lt-gdatacalendar. Once I have installed the library, though, it creates test/.libs/gdatacalendar instead. The output of ldd is the same for both with one exception:
# before install
# ldd test/.libs/lt-gdatacalendar
libgdata.so.0 => /home/altern8/workspaces/4355/libgdata/src/.libs/libgdata.so.0 (0xb7c32000)
# after install
# ldd test/.libs/gdatacalendar
libgdata.so.0 => /home/altern8/workspaces/4355/dev-install/lib/libgdata.so.0 (0xb7c87000)
What would cause this to create lt-gdatacalendar in one case but gdatacalendar in another?
The output of ldd on libgdata is:
altern8#goldfrapp:~/workspaces/4355/libgdata$ ldd /home/altern8/workspaces/4355/libgdata/src/.libs/libgdata.so.0
linux-gate.so.1 => (0xb7f7c000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7f3b000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7dec000)
/lib/ld-linux.so.2 (0xb7f7d000)
I think I've sorted this out.
The problem should be that libtool sees the "-L" flag in the command line before it sees the "../src/libgdata.so" part. In this case, it executes the linker with "-Wl,-rpath,..." for that "-L" path. If that path contains "libgdata.so", then it will always be used, which is the case here.
In my case, I've rearranged "prog_LDADD" to like like this:
"prog_LDADD = $(top_builddir)/src/my_lib.so $(DEPENDENCY_LIBS)"
In your case, try to delete AM_LDFLAGS and write:
LDADD = $(top_builddir)/src/libgdata.la $(APIUTIL_LIBS)
Not sure how to do that in autoconf, but final command might need to have -L../src, so linker can find newly built library first.
Try manually running last command with that addition and see if that helps.
EDIT: Ok, I guess misread it, thought it wasn't linking, but you are saying it links but doesn't run?
If that is the case, run ldd on your binary and see which .so it picks up -- most likely installed (and outdated) ones.
In this case, either install updated libs before running, or export LD_LIBRARY_PATH env variable before running.
export LD_LIBRARY_PATH="/path to freshly built libs"
I know that for dependencies to work correctly, you need to refer to libgdata.la with a relative path in LDADD; it's possible that affects the situation you're describing as well.
I'm not sure why, though. The behavior you're describing does seem a bit odd; and perhaps worth reporting to the libtool developers.
Without -no-install libtool creates script wrappers and puts the executables into the .libs/ subdir (linked with the installed libraries). Calling the wrapper makes your executable load/link with your local (not installed) library - so everything works fine, e.g. make check does not test the installed but your freshly baken library.
In some cases (e.g. when debugging or valgrinding), you do not want to have those wrappers, but real executables directly linked with your local library. For this you use AM_LDFLAGS = -no-install (or just set it for single targets).
More details here
Related
I want to fuzz the map loading feature in counter strike. The source code for csgo got leaked a while back and here is a build which you can compile https://github.com/SwagSoftware/Kisak-Strike . However, when I try to compile it using this command:
AFL_USE_ASAN=1 PERSIST=1 cmake -DCMAKE_BUILD_TYPE=Debug -DUSE_ROCKETUI=ON -DFREETYPE_LIBRARY=/usr/lib/x86_64-linux-gnu/libfreetype.so -DFREETYPE_INCLUDE_DIRS=/usr/include/freetype2/freetype/ -DUSE_KISAK_PHYSICS=ON -DCMAKE_C_COMPILER=/home/cyberhacker/Asioita/Hakkerointi/Counterstrikestuff/aflpp/afl-gcc-fastthing/AFLplusplus/afl-gcc-fast -DCMAKE_CXX_COMPILER=/home/cyberhacker/Asioita/Hakkerointi/Counterstrikestuff/aflpp/afl-gcc-fastthing/AFLplusplus/afl-g++-fast ..
and then when i try to run ./csgo_linux64 , it throws this error:
Failed to load the launcher(bin/linux64/launcher_client.so) (/home/cyberhacker/Asioita/Csgocompile/withjump/game/bin/linux64/libtier0_client.so: undefined symbol: __afl_area_ptr)
I am expecting it to just work as usual (same as with the regular build). It works completely fine when I try to compile it normally with this command:
cmake -DCMAKE_BUILD_TYPE=Debug -DUSE_ROCKETUI=ON -DFREETYPE_LIBRARY=/usr/lib/x86_64-linux-gnu/libfreetype.so -DFREETYPE_INCLUDE_DIRS=/usr/include/freetype2/freetype/ -DUSE_KISAK_PHYSICS=ON -DCMAKE_C_COMPILER=/usr/bin/cc -DCMAKE_CXX_COMPILER=/usr/bin/c++ ..
and then make -j8
I searched a bit and found this: this . In that conversation they say that this error can be cause by compiling with afl-gcc but then linking with normal gcc or ld. However this is not the cause of my problem since I have looked through the cmake log files and the binaries are being linked with afl-g++-fast so this shouldn't be a problem in my case. I read somewhere that the libraries should be statically included, not dynamic but I do not think that it is a necessity. Feel free to look at the Kisak strike source code if you want to (obviously).
I am facing the Make77 problem. Can somebody help me out?
mingw32-make
gcc -Iinclude/ -Isrc/ -Wall -Wno-unused-result -Wno-unknown-pragmas -Wfatal-errors -fPIC -Ofast obj/captcha.o obj/lsd.o obj/super.o obj/art.o obj/tag.o obj/cifar.o obj/go.o obj/rnn.o obj/segmenter.o obj/regressor.o obj/classifier.o obj/coco.o obj/yolo.o obj/detector.o obj/nightmare.o obj/instance-segmenter.o obj/darknet.o libdarknet.a -o darknet -lm -pthread libdarknet.a
c:/mingw/bin/../lib/gcc/mingw32/9.2.0/../../../../mingw32/bin/ld.exe: obj/go.o:go.c:(.text+0x329f): undefined reference to `__WSAFDIsSet#8'
c:/mingw/bin/../lib/gcc/mingw32/9.2.0/../../../../mingw32/bin/ld.exe: obj/go.o:go.c:(.text+0x32e1): undefined reference to `select#20'
collect2.exe: error: ld returned 1 exit status
Makefile:77: recipe for target 'darknet' failed
mingw32-make: *** [darknet] Error 1
I was in your shoes a few weeks ago and managed to fix that.
I am confident, you are trying to compile the original repository of Darknet on a Windows machine.
Cause
Unfortunately, one of the libraries used in go.c is *nix-only. It has a counterpart in Windows called winsock.h, but apparently it is not enough and the problem still persists.
Solution
Instead what you should do is use another repo of Darknet which is ported to Windows properly and has a lot of support. It has exactly the same functionality as the original repo except for very little changes which only makes the framework better. Instead of compiling with make command, you should build it with Microsoft Visual Studio. You may go with the latest version of MVS. If you want to use a GPU and install correctly, make sure you follow the instructions here https://github.com/AlexeyAB/darknet#requirements . To avoid any weird errors, install the requirements in order.
When all requirements are installed, navigate to build/darknet and open darknet.sln. Switch to Release and x64 and build the project.
That should be it. If you have any issues, let me know so I can help you. Also, if this solution works for you, make sure to mark my reply as the best answer.
I have been able to install and start a program with CMake (with HDF5) but once I access the "about" drop-down link for said program it crashes with the following error:
python: symbol lookup error: /nobackup/<user id>/program-devel/dist_linux/bin_linux/libprogramDLL.so: undefined symbol: h5lib_MP_h5get_libversion_f_
I believe it is an issue with linking static libraries but I am, unfortunately, quite new to CMake and unable to isolate the root problem. I know that this "symbol" is tied somehow to a libhdf5_fortran.a and this is listed in my Cache with:
$ grep -rnw '/nobackup/<user id>/program-devel/build' -e "libhdf5_fortran"
/nobackup/<user id>/program-devel/build/CMakeCache.txt:234:ToolkitLib_LIB_DEPENDS:STATIC=general;SomeLib;general;libz.a;general;libhdf5.a;general;libhdf5_fortran.a;
I’m not sure if this might be where the problem is or not but this is from the ToolKit file - CMakeLists.txt.
if (${USE_HDF5})
#link_directories (${HDF5_DIRECTORY}/lib)
if (WIN32)
target_link_libraries(ToolkitLib libszip libzlib libhdf5 libhdf5_f90cstub libhdf5_fortran)
else ()
# doesn't seem to work on Linux for some reason....
#target_link_libraries(ToolkitLib libsz libz libhdf5 libhdf5_fortran)
# ... try this ... seems to be getting the shared libs...not the static ones...
# set(HDF5_LINK_FLAGS "-L${HDF5_DIRECTORY}/lib -lz -lhdf5_fortran -lhdf5")
# SET(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} ${HDF5_LINK_FLAGS}")
# SET(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} ${HDF5_LINK_FLAGS}")
# ... doesn't work either ...
target_link_libraries(ToolkitLib libz.a libhdf5.a libhdf5_fortran.a)
endif()
endif()
The last 4 "target_link_library" elements are in directories I've added to my LD_LIBRARY_PATH (although, I've heard this isn't the preferred approach). There is also a final output line when I issue gmake install that might be relevant:
-- Set runtime path of "/nobackup/<user id>/program-devel/dist_linux/bin_linux/libProgramDLL.so" to "$ORIGIN/"
It seems I fixed my problem by adding a --with-pic on the hdf5 installation bash scripts. I also had to remove a -standard-semantics from the CMAKE_Fortran_FLAGS in the src directory. Those two things along with the help you provided fixed my problem. Thanks a lot Pierre de Buyl!
When setting advanced properties on a program/link to start as another user it is throwing the error:
Sorry - Plasma
KDEInit could not launch 'kdesu':
Could not open library 'libkdeinit5_kdesu'.
Cannot load library /run/current-system/sw/lib/libkdeinit5_kdesu: (/run/current-system/sw/lib/libkdeinit5_kdesu.so: cannot open shared object file: No such file or directory)
I tried to install kdesu using:
[root#nixos:~]# nix-env -qaP kdesu
nixos.kdeFrameworks.kdesu kdesu-5.36.0
[root#nixos:~]# nix-env -iA nixos.kdeFrameworks.kdesu
replacing old ‘kdesu-5.36.0’
installing ‘kdesu-5.36.0’
building path(s) ‘/nix/store/2bn27h5drw0800gk5z2rmwfx78gqbbdc-user-environment’
created 2209 symlinks in user environment
[root#nixos:~]# kdesu
bash: kdesu: command not found
[root#nixos:~]# which kdesu
which: no kdesu in (/root/bin:/run/wrappers/bin:/etc/per-user-pkgs/root/bin:/root/.nix-profile/bin:/nix/var/nix/profiles/default/bin:/run/current-system/sw/bin)
I also tried installing nix-env -iA nixos.kde-cli-tools but that does not work either.
Any suggestions on how to get kdesu installed on NixOS?
As a general rule, unlike many distros on NixOS installing a library directly doesn't work as intended; the application that needs the library won't be able to find it. Instead, the package must declare all it's dependencies.
Packages which have optional dependencies tend to have a way to add them via configuration. You may want to try something like this in /etc/nixos/configuration.nix
services.xserver.desktopManager.plasma5.extraPackages = with kdeFrameworks;
[ kdesu
];
I'm glad to see that you filed an issue on Nixpkgs, because this is not a configuration issue but a packaging bug.
It looks like kdesu lives in some libexec dir that doesn't hasn't been added to your PATH. It belongs to the kde-cli-tools package. You can run it with
$(nix-build '<nixpkgs>' -A kde-cli-tools --no-out-link)/lib/libexec/kf5/kdesu
You can use the above as an alias to launch kdesu until the fix to the packaging bug arrives.
I'm doing my first steps with Qt and QtWebEngine on an embedded board (i.MX6), using Yocto. Using provided example recipes, like the quicknanobrowser, works nicely on the target. So I can't confirm this answer which claims that WebEngine is not available on embedded platforms.
Now I want to write my own QML application and deploy it on the board. With the recipe meta-toolchain-qt5 I created an SDK and installed it. In QtCreator I set all paths to the SDK installation and tried to build it, but got this error:
Project ERROR: Unknown module(s) in QT: webengine
11:13:13: The process "/opt/poky/1.8/sysroots/x86_64-pokysdk-linux/usr/bin/qt5/qmake" exited with code 3.
It turned out that WebEngine was not included in the SDK. Thanks to this answer, I fixed that by putting the following to my own packagegroup-qt5-toolchain-target.bbappend file:
RDEPENDS_${PN} += " \
qtwebengine \
qtwebengine-qmlplugins \
qtquickcontrols-qmlplugins \
qtwebengine-examples \
"
Then reinstalled the SDK. Now it seems that all WebEngine files are available in the SDK installation (the zsh glob pattern below matches all directories in any subdirectory of /opt/poky/1.8/, which contain "webengine", case-insensitively):
% ls -1 -d (#i)/opt/poky/1.8/**/*webengine*(/)
/opt/poky/1.8/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi/usr/include/qt5/QtWebEngine/
/opt/poky/1.8/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi/usr/include/qt5/QtWebEngine/5.4.3/QtWebEngine/
/opt/poky/1.8/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi/usr/include/qt5/QtWebEngineWidgets/
/opt/poky/1.8/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi/usr/include/qt5/QtWebEngineWidgets/5.4.3/QtWebEngineWidgets/
/opt/poky/1.8/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi/usr/lib/qt5/qml/QtWebEngine/
/opt/poky/1.8/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi/usr/share/qt5/examples/webengine/
/opt/poky/1.8/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi/usr/share/qt5/examples/webenginewidgets/
/opt/poky/1.8/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi/usr/share/qt5/translations/qtwebengine_locales/
Still, I get the same Unknown module error. This is independent of QtCreator, and can also be shown by directly calling qmake:
% source /opt/poky/1.8/environment-setup-cortexa9hf-vfp-neon-poky-linux-gnueabi
% /opt/poky/1.8/sysroots/x86_64-pokysdk-linux/usr/bin/qt5/qmake /home/me/test/test.pro -r -spec linux-oe-g++ CONFIG+=debug CONFIG+=declarative_debug CONFIG+=qml_debug
Project ERROR: Unknown module(s) in QT: webengine
The project itself should be fine, because it compiles and runs without problems on the Desktop installation.
Any ideas? Are there maybe still some files missing in the SDK? Where does qmake search for the modules? How can I tell qmake where to find the WebEngine installation?
In /opt/poky/1.8/environment-setup-cortexa9hf-vfp-neon-poky-linux-gnueabi
add sh /opt/poky/1.8/sysroots/x86_64-pokysdk-linux/environment-setup.d/qt5.sh
This will set up the Qt5 environment.