Bug#969260: openfjx: FTBFS (gstreamer)

Chris Knadle Chris.Knadle at coredump.us
Sat Sep 12 06:28:03 BST 2020


tony mancill:
> Hi Chris!

Hello again Tony :)

> On Sat, Sep 05, 2020 at 05:43:17AM +0000, Chris Knadle wrote:
>> Chris Knadle:
>>> For what it's worth, I used a clean cowbuilder sid chroot that was fully
>>> upgraded to build openjfx 11.0.7+0-4 and the package built fine. The build log
>>> is about 808kB -- I'll send it to the bug report if desired. Offhand I'm not
>>> sure what's going on either. It's probably wishful thinking that the cowbuilder
>>> build log will be comparable to the buildd build logs, but I'll have a look.
>>
>> Okay, I've compared the cowbuilder logs and the buildd logs and there are a
>> number of differences, and to me it looks like buildd might be using gcc-10
>> where my cowbuilder build may not be. The buildd logs show many warning/error
>> lines of variables "first defined here" and that's indicative of a gcc-10
>> problem, along with many other errors and warnings that the cowbuilder build
>> didn't show.
>>
>> I was given some hints about this in bug #957546:
>>
>>    Common build failures are new warnings resulting in build failures with
>>    -Werror turned on, or new/dropped symbols in Debian symbols files.
>>    For other C/C++ related build failures see the porting guide at
>>    http://gcc.gnu.org/gcc-10/porting_to.html
> 
> Thank you for taking a look at this.  I suspect that you're on to
> something with gcc-10, but if that's the case, I'm worried about my
> entire build toolchain with respect to gcc-10 bugs.  Just to be sure, I
> created a fresh chroot with:
> 
>    sudo sbuild-createchroot sid /path/to/chroot
> 
> And the package still builds correctly for me, and "gcc -v" in that
> chroot shows gcc 10.2:
> 
> $ schroot -c sid-amd64-sbuild -u root
> (sid-amd64-sbuild)root at lark:~# gcc -v
> Using built-in specs.
> COLLECT_GCC=gcc
> COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/10/lto-wrapper
> OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa:hsa
> OFFLOAD_TARGET_DEFAULT=1
> Target: x86_64-linux-gnu
> Configured with: ../src/configure -v --with-pkgversion='Debian 10.2.0-6' --with-bugurl=file:///usr/share/doc/gcc-10/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-10 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none=/build/gcc-10-OZNiN5/gcc-10-10.2.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-10-OZNiN5/gcc-10-10.2.0/debian/tmp-gcn/usr,hsa --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
> Thread model: posix
> Supported LTO compression algorithms: zlib zstd
> gcc version 10.2.0 (Debian 10.2.0-6)

I got the *exact* same output from cowbuilder when checking 'gcc -v' -- I
literally copied the above from your email, copied the output from 'gcc -v' in
my cowbuilder chroot, ran 'diff -u' on the files, and came back identical.

So ... yeah ... I also don't quite know what's going on either. I /suspect/ it's
a GCC-10 issue because of the particular warning/error messages, so it seems to
make _sense_ that it would be some GCC-10 issue, however both your and my local
build chroots should be using GCC-10 and build fine. So ... ?

> So I'm confused about what's different on the buildd system.  I will
> keep poking at it.

Something to try if you've got time:
Try doing a "colordiff -u" on the log output from your successful sbuild vs the
failed sbuild output from the buildd's; that should give a colorized output of
where there are differences in lines, and maybe there will be a hint as to
something that's different on the buildd's, like different GCC options, and also
where the build "starts to go wrong".

Maybe you've done that already, but if not that might give us some hints.
I'm building an sbuild chroot and will see if I can poke at this some also.

   -- Chris

-- 
Chris Knadle
Chris.Knadle at coredump.us


More information about the pkg-java-maintainers mailing list