Undefined symbol error in Centos compile - dynamic

I have run into an interesting problem. I am compiling my application code and was using ace library(version 6_1_1) on my centos 6 machine. Everything worked fine. When i look at the symbols of the ace library compiled on centos 6 machine, it looks like this:
bash-4.1$ nm ace/libACE.so.6.1.1 | grep handle_sig 000f9430 T
_ZN15ACE_Sig_Adapter13handle_signalEiP7siginfoP8ucontext 000b84d0 T _ZN17ACE_Event_Handler13handle_signalEiP7siginfoP8ucontext 00079f10 T _ZN18ACE_Service_Config13handle_signalEiP7siginfoP8ucontext 000f26d0 T _ZN19ACE_Process_Manager13handle_signalEiP7siginfoP8ucontext 0007ee70 T _ZN19ACE_Service_Manager13handle_signalEiP7siginfoP8ucontext
000cf920 T
_ZN20ACE_MMAP_Memory_Pool13handle_signalEiP7siginfoP8ucontext 000f8b80 T _ZN22ACE_Shared_Memory_Pool13handle_signalEiP7siginfoP8ucontext
bash-4.1$
But when i compile the same project on centos 7 machine, the symbols change:
bash# nm ace/6_1_1/ace/libACE.so.6.1.1 | grep handle_sig 000fa090 T
_ZN15ACE_Sig_Adapter13handle_signalEiP9siginfo_tP8ucontext 000b9570 T
_ZN17ACE_Event_Handler13handle_signalEiP9siginfo_tP8ucontext 0007e070 T
_ZN18ACE_Service_Config13handle_signalEiP9siginfo_tP8ucontext 000f3500 T
_ZN19ACE_Process_Manager13handle_signalEiP9siginfo_tP8ucontext 00081cb0 T
_ZN19ACE_Service_Manager13handle_signalEiP9siginfo_tP8ucontext 000d1990 T
_ZN20ACE_MMAP_Memory_Pool13handle_signalEiP9siginfo_tP8ucontext 000f93d0 T
_ZN22ACE_Shared_Memory_Pool13handle_signalEiP9siginfo_tP8ucontext bash#
Notice that there is an extra _t in siginfo. So, my application which links this library fails to launch during run time giving me that error:
symbol "_ZN17ACE_Event_Handler13handle_signalEiP9siginfo_tP8ucontext"
not found
Another interesting point to note is that if i copy the compiled ace library from my centos 6 box into centos 7 box, my application works fine.
I am lost on how to fix this issue. Any help in this regards will be appreciated!

But when i compile the same project on centos 7 machine, the symbols change:
Probably Glibc on Centos 7 has changed one of the types in public headers which caused mangler to emit different symbols:
$ echo _ZN15ACE_Sig_Adapter13handle_signalEiP7siginfoP8ucontext | c++filt
ACE_Sig_Adapter::handle_signal(int, siginfo*, ucontext*)
$ echo _ZN15ACE_Sig_Adapter13handle_signalEiP9siginfo_tP8ucontext | c++filt
ACE_Sig_Adapter::handle_signal(int, siginfo_t*, ucontext*)
Notice that new method now uses siginfo_t rather than siginfo (you'll see hundreds of complaints if you google for "siginfo_t vs siginfo").
Another interesting point to note is that if i copy the compiled ace
library from my centos 6 box into centos 7 box, my application works fine.
That's backward compatibility - you can (usually) run apps linked on older version of distro on it's newer versions.
On the contrary, forward compatibility (in your case - linking old application against new library) is not guaranteed.
I am lost on how to fix this issue.
If you are only interested in new CentOS - rebuild all your code. If you want to run on older versions - build on the oldest and distribute that.

Related

distro 'rhel7.2' does not exist in our dictionary

While installing a kvm via virt-install I have used following attribute os_variant=rhel7.2. While installing I am getting following error :
distro 'rhel7.2' does not exist in our dictionary
When I do uname -r I am getting output as
3.10.0-327.el7.x86_64
It is a RHEL KVM host.
Running osinfo-query os|grep 'Red Hat Enterprise Linux 7.2' returns following:
rhel7.1 | Red Hat Enterprise Linux 7.2 | 7.2 | http://redhat.com/rhel/7.2
What can be solution to this problem?
You could create a custom config file to define a RHEL-7.2 distro, but it is honestly not that important from virt-install's POV. The distro is used to lookup the optimized drivers to use for disk & network primarily. Just using the 'rhel7.1' distro type when installing 'rhel-7.2' will work just fine from this POV.
virt-install get's it's os information out of osinfo-db
If your os does not ship a recent version of osinfo-db you can manually download it from https://releases.pagure.org/libosinfo/ and import it.
e.g.
wget https://releases.pagure.org/libosinfo/osinfo-db-20200325.tar.xz
osinfo-db-import -v osinfo-db-20200325.tar.xz
-v will display all imported os'es, I believe your choice has to match one of the xml files in this list.

Systemtap libdwfl error on Linux

I am tying to work/setup the Systemtap tool for profiling OS procesess, on a Virtual Linux. I am using VirtualBox to run the image. Via
rpm -q kernel
and
cat /proc/version
The version obtained is:
Linux version 2.6.32-5-686 (Debian 2.6.32-48squeeze4)
I have correctly downloaded and installed the tool and wrote a simple program (.stp). However I keep getting the same error, which I have searched information in many places without success:
After executing:
sudo stap my_profiler.stp
I get:
semantic error: libdwfl failure (all kernel modules found): no error
Pass 3: translation failed. Try again with another '--vp 001' option.
According to https://sourceware.org/systemtap/SystemTap_Beginners_Guide/errors.html
⁠semantic error: libdwfl failure
There was a problem processing the debugging information. In most cases, this error results from the installation of a kernel-debuginfo package whose version does not match the probed kernel exactly. The installed kernel-debuginfo package itself may have some consistency or correctness problems.
I have found no relevant information on the "kernel-debuginfo" package. I have also tried the verbose option without benefit. I even tried with an old Snapshot of the VM. Any ideas?
The code of the .stp program I ran:
probe timer.profile{
printf("Process: %s\n", execname())
printf("Process ID: %d\n", pid())
}
Found the problem!!!! It seemed that I was using the wrong version of the Linux Kernel. I was using the default kernel supplied by the version I wrote in the question. It seems that that version (the 2.6.32-5-686 one) has problems with the debug-info so all I did was try the same with another version (the Linux version 3.9.6 with gcc version 4.7.2 Debian 4.7.2-5) and it worked without trouble :)

Sat4j Remote Control window doesn't open

What happens:
I execute the following command.
java -jar sat4j-sat.jar -remote
No window opens, and I get a console output same as without the -remote flag, which begins:
c SAT4J: a SATisfiability library for Java (c) 2004-2013 Artois (...)
c This is free software under the dual EPL/GNU LGPL licenses.
c See www.sat4j.org for details.
c version 2.3.4.v20130419
c java.runtime.name OpenJDK Runtime Environment
c java.vm.name OpenJDK Client VM
c java.vm.version 24.65-b04
c java.vm.vendor Oracle Corporation
c sun.arch.data.model 32
c java.version 1.7.0_65
c os.name Linux
c os.version 3.2.0-4-686-pae
(...)
What is expected:
From readme.txt:
To run sat4j with on the fly configuration:
java -jar sat4j-sat.jar -remote
These instructions should open a java window named Remote Control. We
assume that the 1.5 version of the java command is in your path. If
it isn’t, then you should either specify the complete path to the java
command or update your PATH environment variable as described in the
installation instructions for the Java 2 SDK.
Other details
I have tried multiple versions of the library, up to 2.3.4.
My system is Debian 7 with Gnome 2.
My default Java installation is OpenJDK 1.7.0_65.
My secondary Java installation is Oracle Java 1.8.0_45 (with the same issue).
Gnuplot 4.6 is installed.
My first machine has a 32 bit dual core CPU with 2GB of RAM.
My second machine has a 64 bit quad core CPU with 8GB of RAM with nearly identical software.
Question
Has anyone used SAT4J's remote control feature? What is the problem with my method?
Update
On another machine (64 bit Debian 7) the window opens. After start dat files are created, but plotting does not start.
Update 2
I ran the generated instance.dimacs-gnuplot.gnuplot file manually from a gnuplot terminal, and I got the message unknown or ambiguous terminal type for the x11 type. I installed the gnuplot-x11 package, and now it works on the workplace machine: I can see the diagrams (wow!). Unfortunately on my home machines the Remote Control window still doesn't open.
The -remote parameter is used to display the remote control, i.e. to setup the various parameters of the solver.
If you want to always monitor what the solver is doing, you need to use in conjunction the -r parameter.
So the complete command line should be:
java -jar sat4j-sat.jar -r -remote file.cnf
You can get a fresh snapshot of Sat4j Sat on our continuous integration server:
http://bamboo.ow2.org/browse/SAT4J-DEF2-41/artifact/JOB1/nightly_build/
This might solve the issue you met with the 2.3.4 release.
Cheers,
Daniel

ios Symbolication Server side

How to symbolicate the ios crash report after uploading to server in a linux environment where iOS development tools and scripts will not be available. I know Apple uses atos and some other tools to map the hex addresses to symbol along with .dYSM file.
I can upload .dYSM file along with crash report to server. Refered QuincyKit, but they are doing symbolication locally. But other's like HockeyApp and Critterism are doing it remotely.
Pls recommend the possible ways to do it in server.
It is possible. You can take a look at https://github.com/facebook/atosl
I got it working under Linux. (Ubuntu Server) However, it takes some time to get it up and running.
Installing atosl
First, you need to install libdwarf-dev, dwarfdump, binutils-dev and libiberty-dev.
E.g. on Ubuntu:
$ sudo apt-get install libdwarf-dev dwarfdump binutils-dev libiberty-dev
Download or clone the atosl repo from GitHub:
$ git clone https://github.com/facebook/atosl.git
CD to the atosl dir
$ cd atosl
Create a local config config.mk.local which contains a flag with the location of your binutil apps. (in Ubuntu by default that's /usr/bin). If you're not sure, you can find out by executing cat /var/lib/dpkg/info/binutils.list | less and copy the path of the file objdump. E.g. if the entry is /usr/bin/objdump, your path is /usr/bin.
So in the end, your config.mk.local should look like this:
LDFLAGS += -L/usr/bin
Compile it:
$ make
Now you can start using it:
$ ./atosl --help
Symbolicating example
To show how atosl is used, I'll provide a simple example.
Now let's take a look at a line from the crash log:
13 ErrorApp 0x000ea294 0xe3000 + 29332
To symbolicate this, we will need the load address, and the runtime address.
In this example the runtime address is 0x000ea294, and the load address is 0xe3000.
Now we have everything we need:
$ ./atosl -o [YOUR_dSYM_FILE] -l [LOAD_ADDRESS] [RUNTIME_ADDRESS]
In this example:
$ ./atosl -o ErrorApp.app.dSYM/Contents/Resources/DWARF/ErrorApp -l 0xe3000 0x000ea294
Which returns the symbolicated line:
main (in ErrorApp) (main.m:16)
FYI
Your vmaddr, which usually is 0x00001000, you can find by looking at the segname __TEXT Mach-O load command of your binary. In my example, this happens to be different, namely 0x00004000
To find the address, we need to do some math.
The address is found by the following formula:
address = vmaddr + ( runtime_address - load_address )
In this example our address is:
0x00004000 + ( 0x000ea294 - 0xe3000 ) = 0xB294
I haven't played around with this that much yet, but for now it seems to give me the results I needed. Maybe it will work for you too.
You need to implement your own linux compatible versions of atos, otool and dwarfdump (at least the functionality needed for symbolication). The Apple tools are not open source and only run on Mac OS X.
None of the services provide a solution that can be used by 3rd parties on non OS X systems. So your only chance, besides implementing the required functionality to run on your linux system, is to do it on a Mac like QuincyKit does it, see https://github.com/TheRealKerni/QuincyKit/wiki/Remote-symbolication or use a third party service.
Note: I am the creator of QuincyKit and Co-Founder of HockeyApp.

Asterisk 10, dahdi_dummy won't build

# cat /proc/version
Linux version 3.2.0-2-amd64 (Debian 3.2.12-1) (debian-kernel#lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-1) ) #1 SMP Tue Mar 20 18:36:37 UTC 2012
I've read some apps in Asterisk 10 still use timers from dahdi_dummy. But it won't build - make ignores dahdi_dummy module:
root#ster:/usr/src/dahdi-linux-complete-2.6.0+2.6.0# find ./ -name '*dummy*'
./tools/menuselect/contrib/Makefile-dummy
./tools/menuselect/contrib/menuselect-dummy
./linux/drivers/dahdi/dahdi_dummy.c
dahdi show status in cli shows nothing. Really i will not use digium cards, so i probably need only dahdi_dummy.
# lsmod | grep dahdi
dahdi_transcode 13001 1 wctc4xxp
dahdi_voicebus 45931 2 wcte12xp,wctdm24xxp
dahdi 191058 11 wct4xxp,dahdi_voicebus,wcte12xp,wct1xxp,wcte11xp,wctdm24xxp,wcfxo,wctdm,wcb4xxp,dahdi_transcode,xpp
crc_ccitt 12347 2 dahdi,wctdm24xxp
So, may be i don't need that module anymore? And why it won't compile?
Thanks.
You do not need dahdi_dummy anymore. It has not been required since DAHDI-Linux 2.3.0. The core of DAHDI is now able to use the kernel timers automatically if no telephony hardware is installed.
The reason it won't compile in 2.6.0 was due to an error that was fixed in 2.6.0-rc1. The interface between the core of DAHDI and the board drivers changed but dahdi_dummy was not updated as well. More information is available on the Asterisk issue tracker in issue DAHLIN-274.