Re: Fwd: Bug#1050663: dar option --on-fly-isolate creates catalogue with broken slice_layout

Hi Denis!

Huge thanks for your time. I stressed the compiler this evening, too.
See my findings below.

On Tue, Aug 29, 2023 at 10:42:31PM +0200, Denis Corbin wrote:
> On 29/08/2023 04:50, John Goerzen wrote:
> > On Mon, Aug 28 2023, Denis Corbin wrote:
> > 
> > > I could not reproduce it with neither 2.7.9 nor 2.7.10 on my system. Will try
> > > under Debian to see what's wrong, keep you informed.
> > 
> > Interestingly, I could duplicate this with the dar version in
> > bookworm-backports, but not with the one in sid.  Both are 2.7.10.
> > That's odd!
> 
> Thanks for that, I have installed a pristine Debian 12 adding the backports
> repo and I could reproduce it:
> - first using the Debian provided binary
> - then using the deb-src package and compiling the provided source code
>   (which include tiny and harmless patch to adapt to Debian rules)
> - then using the upstream source code alone
> 
> The problem disappears just removing the default compilation -O2 options:

I will try this option tomorrow. I compiled today v2.7.8, v2.7.9 and
v2.7.11 on my Debian testing and _all_ versions fail the onflytest. So I
think, too, there is something outside the source which influences.

> export LDFLAGS=-g
> export CFLAGS=-g
> export CXXFLAGS=-g
> ./configure
> make

my compile flags:
./configure --prefix=/home/thomas/tmp/dar_compile/inst_temp --disable-build-html --disable-libargon2-linking --disable-libcurl-linking --disable-gpgme-linking --disable-libgcrypt-linking

> The problem also disappear when replacing gcc-12 by the clang 14 compiler.

I use the static version for my tests to eliminate accidentally loading
of dynamic libraries from the OS.

$ /home/thomas/tmp/dar_compile/inst_temp/bin/dar_static -V
 dar_static version 2.7.11, Copyright (C) 2002-2023 Denis Corbin
[...]
 compiled the Aug 29 2023 with GNUC version 13.1.0
 dar_static is part of the Disk ARchive suite (Release 2.7.11)

> I can't troubleshoot any further, as I need to remove the default
> optimization options, to step in the execution (else it is really difficult
> to link binary to source code, gdb is lost most of the time)
> 
> As far as I can understand, problem seems coming from gcc-12 and not the
> linking process (ld) nor external library nor Debian added patches nor the
> upstream source code.
> 
> > 
> > On the Debian side:
> > 
> > - In dar 2.7.9-1, I enabled librsync support, and required libcap-dev and
> >    libnsl-dev.
> > 
> > - In dar 2.7.9-2, I enabled libthreadar, curl, and OpenSSL support.
> > 
> > - In 2.7.10-1, I enabled building the Python bindings.
> > 
> > I don't immediately see how any of these could be relevant here, but
> > thought I'd mention in case it's a clue.
> 
> I would check the output of "dar -V", which reports the compiler used: I
> hope this will  confirm the link with gcc-12.

As mentioned above with GNUC v13 it does not work either. I try
tommorrow compiling without optimization.

Regards,
Tom

PS: Denis, thanks for your superb documentation. Everthing was in place
from the first git clone to the make install. I had no problems att all
follow your instructions.