[ebuild N ] app-forensics/libewf-20130416 USE="-debug -ewf -fuse -rawio -ssl -static-libs -unicode -uuid -zlib" There are lot of errors after these: libtool: compile: x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I../common -I../include -I../common -I../libcstring -I../libcerror -I../libcerror -I../libcdata -I../libcl ocale -I../libcnotify -I../libcsplit -I../libuna -I../libcfile -I../libcpath -I../libbfio -I../libfcache -I../libfvalue -I../libmfdata -I../libhmac -I../libcaes -pipe -O2 -Wall -c libewf_compression.c -fPIC -DPIC -o .libs/libewf_compression.o In file included from libewf_section.h:38:0, from libewf_chunk_table.h:34, from libewf_chunk_table.c:31: libewf_chunk_table.c: In function 'libewf_chunk_table_read_offsets': ewf_checksum.h:37:13: warning: implicit declaration of function 'adler32' [-Wimplicit-function-declaration] (uint32_t) adler32( (uLong) previous_key, (const Bytef *) buffer, (uInt) size ^ libewf_chunk_table.c:697:25: note: in expansion of macro 'ewf_checksum_calculate' calculated_checksum = ewf_checksum_calculate( ^ ewf_checksum.h:37:23: error: 'uLong' undeclared (first use in this function) (uint32_t) adler32( (uLong) previous_key, (const Bytef *) buffer, (uInt) size ^ libewf_chunk_table.c:697:25: note: in expansion of macro 'ewf_checksum_calculate' calculated_checksum = ewf_checksum_calculate( ^ ewf_checksum.h:37:23: note: each undeclared identifier is reported only once for each function it appears in (uint32_t) adler32( (uLong) previous_key, (const Bytef *) buffer, (uInt) size ^ libewf_chunk_table.c:697:25: note: in expansion of macro 'ewf_checksum_calculate' calculated_checksum = ewf_checksum_calculate( ^ libewf_chunk_table.c:700:12: error: expected ')' before numeric constant 1 ); ^ ewf_checksum.h:37:30: note: in definition of macro 'ewf_checksum_calculate' (uint32_t) adler32( (uLong) previous_key, (const Bytef *) buffer, (uInt) size ^
Created attachment 499424 [details] build.log
Created attachment 499426 [details] emerge --info
This probably calls for a version bump - there are releases on the GitHub from 2017, although these seem to be marked experimental. =app-forensics/libewf-20130416 isn't building for me either. I seem to be getting different error messages, interestingly. This was when I had upgraded gcc to 6.4.0, selected a new 17.0 profile, and was rebuilding everything, so I know this code used to build under 4.9.4. The errors start with warnings about functions being "declared but never defined", then the build ultimately fails when it comes time to link, with undefined references: > /bin/sh ../libtool --tag=CC --mode=compile x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I../common -I../include -I../common -I../libcstring -I../libcerror -march=native -O2 -pipe -Wall -c -o libuna_codepage_iso_8859_15.lo libuna_codepage_iso_8859_15.c > In file included from libuna_byte_stream.c:29:0: > libuna_unicode_character.h:201:5: warning: inline function 'libuna_unicode_character_copy_to_utf32_stream' declared but never defined > int libuna_unicode_character_copy_to_utf32_stream( > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > /bin/sh ../libtool --tag=CC --mode=compile x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I../common -I../include -I../common -I../libcstring -I../libcerror -march=native -O2 -pipe -Wall -c -o libuna_codepage_iso_8859_16.lo libuna_codepage_iso_8859_16.c > libuna_unicode_character.h:191:5: warning: inline function 'libuna_unicode_character_copy_from_utf32_stream' declared but never defined > int libuna_unicode_character_copy_from_utf32_stream( > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > libuna_unicode_character.h:182:5: warning: inline function 'libuna_unicode_character_copy_to_utf32' declared but never defined > int libuna_unicode_character_copy_to_utf32( > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > libuna_unicode_character.h:173:5: warning: inline function 'libuna_unicode_character_copy_from_utf32' declared but never defined > int libuna_unicode_character_copy_from_utf32( > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > libuna_unicode_character.h:166:5: warning: inline function 'libuna_unicode_character_size_to_utf32' declared but never defined > int libuna_unicode_character_size_to_utf32( > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > libuna_unicode_character.h:156:5: warning: inline function 'libuna_unicode_character_copy_to_utf16_stream' declared but never defined > int libuna_unicode_character_copy_to_utf16_stream( > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > libuna_unicode_character.h:146:5: warning: inline function 'libuna_unicode_character_copy_from_utf16_stream' declared but never defined > int libuna_unicode_character_copy_from_utf16_stream( > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > libuna_unicode_character.h:137:5: warning: inline function 'libuna_unicode_character_copy_to_utf16' declared but never defined > int libuna_unicode_character_copy_to_utf16( > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ (and others immediately afterwards; see my build log, which I'll be attaching immediately after this comment) In my case, I'm building libewf with the USE flags "fuse ssl unicode uuid zlib", so it's quite possible I might get other errors (possibly the original errors in this bug) if I built without the "unicode" USE flag.
Created attachment 514062 [details] build.log for Unicode "declared but never defined" errors
Created attachment 514064 [details] emerge --info for Unicode "declared but never defined" errors
My apologies - looking further, my own bug has (according to bug #568738) been fixed in the latest available ebuild marked ~amd64. I apologise for polluting this bug and will mark my attachments obsolete.
Just updating this bug to confirm that after accepting ~amd64 on =app-forensics/libewf-20140608-r1 , I was able to build on gcc-6.4.0. To the original bug reporter: Even though our bugs were different, it's worth trying to build on the latest available version to make sure that bugs are still reproducible on the latest ebuild. Try giving that a go and seeing if it works for you! In any case, =app-forensics/libewf-20130416 should probably be dropped from the tree as it appears not to build on modern profiles.
An automated check of this bug failed - repoman reported dependency errors (85 lines truncated): > dependency.bad app-forensics/libewf/libewf-20140608-r1.ebuild: DEPEND: amd64(default/linux/amd64/17.0) ['=app-forensics/libbfio-0.0.20120425_alpha'] > dependency.bad app-forensics/libewf/libewf-20140608-r1.ebuild: RDEPEND: amd64(default/linux/amd64/17.0) ['=app-forensics/libbfio-0.0.20120425_alpha'] > dependency.bad app-forensics/libewf/libewf-20140608-r1.ebuild: DEPEND: amd64(default/linux/amd64/17.0/desktop) ['=app-forensics/libbfio-0.0.20120425_alpha']
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=514dc4d9c8f74aca164ff4d74c54917ed1b24b92 commit 514dc4d9c8f74aca164ff4d74c54917ed1b24b92 Author: Thomas Deutschmann <whissi@gentoo.org> AuthorDate: 2018-02-06 15:24:22 +0000 Commit: Thomas Deutschmann <whissi@gentoo.org> CommitDate: 2018-02-06 15:24:22 +0000 app-forensics/libewf: fix test failures Bug: https://bugs.gentoo.org/634910 Package-Manager: Portage-2.3.24, Repoman-2.3.6 .../libewf-20140608-fix-tmpdir-in-tests.patch | 33 ++++++++++++++++++++++ app-forensics/libewf/libewf-20140608-r1.ebuild | 10 ++++--- 2 files changed, 39 insertions(+), 4 deletions(-)}
I am most sorry, my desktop system failed and my laptop also did about 1 mouth ago. I can no longer contribute to Gentoo Linux until I get a new system and my life back in order. I am currently working off an old i386 system and borrowed laptop so I don't have the compute power to spare for running Gentoo. I'll be back, but in the meantime please take what action you will. Thanks for all the penguins and God bless!
I've been fighting for/with libewf, sleuthkit and a few other forensic packages in Gentoo for a few years now... There is a huge refactoring going on for most libraries and they are far from stable (not to mention "forensically stable"). Most of the work is under https://github.com/libyal Seeing that libewf was PMASKED, I spent a few hours and was able to have working libewf and sleuthkit[-java], mostly based on pentoo overlay. I will try to test at least some of its functionality in the coming weeks, but no guarantees. If anyone wants to try, use my pkalin overlay https://github.com/thinrope/pkalin and try libewf and sleuthkit. Here is my situation: $ qlist -vIRU sleuthkit libewf app-forensics/libewf-20171104::pkalin (ewf nls python_targets_python2_7 ssl unicode zlib) app-forensics/sleuthkit-4.6.0::pkalin (aff ewf static-libs threads zlib) $ equery g --depth=1 =app-forensics/sleuthkit-4.6.0::pkalin =app-forensics/libewf-20171104::pkalin * dependency graph for app-forensics/sleuthkit-4.6.0 `-- app-forensics/sleuthkit-4.6.0 ~amd64 `-- dev-db/sqlite-3.22.0 (dev-db/sqlite) amd64 `-- dev-lang/perl-5.24.3-r1 (dev-lang/perl) amd64 `-- app-forensics/afflib-3.7.4 (app-forensics/afflib) amd64 `-- app-forensics/libewf-20171104 (app-forensics/libewf) ~amd64 `-- virtual/jdk-1.8.0-r3 (>=virtual/jdk-1.8) amd64 `-- dev-java/c3p0-0.9.5.1 (>=dev-java/c3p0-0.9.5) amd64 `-- dev-java/jdbc-postgresql-9.4_p1206 (>=dev-java/jdbc-postgresql-9.4) amd64 `-- sys-libs/zlib-1.2.11-r1 (sys-libs/zlib) amd64 `-- app-doc/doxygen-1.8.13-r1 (app-doc/doxygen) amd64 `-- dev-util/cppunit-1.14.0 (>=dev-util/cppunit-1.2.1) amd64 `-- app-portage/elt-patches-20170815 (>=app-portage/elt-patches-20170422) amd64 `-- sys-devel/automake-1.16.1-r1 (>=sys-devel/automake-1.16) [~amd64 keyword] `-- sys-devel/automake-1.15.1-r2 (>=sys-devel/automake-1.15.1) amd64 `-- sys-devel/autoconf-2.69-r4 (>=sys-devel/autoconf-2.69) amd64 `-- sys-devel/libtool-2.4.6-r3 (>=sys-devel/libtool-2.4) amd64 `-- dev-java/java-config-2.2.0-r4 (>=dev-java/java-config-2.2.0-r3) amd64 `-- dev-java/ant-core-1.9.2 (>=dev-java/ant-core-1.8.2) amd64 `-- dev-java/javatoolkit-0.3.0-r9 (>=dev-java/javatoolkit-0.3.0-r2) amd64 `-- virtual/jre-1.8.0-r1 (>=virtual/jre-1.8) amd64 [ app-forensics/sleuthkit-4.6.0 stats: packages (20), max depth (1) ] * dependency graph for app-forensics/libewf-20171104 `-- app-forensics/libewf-20171104 ~amd64 `-- sys-libs/zlib-1.2.11-r1 (sys-libs/zlib) amd64 `-- sys-fs/fuse-2.9.7 (sys-fs/fuse) amd64 `-- sys-apps/util-linux-2.30.2-r1 (>=sys-apps/util-linux-2.16) amd64 `-- dev-libs/openssl-1.0.2n (dev-libs/openssl) amd64 `-- virtual/libintl-0-r2 (virtual/libintl) amd64 `-- virtual/libiconv-0-r2 (virtual/libiconv) amd64 `-- dev-libs/libuna-20170112_alpha (dev-libs/libuna) ~amd64 `-- app-forensics/libbfio-20170123 (app-forensics/libbfio) ~amd64 `-- dev-lang/python-2.7.14-r1 (>=dev-lang/python-2.7.5-r2) amd64 `-- dev-lang/python-3.4.5-r1 (dev-lang/python) amd64 `-- dev-lang/python-3.5.4-r1 (dev-lang/python) amd64 `-- dev-lang/python-exec-2.4.5 (>=dev-lang/python-exec-2) amd64 [python_targets_python2_7(-)? python_targets_python3_4(-)? python_targets_python3_5(-)? -python_single_target_python2_7(-) -python_single_target_python3_4(-) -python_single_target_python3_5(-)] `-- dev-libs/libcerror-20180102_beta (dev-libs/libcerror) ~amd64 `-- dev-libs/libcthreads-20170101_alpha (dev-libs/libcthreads) ~amd64 `-- dev-libs/libcaes-20170110_alpha (dev-libs/libcaes) ~amd64 `-- dev-libs/libcdata-20180102_alpha (dev-libs/libcdata) ~amd64 `-- dev-libs/libcdatetime-20170609_alpha (dev-libs/libcdatetime) ~amd64 `-- dev-libs/libclocale-20170105_alpha (dev-libs/libclocale) ~amd64 `-- dev-libs/libcnotify-20180102_beta (dev-libs/libcnotify) ~amd64 `-- dev-libs/libcsplit-20180103_beta (dev-libs/libcsplit) ~amd64 `-- dev-libs/libcfile-20170105_alpha (dev-libs/libcfile) ~amd64 `-- dev-libs/libcpath-20170108 (dev-libs/libcpath) ~amd64 `-- dev-libs/libfcache-20170111 (dev-libs/libfcache) ~amd64 `-- dev-libs/libfdata-20170112 (dev-libs/libfdata) ~amd64 `-- dev-libs/libfguid-20170112_alpha (dev-libs/libfguid) ~amd64 `-- dev-libs/libfvalue-20170113 (dev-libs/libfvalue) ~amd64 `-- dev-libs/libsmdev-20171112 (dev-libs/libsmdev) ~amd64 [ app-forensics/libewf-20171104 stats: packages (28), max depth (1) ] I don't expect such a plethora of ebuilds to land without a maintainer, yet I cannot promise comunity-level maintenance :-|
Initial version of libewf-20171104 now in the tree, but I'm not sure if I'm going to spend time unbundling/maintaining all the other libyal libs yet. If others want to, feel free to find some proxy maintainers and push ebuilds for the libs into the tree.
Maybe 20171104 version could be targetted instead :/
An automated check of this bug succeeded - the previous repoman errors are now resolved.
x86 stable
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=31825104c7336757b9018192ef878a0814878f08 commit 31825104c7336757b9018192ef878a0814878f08 Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2018-06-24 17:25:59 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2018-06-24 19:35:03 +0000 app-forensics/libewf: stable 20171104 for ppc, bug #634910 Bug: https://bugs.gentoo.org/634910 Package-Manager: Portage-2.3.40, Repoman-2.3.9 RepoMan-Options: --include-arches="ppc" app-forensics/libewf/libewf-20171104.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
amd64 stable
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=fa53618d0b353ee288eeab444e2e21af6d020790 commit fa53618d0b353ee288eeab444e2e21af6d020790 Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2018-07-20 22:23:04 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2018-07-20 22:23:57 +0000 app-forensics/libewf: stable 20171104 for hppa, bug #634910 Bug: https://bugs.gentoo.org/634910 Package-Manager: Portage-2.3.43, Repoman-2.3.10 RepoMan-Options: --include-arches="hppa" app-forensics/libewf/libewf-20171104.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Last arch. Closing.
