dns-terror (fastresolve-2.10_5) core dump na FreeBSD 10.x

Miroslav Lachman 000.fbsd at quip.cz
Sun Feb 28 23:49:14 CET 2016


Dan Lukes wrote on 02/26/2016 12:45:
> Miroslav Lachman wrote on 26.2.2016 10:54:

>> Zkusim ted do make.conf pridat USE_GCC=yes a uvidim, co to provede.
>
> No a/nebo to zkusit prelozit s optimalizaci.
>
> Nicmene, na report autorum kodu je to tak jako tak, ja ale nedokazu
> navrhnout vhodnou opravu zdrojaku.

Zkusil jsem to prelozit s GCC, ale dns-terror stejne segfaultuje a ani 
mi to nejde debugovat:

# gdb dns-terror
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain 
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...Dwarf Error: wrong 
version in compilation unit header (is 4, should be 2) [in module 
/usr/local/bin/dns-terror]

(gdb) core dns-terror.core
Core was generated by `dns-terror'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/local/lib/libadns.so.1...done.
Loaded symbols for /usr/local/lib/libadns.so.1
Reading symbols from /lib/libz.so.6...done.
Loaded symbols for /lib/libz.so.6
Reading symbols from /usr/local/lib/libdb_cxx-5.3.so.0...done.
Loaded symbols for /usr/local/lib/libdb_cxx-5.3.so.0
Reading symbols from /usr/local/lib/gcc48/libstdc++.so.6...Error while 
reading shared library symbols:
Dwarf Error: wrong version in compilation unit header (is 4, should be 
2) [in module /usr/local/lib/gcc48/libstdc++.so.6]
Reading symbols from /lib/libm.so.5...done.
Loaded symbols for /lib/libm.so.5
Reading symbols from /usr/local/lib/gcc48/libgcc_s.so.1...Error while 
reading shared library symbols:
Dwarf Error: wrong version in compilation unit header (is 4, should be 
2) [in module /usr/local/lib/gcc48/libgcc_s.so.1]
Reading symbols from /lib/libc.so.7...done.
Loaded symbols for /lib/libc.so.7
Reading symbols from /lib/libthr.so.3...done.
Loaded symbols for /lib/libthr.so.3
Reading symbols from /usr/lib/libc++.so.1...done.
Loaded symbols for /usr/lib/libc++.so.1
Reading symbols from /lib/libcxxrt.so.1...done.
Loaded symbols for /lib/libcxxrt.so.1
Reading symbols from /libexec/ld-elf.so.1...done.
Loaded symbols for /libexec/ld-elf.so.1
#0  0x0000000000000000 in ?? ()
[New Thread 802c06400 (LWP 100098/<unknown>)]

(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x00000008013288c8 in ?? () from /usr/local/lib/gcc48/libstdc++.so.6
#2  0x00000008015d41c0 in ?? () from /usr/local/lib/gcc48/libstdc++.so.6
#3  0x00007fffffffd6b0 in ?? ()
#4  0x0000000000000000 in ?? ()


Myslim, ze ja uz se dal nedostanu a tak radsi zkusim kontaktovat autora, 
jestli se na to muze podivat.

Co me ale velmi prekvapilo, ze kdyz jsem do Makefile toho fastresolve 
pridal USE_GCC=yes (tak jako to maji jine porty, ktere pouzivaji GCC), 
najednou fastresolve dostane sileny seznam runtime zavislosti:

New packages to be INSTALLED:
         gcc: 4.8.5_2 [debug]
         indexinfo: 0.2.4 [debug]
         mpc: 1.0.3 [codelab]
         gmp: 5.1.3_3 [debug]
         mpfr: 3.1.3_1 [debug]
         binutils: 2.25.1,1 [debug]
         gcc-ecj: 4.5 [debug]

Installed packages to be REINSTALLED:
         fastresolve-2.10_5 [debug]

A co jsem tak koukal na freshports, tak vlastne kazdy port, ktery 
pouziva USE_GCC ma najednou tyhle veci jako runtime deps.

To mi prijde jako chyba. Nebo se pletu?

Prece tim, ze se na stejny kod pouzije jiny kompilator by se nemel 
zmenit seznam runtime zavislosti, ne?

http://www.freshports.org/lang/gcc/
993 portu v seznamu "This port is required for run"

Mirek



More information about the Users-l mailing list