You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In working with the latest code, both packaging for Gentoo and testing the analysis tools on an actual work task, I had a couple of things to report and a question. See here for the package build setup, basically some bash functions to run the package build commands and install things (the latter part is all manual). http://www.gentoogeek.org/portage-overlay/dev-util/oink-stack/
Issue 1)
Building as a Gentoo package using "./configure perform" everything builds fine with a current toolchain (gcc-4.5.2 plus the tools below) but the regression tests fail with an assert error:
The same assert error is induced when scanning a particular source file with qual.
Issue 2)
Your docs say platform requires gcc 3.4, so I tried 3.4.6 since that's the only 3.4.x version in the Gentoo package tree. So, in building the platform stuff with gcc-3.4.6 there is a missing symbol error from an older gcc libc++:
$ make
cd libc_glibc-2.3.5 && make all
make[1]: Entering directory `oink-stack-9999/platform-model/libc_glibc-2.3.5'
cd src && make all
make[2]: Entering directory `oink-stack-9999/platform-model/libc_glibc-2.3.5/src'
-- aio.c
gcc aio.c -> aio.o
cpp aio.c -> aio.oink.i
oinkx aio.oink.i -> aio.odir
oink/oink: /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.6/libstdc++.so.6: version `GLIBCXX_3.4.11' not found (required by oink-stack-9999/oink/oink)
oink/oink: /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.6/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by oink-stack-9999/oink/oink)
make[2]: *** [aio.odir] Error 1
rm aio.oink.i
make[2]: Leaving directory `oink-stack-9999/platform-model/libc_glibc-2.3.5/src'
make[1]: *** [all] Error 2
make[1]: Leaving directory `oink-stack-9999/platform-model/libc_glibc-2.3.5'
It turns out those symbols are only found in dbg_util.o as shown below:
$ readelf -s ../oink/oink | grep 'GLIBCXX_3\.4\.9' | c++filt | grep _ZN
50: 0000000000000000 0 FUNC GLOBAL DEFAULT UND _ZNSo9_M_insertIPKvEERSoT@GLIBCXX_3.4.9 (6)
$ nm -A *.o | grep "_ZNSo9_M_insertIPKvEERSoT"
dbg_util.o: U _ZNSo9_M_insertIPKvEERSoT_
So my question is...
Did you have any plans to update the above source file so it does not depend on such a narrow version of the C++ library implementation? If so, that should make it possible to package it (relatively) normally, otherwise it seems like I'd need to build it in a chroot with a very specific toolchain just so I can use it (and I would not have an easy way to package it to use the platform-model). Although shared libs/executables are preferred, I would at least be able to package it without the platform stuff.
Thanks in advance again
The text was updated successfully, but these errors were encountered:
In working with the latest code, both packaging for Gentoo and testing the analysis tools on an actual work task, I had a couple of things to report and a question. See here for the package build setup, basically some bash functions to run the package build commands and install things (the latter part is all manual). http://www.gentoogeek.org/portage-overlay/dev-util/oink-stack/
Issue 1)
Building as a Gentoo package using "./configure perform" everything builds fine with a current toolchain (gcc-4.5.2 plus the tools below) but the regression tests fail with an assert error:
System uname: Linux-2.6.36.3-rt-x86_64-AMD
sys-libs/glibc: 2.11.3
sys-devel/binutils: 2.21
sys-devel/gcc: 3.4.6-r2, 4.4.4-r2, 4.5.2
sys-devel/libtool: 2.4-r1
sys-devel/make: 3.81-r2
The same assert error is induced when scanning a particular source file with qual.
Issue 2)
Your docs say platform requires gcc 3.4, so I tried 3.4.6 since that's the only 3.4.x version in the Gentoo package tree. So, in building the platform stuff with gcc-3.4.6 there is a missing symbol error from an older gcc libc++:
It turns out those symbols are only found in dbg_util.o as shown below:
So my question is...
Did you have any plans to update the above source file so it does not depend on such a narrow version of the C++ library implementation? If so, that should make it possible to package it (relatively) normally, otherwise it seems like I'd need to build it in a chroot with a very specific toolchain just so I can use it (and I would not have an easy way to package it to use the platform-model). Although shared libs/executables are preferred, I would at least be able to package it without the platform stuff.
Thanks in advance again
The text was updated successfully, but these errors were encountered: