Error "Did you compile with -rdynamic?" seen only when application installed using RPM - gtk

I have a Vala application that loads modules just gmodule-2.0, when installed through usual make install means everything works correctly. When I build an RPM file and install (on Fedora 27) using dnf install my-app I get a whole bunch of errors like
(my-app:15094): Gtk-WARNING **: Could not find signal handler 'btn_thing_changed_cb'. Did you compile with -rdynamic?
(my-app:15094): Gtk-WARNING **: Could not find signal handler 'adj_thing_value_changed_cb'. Did you compile with -rdynamic?
Even after I add -rdynamic to the build and reinstall I continue to see these errors. Somewhere I read that I need to use gmodule-export-2.0, but the diff on it's pkgconfig and the one for gmodule-2.0 shows that they're exactly the same. Soooo...
The application is written in Vala and built using valac. Also, the UI classes that I have are Gtk template classes which may be an issue, but the fact that it works when I install from source makes me think that it isn't.

This is because the default RPM build will strip the symbols out of executables. You can disable stripping by changing your spec file to include:
%global __os_install_post %{nil}
or:
%global __strip /bin/true

Related

Checksum failed 'download/jpegsrc.v8b.tar.gz while installing SDL. How to resolve?

I am trying to install SDL but error with checksum occur:
Building Alien-SDL-1.446
Build option used:
Source code build
z(v1.2.5) jpeg(v8b) tiff(v3.9.1) png(v1.4.1) freetype(v2.3.12) SDL(v1.2.15) SDL_image(v1.2.11) ogg(v1.3.0) vorbis(v1.3.3) SDL_mixer(v1.2.12) SDL_ttf(v2.0.11) SDL_gfx(v2.0.25)
Building Alien-SDL
Fetching 'http://froggs.de/libz/zlib-1.2.5.tar.gz'...
Checking checksum for 'download/zlib-1.2.5.tar.gz'...
Fetching 'http://www.ijg.org/files/jpegsrc.v8b.tar.gz'...
###WARN## checksum for file download/jpegsrc.v8b.tar.gz is 033998fb47d66e1a5e16a51243424be7a172296b but we expect 15dc1939ea1a5b9d09baea11cceb13ca59e4f9df
###ERROR### Checksum failed 'download/jpegsrc.v8b.tar.gz' at inc/My/Builder.pm line 161.
Checking checksum for 'download/jpegsrc.v8b.tar.gz'...
-> FAIL Installing Alien::SDL failed. See /home/kes/.cpanm/work/1634308125.20978/build.log for details. Retry with --force to force install it.
Searching Tie::Simple on mirror index /home/kes/work/projects/SDL/test/local/cache/modules/02packages.details.txt ...
--> Working on Tie::Simple
Fetching http://cpan.metacpan.org/authors/id/H/HA/HANENKAMP/Tie-Simple-1.04.tar.gz
-> OK
How to install SDL?
_build/config_data has the wrong first source set for jpeg v8b. The second source passes the sha1sum, but the first doesn't. If the correct archive is downloaded, the system then hangs up when configuring SDL. SDL_image and SDL_mixer can be manually configured, but SDL_ttf cannot be configured successfully. One should not rely on cpan's sources here. Install all the binary SDL1.2 libraries in a binary distro, also install packages e.g. perl-Alien, libalien-sdl-perl libalien-sdl-dev-perl to have alien installed, and then when it runs the Build.PL for SDL, choose the option to use your own /usr/ libraries (you will see 3 options if it works, choose [1] instead of [2]). Cpan will then succeed with install SDL.
There should be extra instructions with this, that you need to use binary libraries here. Because the script install is super outdated as far as I can tell, if you are running linux that is.

Installing Tensorflow from source

I've been trying to install Tensorflow and get it working over the past few days. Whilst I have managed to install TF and get it working as tested by opening Python in the terminal and typing,
import tensorflow as tf
I have not been successful attempting to retrain Inception v3. I managed to install it from source once by following the instructions laid out here however I am no longer able to do so. When I get to the section 'Create the pip package and install' and go to run bazel build -c opt //tensorflow/tools/pip_package:build_pip_package in the root of my Tensorflow directiory I get the following error.
kieran#kieranUbuntu:~/tensorflow$ bazel build -c opt //tensorflow/tools/pip_package:build_pip_package
ERROR: /home/kieran/tensorflow/tensorflow/core/BUILD:1068:1: no such target '//tensorflow/tools/git:gen/spec.json': target 'gen/spec.json' not declared in package 'tensorflow/tools/git' defined by /home/kieran/tensorflow/tensorflow/tools/git/BUILD and referenced by '//tensorflow/core:version_info_gen'.
ERROR: /home/kieran/tensorflow/tensorflow/core/BUILD:1068:1: no such target '//tensorflow/tools/git:gen/head': target 'gen/head' not declared in package 'tensorflow/tools/git' defined by /home/kieran/tensorflow/tensorflow/tools/git/BUILD and referenced by '//tensorflow/core:version_info_gen'.
ERROR: /home/kieran/tensorflow/tensorflow/core/BUILD:1068:1: no such target '//tensorflow/tools/git:gen/branch_ref': target 'gen/branch_ref' not declared in package 'tensorflow/tools/git' defined by /home/kieran/tensorflow/tensorflow/tools/git/BUILD and referenced by '//tensorflow/core:version_info_gen'.
ERROR: Analysis of target '//tensorflow/tools/pip_package:build_pip_package' failed; build aborted.
INFO: Elapsed time: 3.063s
This is the same error I ran into when I managed to install it and then attempted retaining the classifier following this tutorial. At the section, bazel build tensorflow/examples/image_retraining:retrain.
I just can't figure out what is going wrong and I have been trying for so long.
I'm using this pip version, # Ubuntu/Linux 64-bit, CPU only, Python 2.7
I think you should search before ask, This link can probably solve your issue.
The issue lied in the incorrect use of ./configure. Whilst it was ran I currently have two versions of python on my computer, both of which are stored in different locations, when running ./configure I pointed it to the wrong python version. After rectifying the issue everything worked correctly.

Building Swift on CentOS

I am building Swift compiler from source on CentOS 6, and am running into a library issue. After fighting with the build script for a while I have got where running ./utils/build-script eventually gives:
+ /home/src/cmake-3.4.1-Linux-x86_64/bin/cmake --build /home/src/swift/build/Ninja-DebugAssert/cmark-linux-x86_64 -- all
ninja: no work to do.
llvm: using standard linker
+ cd /home/src/swift/build/Ninja-DebugAssert/llvm-linux-x86_64
+ /home/src/cmake-3.4.1-Linux-x86_64/bin/cmake -G Ninja -DCMAKE_C_COMPILER:PATH=clang -DCMAKE_CXX_COMPILER:PATH=clang++ '-DCMAKE_C_FLAGS= ' '-DCMAKE_CXX_FLAGS= ' -DCMAKE_BUILD_TYPE:STRING=Debug -DLLVM_ENABLE_ASSERTIONS:BOOL=TRUE -DLLVM_TOOL_SWIFT_BUILD:BOOL=NO '-DLLVM_TARGETS_TO_BUILD=X86;ARM;AArch64' -DLLVM_INCLUDE_TESTS:BOOL=TRUE -LLVM_INCLUDE_DOCS:BOOL=TRUE -DCMAKE_INSTALL_PREFIX:PATH=/usr -DINTERNAL_INSTALL_PREFIX=local /home/src/swift/llvm
CMake Error at cmake/modules/CheckAtomic.cmake:36 (message):
Host compiler appears to require libatomic, but cannot find it.
Call Stack (most recent call first):
cmake/config-ix.cmake:296 (include)
CMakeLists.txt:403 (include)
-- Configuring incomplete, errors occurred!
See also "/home/src/swift/build/Ninja-DebugAssert/llvm-linux-x86_64/CMakeFiles/CMakeOutput.log".
See also "/home/src/swift/build/Ninja-DebugAssert/llvm-linux-x86_64/CMakeFiles/CMakeError.log".
./utils/build-script: command terminated with a non-zero exit status 1, aborting
(gcc-4.8.2 was what I compiled llvm with)
libatomic is there:
$ locate libatomic
/opt/gcc-4.8.2/lib64/libatomic.a
/opt/gcc-4.8.2/lib64/libatomic.la
/opt/gcc-4.8.2/lib64/libatomic.so
/opt/gcc-4.8.2/lib64/libatomic.so.1
/opt/gcc-4.8.2/lib64/libatomic.so.1.0.0
I just don't know how to tell the build system where to look. I have tried the usual CMAKE_LIBRARY_PATH (exporting on the command line - I am not sure if cmake works like the way LD_LIBRARY_PATH, LIBRARY_PATH work) but it can't seem to find it.
I also don't have root on the machine.
I had not tried building from source on CentOS 6 until I saw this question, but I have been able to build Swift 2.2 on CentOS 7.1 and Ubuntu 14.04, with partial success. A few things to think about:
You will need numerous dependencies required to build Swift, and unless
they happen to be already on the system, you will need root access to
install them.
Use -R flag with the build-script to create a release build.
Building in DebugAssert (the default) will require a lot of memory. In my case even 14 GB was not sufficient. A release build
can be done with about 6 GB.
As for your specific problem, it is related to Clang's dependency on GCC-related packages for headers and libraries. See, for example, Fedora 21 with clang, without gcc.
Even if you installed GCC 4.8.2 and adjusted the path to use gcc and g++ from 4.8.2, Clang may still be looking in the old GCC directories for headers and libraries. CMake first tries to compile a C++ test file that includes the header atomic, which does not exist in the old GCC. So, it then tries to link a C test program that uses the library libatomic, which again doesn't exist in the old GCC. You can see this by looking at llvm/cmake/modules/CheckAtomic.cmake mentioned by usr1234567. CMakeError.log and CMakeOutput.log can also provide valuable insight. BTW, when I was building Swift on CentOS 7.1, I didn't run into this problem because GCC 4.8.2 was used by Clang for headers and libraries and the atomic header was found, so the C++ file got compiled. However, had the libatomic check been done, it would have failed, because libatomic.so in the repository-provided 4.8.2 has INPUT ( <name of some non-existent file> ), so trying to link with libatomic errors out.
I'm sure there are various ways of dealing with this issue, but what solved the problem for me was setting the following environment variables, please adjust to your specific setup:
export CPLUS_INCLUDE_PATH=/opt/gcc-4.8.2/include/c++/4.8.2:/opt/gcc-4.8.2/include/c++/4.8.2/x86_64-unknown-linux-gnu
export LIBRARY_PATH=/opt/gcc-4.8.2/lib64:/opt/gcc-4.8.2/lib/gcc/x86_64-unknown-linux-gnu/4.8.2
Also make sure that your 4.8.2 version of libstdc++.so is available to the dynamic linker at runtime. Since you don't have root, do
export LD_LIBRARY_PATH=/opt/gcc-4.8.2/lib64
If you had root, you could use ldconfig.
Before you start building Swift, you may want to try building, using Clang, a simple C program linking it with libatomic (the code doesn't actually have to use any symbols from the lib) and a simple C++ program that includes the <atomic> header. When compiling the C++ program, use the -std=c++11 compiler flag. If the C++ program compiles successfully, then it is not necessary for the libatomic linking test to be successful.
Interestingly, the CMakeOutput.log file still did not report finding GCC 4.8.2 as a candidate GCC installation, but the configuration/build worked well past the error.
Hopefully this helps. Please let us know if you run into something else.
CheckAtomic.cmake seems to be part of LLVM. I found a file at Github and it tries to find '__atomic_fetch_add_4' from libatomic
check_library_exists(atomic __atomic_fetch_add_4 "" HAVE_LIBATOMIC)
This fails for you. Check CMakeFiles/CMakeError.log to get more details why this test failed. Or try this line in a new project.

Using Scons to build mongo-nonx86 on an arm based Synology NAS

I have a Synology DS212j NAS (cpu Feroceon 88FR131 rev 1 (v5l)) with the optware ipkg installed. I am trying to build mongo-nonx86 on it.
"scons all" gives me the following messages:
scons: Reading SConscript files ...
scons version: 2.0.1
python version: 2 5 6 'final' 0
Checking whether the C++ compiler worksyes
Checking for C library stdc++... no
can't find stdc++ library which is needed
I have the stdc++ library installed, I also have ssl installed. My underlying question is how can I get scons to tell me more about what is really missing, where it is looking, how it is looking etc. I have so far found no options which generate any more useful diagnostic output?
Obviously a ready-made solution for getting mongodb working on this great little box would be even more welcome :-)
Well even if you do have it installed, it doesn't seem to think so, here is what I would try to do, install libssl-dev, then try to install the dev package for libstdc++, which is: libstdc++-dev.
Then see if you can compile it.

Error while compiling tossim in tiny OS

When I try to compile TOSSIM in tiny OS v-2.0.2 , this is the error that it is giving me:
# make micaz sim
Makefile:2: /opt/tinyos-2.1.0/support/make/Makerules: No such file or directory
make: *** No rule to make target `/opt/tinyos-2.1.0/support/make/Makerules'. Stop.
How to remove this error?
Did you run a ./configure ? This is usually the config script used by make files, but sometimes people use strange build systems so I'd look around in the project's root directory for something else relating to configuring or installing. There should also be a text file called 'INSTALL' which helps.
The usual build commands are:
./configure
make
make install clean