CdioList_t * iso9660_fs_readdir (CdIo_t *p_cdio, const char psz_path[]); ^~~~~~~~~~~~~~~~~~ /var/tmp/portage/media-video/vcdimager-0.7.24/work/vcdimager-0.7.24/lib/info.c:144:3: error: too few arguments to function ‘_cdio_list_free’ _cdio_list_free (entlist, true); ^~~~~~~~~~~~~~~ In file included from /var/tmp/portage/media-video/vcdimager-0.7.24/work/vcdimager-0.7.24/lib/info_private.h:34:0, ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 17.0-desktop_libressl_20171211-202647 ------------------------------------------------------------------- gcc-config -l: [1] x86_64-pc-linux-gnu-7.2.0 * Available Python interpreters, in order of preference: [1] python3.5 [2] python2.7 (fallback) [3] jython2.7 (fallback) Available Ruby profiles: [1] ruby22 (with Rubygems) * java-config: The following VMs are available for generation-2: *) IcedTea JDK 3.6.0 [icedtea-bin-8] Available Java Virtual Machines: [1] icedtea-bin-8 system-vm emerge -qpv media-video/vcdimager [ebuild N ] media-video/vcdimager-0.7.24 USE="xml -static-libs" ABI_X86="(64) -32 (-x32)"
Created attachment 510654 [details] emerge-info.txt
Created attachment 510656 [details] emerge-history.txt
Created attachment 510658 [details] environment
Created attachment 510660 [details] etc.portage.tbz2
Created attachment 510662 [details] logs.tbz2
Created attachment 510664 [details] media-video:vcdimager-0.7.24:20171218-102542.log
Created attachment 510666 [details] temp.tbz2
Upstream Bugreport: https://savannah.gnu.org/support/?109436
Created attachment 513106 [details] New ebuild with patches Patches fix the build issues, totally untested apart from building.
(In reply to Luke A. Guest from comment #9) > Created attachment 513106 [details] > New ebuild with patches > > Patches fix the build issues, totally untested apart from building. I know you grabbed those patches from the bug reports upstream, but should be passing NULL as the function pointer for the free callback there? Won't that create a memory leak? Granted, this changelog: http://git.savannah.gnu.org/cgit/libcdio.git/commit/?id=73800fc0cd81a735764f79b7f3f957d8a71eb02c shows some invocations of that free call with a NULL function pointer but for many there are a few different free functions being used. Maybe it's stack memory that call this with NULL and heap with a free callback?
(In reply to Adam Stylinski from comment #10) > (In reply to Luke A. Guest from comment #9) > > Created attachment 513106 [details] > > New ebuild with patches > > > > Patches fix the build issues, totally untested apart from building. > > I know you grabbed those patches from the bug reports upstream, but should > be passing NULL as the function pointer for the free callback there? Won't > that create a memory leak? Granted, this changelog: > http://git.savannah.gnu.org/cgit/libcdio.git/commit/ > ?id=73800fc0cd81a735764f79b7f3f957d8a71eb02c shows some invocations of that > free call with a NULL function pointer but for many there are a few > different free functions being used. Maybe it's stack memory that call this > with NULL and heap with a free callback? After further examining the code, the real fix (to be compatible with what was done before) is to specify the free function as the function pointer. It looks like the old behavior would just call free directly after dereferencing the non-NULL node pointer.
(In reply to Adam Stylinski from comment #10) > (In reply to Luke A. Guest from comment #9) > > Created attachment 513106 [details] > > New ebuild with patches > > > > Patches fix the build issues, totally untested apart from building. > > I know you grabbed those patches from the bug reports upstream, but should I didn't actually. I didn't see any patches in the above link. > be passing NULL as the function pointer for the free callback there? Won't If there's no callback for the allocation, I see no point of one in the free. > that create a memory leak? Granted, this changelog: > http://git.savannah.gnu.org/cgit/libcdio.git/commit/ > ?id=73800fc0cd81a735764f79b7f3f957d8a71eb02c shows some invocations of that > free call with a NULL function pointer but for many there are a few > different free functions being used. Maybe it's stack memory that call this > with NULL and heap with a free callback?
AFAIK this is caused by API changes in dev-libs/libcdio-1.1.0 and higher See Bug #638646 and comment https://bugs.gentoo.org/638646#c27 Masking =dev-libs/libcdio-1.1.0 and =dev-libs/libcdio-2.0.0 works for me.
The patch from Luke A. Guest works (~x86 box)
Could you at least update the vcdimager ebuild to require libcdio:0/17? Slot dependency will temporarily solve this bug until vcdimager gets updated to the new API.
(In reply to Martin Doucha from comment #15) > Could you at least update the vcdimager ebuild to require libcdio:0/17? Slot > dependency will temporarily solve this bug until vcdimager gets updated to > the new API. I would rather consider to update the patches of the current ebuild to make it compatible with the recent libcdio.
I can confirm that the new ebuild compiles vcdimager, but I get this QA Notice: * QA Notice: Package triggers severe warnings which indicate that it * may exhibit random runtime failures. * /tmp/portage/media-video/vcdimager-0.7.24/work/vcdimager-0.7.24/frontends/cli/vcdimager.c:413:19: warning: implicit declaration of function ‘strptime’; did you mean ‘strftime’? [-Wimplicit-function-declaration] * /tmp/portage/media-video/vcdimager-0.7.24/work/vcdimager-0.7.24/frontends/xml/vcd_xml_build.c:478:14: warning: implicit declaration of function ‘strptime’; did you mean ‘strftime’? [-Wimplicit-function-declaration] * Please do not file a Gentoo bug and instead report the above QA * issues directly to the upstream developers of this software. * Homepage: http://www.vcdimager.org/
(In reply to Petross404(Petros S) from comment #17) > I can confirm that the new ebuild compiles vcdimager, but I get this QA > Notice: > > * QA Notice: Package triggers severe warnings which indicate that it > * may exhibit random runtime failures. > * > /tmp/portage/media-video/vcdimager-0.7.24/work/vcdimager-0.7.24/frontends/ > cli/vcdimager.c:413:19: warning: implicit declaration of function > ‘strptime’; did you mean ‘strftime’? [-Wimplicit-function-declaration] > * > /tmp/portage/media-video/vcdimager-0.7.24/work/vcdimager-0.7.24/frontends/ > xml/vcd_xml_build.c:478:14: warning: implicit declaration of function > ‘strptime’; did you mean ‘strftime’? [-Wimplicit-function-declaration] > > * Please do not file a Gentoo bug and instead report the above QA > * issues directly to the upstream developers of this software. > * Homepage: http://www.vcdimager.org/ I attach a patch for that. Only applies after other patches in this bug.
Created attachment 515720 [details, diff] implicit declaration of strptime fix Applies cleanly only after libcdio-1 and libcdio-2 patches applied.
(In reply to Luke A. Guest from comment #12) > (In reply to Adam Stylinski from comment #10) > > (In reply to Luke A. Guest from comment #9) > > > Created attachment 513106 [details] > > > New ebuild with patches > > > > > > Patches fix the build issues, totally untested apart from building. > > > > I know you grabbed those patches from the bug reports upstream, but should > > I didn't actually. I didn't see any patches in the above link. > > > be passing NULL as the function pointer for the free callback there? Won't > > If there's no callback for the allocation, I see no point of one in the free. > > > that create a memory leak? Granted, this changelog: > > http://git.savannah.gnu.org/cgit/libcdio.git/commit/ > > ?id=73800fc0cd81a735764f79b7f3f957d8a71eb02c shows some invocations of that > > free call with a NULL function pointer but for many there are a few > > different free functions being used. Maybe it's stack memory that call this > > with NULL and heap with a free callback? The old behavior actually did call free - this one does not (it calls whatever callback you've specified if it's non-null and exits otherwise).
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=36118ca20461b5421246550de2b2af247b5cec7b commit 36118ca20461b5421246550de2b2af247b5cec7b Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2018-04-07 20:32:14 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2018-04-07 20:48:48 +0000 media-video/vcdimager: 2.0.1 version bump Bug: https://bugs.gentoo.org/641550 Closes: https://bugs.gentoo.org/641470 Package-Manager: Portage-2.3.28, Repoman-2.3.9 media-video/vcdimager/Manifest | 1 + media-video/vcdimager/vcdimager-2.0.1.ebuild | 57 ++++++++++++++++++++++++++++ 2 files changed, 58 insertions(+)}
The fix may or may not have fixed =media-video/vcdimager-2.0.1, but it most certainly did not fix =media-video/vcdimager-0.7.24. I just had my existing packages broken in stable, because =dev-libs/libcdio-2.0.0-r1 has been marked stable and =media-video/vcdimager-0.7.24 does not know it needs to depend on <1.0. vcdimager-0.7.24 is marked stable and breaks with the new stable version of libcdio, 2.0.0-r1. Please do as comment #15 suggested and alter the dependencies of =media-video/vcdimager-0.7.24 so it doesn't try to build with the new incompatible version of libcdio. Either that, or divide libcdio into slots... Making all in lib make[2]: Entering directory '/var/tmp/portage/media-video/vcdimager-0.7.24/work/vcdimager-0.7.24-abi_x86_32.x86/lib' /bin/sh ../libtool --tag=CC --mode=compile x86_64-pc-linux-gnu-gcc -m32 -DHAVE_CONFIG_H -I. -I/var/tmp/portage/media-video/vcdimager-0.7.24/work/vcdimager-0.7.24/lib -I.. -I/var/tmp/portage/media-video/vcdimager-0.7.24/work/vcdimager-0.7.24/include/ -I/var/tmp/portage/media-video/vcdimager-0.7.24/work/vcdimager-0.7.24/lib/ -O2 -march=native -mmmx -mpopcnt -msse -msse2 -msse3 -msse4.1 -msse4.2 -mssse3 -mavx -maes -mfpmath=sse -pipe -fno-stack-protector -Wall -Wchar-subscripts -Wmissing-prototypes -Wmissing-declarations -Wunused -Wpointer-arith -Wwrite-strings -Wnested-externs -Wno-sign-compare -c -o info.lo /var/tmp/portage/media-video/vcdimager-0.7.24/work/vcdimager-0.7.24/lib/info.c libtool: compile: x86_64-pc-linux-gnu-gcc -m32 -DHAVE_CONFIG_H -I. -I/var/tmp/portage/media-video/vcdimager-0.7.24/work/vcdimager-0.7.24/lib -I.. -I/var/tmp/portage/media-video/vcdimager-0.7.24/work/vcdimager-0.7.24/include/ -I/var/tmp/portage/media-video/vcdimager-0.7.24/work/vcdimager-0.7.24/lib/ -O2 -march=native -mmmx -mpopcnt -msse -msse2 -msse3 -msse4.1 -msse4.2 -mssse3 -mavx -maes -mfpmath=sse -pipe -fno-stack-protector -Wall -Wchar-subscripts -Wmissing-prototypes -Wmissing-declarations -Wunused -Wpointer-arith -Wwrite-strings -Wnested-externs -Wno-sign-compare -c /var/tmp/portage/media-video/vcdimager-0.7.24/work/vcdimager-0.7.24/lib/info.c -fPIC -DPIC -o .libs/info.o /var/tmp/portage/media-video/vcdimager-0.7.24/work/vcdimager-0.7.24/lib/info.c: In function ‘_init_segments’: /var/tmp/portage/media-video/vcdimager-0.7.24/work/vcdimager-0.7.24/lib/info.c:109:13: error: too many arguments to function ‘iso9660_fs_readdir’ entlist = iso9660_fs_readdir(p_obj->img, "SEGMENT", true); ^~~~~~~~~~~~~~~~~~ In file included from /var/tmp/portage/media-video/vcdimager-0.7.24/work/vcdimager-0.7.24/lib/info_private.h:35:0, from /var/tmp/portage/media-video/vcdimager-0.7.24/work/vcdimager-0.7.24/lib/info.c:28: /usr/include/cdio/iso9660.h:1060:14: note: declared here CdioList_t * iso9660_fs_readdir (CdIo_t *p_cdio, const char psz_path[]); ^~~~~~~~~~~~~~~~~~ /var/tmp/portage/media-video/vcdimager-0.7.24/work/vcdimager-0.7.24/lib/info.c:144:3: error: too few arguments to function ‘_cdio_list_free’ _cdio_list_free (entlist, true); ^~~~~~~~~~~~~~~ In file included from /var/tmp/portage/media-video/vcdimager-0.7.24/work/vcdimager-0.7.24/lib/info_private.h:34:0, from /var/tmp/portage/media-video/vcdimager-0.7.24/work/vcdimager-0.7.24/lib/info.c:28: /usr/include/cdio/ds.h:46:6: note: declared here void _cdio_list_free (CdioList_t *p_list, int free_data, CdioDataFree_t free_fn); ^~~~~~~~~~~~~~~
