On Tue, Dec 10, 2013 at 4:56 PM, Jan Engelhardt <jengelh@inai.de> wrote:

On Tuesday 2013-12-10 21:01, Greg Freemyer wrote:

...

I haven't touched sleuthkit in factory for a month or more, but suddenly it doesn't compile due to a C++ code issue:

https://build.opensuse.org/package/live_build_log/openSUSE:Factory/sleuthkit...

Is there something in flux in factory and I should just ignore this?

It would seem that libtsk.so is built without having all its dependencies specified. (In short, `ldd -r libtsk.so` returns unresolved symbols.)

See the "Re: [opensuse-packaging] Packages failing to link" thread.

I must be doing this wrong. I did a local build, then a traditional "cd" to the directory where the new libtsk.so is. ldd -r libtsk.so is showing me lots of what looks to me like the normal c++ stuff undefined. What do I need to do before calling ldd -r libtsk.so? ================= cd /var/tmp/build-root/openSUSE_Factory-i586/home/abuild/rpmbuild/BUILD/sleuthkit-4.1.0/tsk/.libs ldd -r libtsk.so linux-gate.so.1 (0xb773f000) libewf.so.2 => /usr/lib/libewf.so.2 (0xb748a000) libz.so.1 => /lib/libz.so.1 (0xb7473000) libpthread.so.0 => /lib/libpthread.so.0 (0xb7456000) libdl.so.2 => /lib/libdl.so.2 (0xb7451000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7433000) libc.so.6 => /lib/libc.so.6 (0xb7282000) libcnotify.so.1 => /usr/lib/libcnotify.so.1 (0xb727e000) libcpath.so.1 => /usr/lib/libcpath.so.1 (0xb7276000) /lib/ld-linux.so.2 (0xb7740000) libcerror.so.1 => /usr/lib/libcerror.so.1 (0xb7272000) libclocale.so.1 => /usr/lib/libclocale.so.1 (0xb726c000) libcsplit.so.1 => /usr/lib/libcsplit.so.1 (0xb7266000) libuna.so.1 => /usr/lib/libuna.so.1 (0xb71cd000) undefined symbol: _ZTVN10__cxxabiv117__class_type_infoE (./libtsk.so) undefined symbol: __cxa_pure_virtual (./libtsk.so) undefined symbol: _ZTVN10__cxxabiv120__si_class_type_infoE (./libtsk.so) undefined symbol: _ZTVSt18basic_stringstreamIcSt11char_traitsIcESaIcEE (./libtsk.so) undefined symbol: _ZTVSt9basic_iosIcSt11char_traitsIcEE (./libtsk.so) undefined symbol: _ZTVSt15basic_streambufIcSt11char_traitsIcEE (./libtsk.so) undefined symbol: _ZTTSt18basic_stringstreamIcSt11char_traitsIcESaIcEE (./libtsk.so) undefined symbol: _ZTVSt15basic_stringbufIcSt11char_traitsIcESaIcEE (./libtsk.so) undefined symbol: _ZNSs4_Rep20_S_empty_rep_storageE (./libtsk.so) undefined symbol: __gxx_personality_v0 (./libtsk.so) undefined symbol: _ZNSo9_M_insertImEERSoT_ (./libtsk.so) undefined symbol: _ZNSt9basic_iosIcSt11char_traitsIcEE4initEPSt15basic_streambufIcS1_E (./libtsk.so) undefined symbol: _ZNKSt5ctypeIcE13_M_widen_initEv (./libtsk.so) undefined symbol: _ZNSt18basic_stringstreamIcSt11char_traitsIcESaIcEED1Ev (./libtsk.so) undefined symbol: _ZdlPv (./libtsk.so) undefined symbol: _ZSt18_Rb_tree_decrementPSt18_Rb_tree_node_base (./libtsk.so) undefined symbol: _ZNSt8ios_baseD2Ev (./libtsk.so) undefined symbol: _ZSt18_Rb_tree_incrementPSt18_Rb_tree_node_base (./libtsk.so) undefined symbol: __cxa_end_catch (./libtsk.so) undefined symbol: _ZNSt8ios_baseC2Ev (./libtsk.so) undefined symbol: _ZNSt6localeC1Ev (./libtsk.so) undefined symbol: _ZNSsC1ERKSs (./libtsk.so) undefined symbol: _ZNSo5flushEv (./libtsk.so) undefined symbol: _Znwj (./libtsk.so) undefined symbol: _ZNSo3putEc (./libtsk.so) undefined symbol: _ZNSo9_M_insertIyEERSoT_ (./libtsk.so) undefined symbol: _ZNSdD2Ev (./libtsk.so) undefined symbol: _ZSt16__throw_bad_castv (./libtsk.so) undefined symbol: _ZSt16__ostream_insertIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_PKS3_i (./libtsk.so) undefined symbol: _ZNSs4_Rep10_M_disposeERKSaIcE (./libtsk.so) undefined symbol: _ZNSt9basic_iosIcSt11char_traitsIcEE5clearESt12_Ios_Iostate (./libtsk.so) undefined symbol: _ZNSs4_Rep9_S_createEjjRKSaIcE (./libtsk.so) undefined symbol: __cxa_begin_catch (./libtsk.so) undefined symbol: __cxa_rethrow (./libtsk.so) undefined symbol: _ZNSt6localeD1Ev (./libtsk.so) undefined symbol: _ZNSo9_M_insertIxEERSoT_ (./libtsk.so) undefined symbol: _ZNSs4_Rep10_M_destroyERKSaIcE (./libtsk.so) undefined symbol: _ZNSs6assignERKSs (./libtsk.so) undefined symbol: _ZNSolsEi (./libtsk.so) undefined symbol: _ZSt29_Rb_tree_insert_and_rebalancebPSt18_Rb_tree_node_baseS0_RS_ (./libtsk.so) undefined symbol: _ZSt17__throw_bad_allocv (./libtsk.so) undefined symbol: _ZNSs6assignEPKcj (./libtsk.so) undefined symbol: _ZSt19__throw_logic_errorPKc (./libtsk.so) gaf@linux-3j6w:/var/tmp/build-root/openSUSE_Factory-i586/home/abuild/rpmbuild/BUILD/sleuthkit-4.1.0/tsk/.libs> -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

Jan, You obviously spent a lot of time looking at this. Thank you and it will take me a few days to digest your results. Greg Jan Engelhardt <jengelh@inai.de> wrote:

On Wednesday 2013-12-11 19:14, Greg Freemyer wrote:

...

...

...

suddenly it doesn't compile due to a C++ code issue:

https://build.opensuse.org/package/live_build_log/openSUSE:Factory/sleuthkit...

Is there something in flux in factory and I should just ignore this?

It would seem that libtsk.so is built without having all its dependencies specified. (In short, `ldd -r libtsk.so` returns unresolved symbols.)

See the "Re: [opensuse-packaging] Packages failing to link" thread.

I must be doing this wrong. I did a local build, then a traditional "cd" to the directory where the new libtsk.so is. ldd -r libtsk.so is showing me lots of what looks to me like the normal c++ stuff undefined. What do I need to do before calling ldd -r libtsk.so?

Your linker problem is unrelated to recent factory changes, and the problem is reproducible on plain 13.1 as well, because libtsk is an oddball (that took me some looking-into as well).

You can reproduce the issue with the following testcase:

# Makefile.am noinst_LTLIBRARIES = libfoo.la libfoo_la_SOURCES = x.cpp lib_LTLIBRARIES = libbar.la libbar_la_SOURCES = libbar_la_LIBADD = libfoo.la

# x.cpp #include <iostream> int anyfunc(void) { std::cout << std::endl; return 0; }

The C++ linker frontend (CXXLD; g++) implicitly places -lstdc++ on the (raw) linker's command line so that libfoo.so gets properly recorded into libfoo.so (if and when built).

However, -lstdc++ never makes it to the static archive's companion file (libfoo.la, which sits in to records dependencies because archives themselves don't), which is because *the linker is never run for them in the first place*.

Therefore, whenever linking in a static archive with C++ things, you can get screwed. The workaround is to manually add

libtsk_la_LIBADD = -lstdc++

but it feels really really ugly.

My recommendation? Abolish make recursion in tsk/, abolish libtsk[a-z]*.la. Have libtsk.la be directly built from all sources, in one go. That also benefits parallel build, because there will no longer be a serialization point. In other words,

libtsk_la_SOURCES = base/md5c.c base/mymalloc.c base/sha1c.c ... img/img_open.c img/img_types.c ... vs/...

Or have the libtsk sublibraries turned into shared libraries too. Needs adding libtskimg_la_LIBADD=../base/libtskbase.la and similar though.

-- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org