[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: arm64 port blocking packages - help welcome



peter green wrote:
Wookey wrote:
Time is very short for bootstrapping arm64 in time for Jessie so
anyone who can help out is very welcome. (I'm now pre-occupied with
prep for the bootstrap/cross sprint next weekend so have run out of
time for much more poking on this until debconf).

Here is a summary of the status of the top 10:

TL;DR. Someone Please look at qt4-x11 -fpermissive issue, libwebp neon issue, openjade autoconf issue
If we fix those I believe the whole SCC should be buildable.

* libwebp
Newly appeared in SCC. Failing to build neon-related files. Needs investigation.
After looking arround in the very confusing paralell build log I found

enc_neon.c: In function 'FTransformWHT':
enc_neon.c:542:1: internal compiler error: in simplify_const_unary_operation, at simplify-rtx.c:1539
}
^
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-4.9/README.Bugs> for instructions.

Doing some googling reveals a gcc upstream bug that seems to be relavent

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61622

The gcc upstream bug is marked as a regression in 4.9 and debian-ports arm64 built libwebp successfully in the past when 4.8 was the default compiler. So building with 4.8 may be a temporary soloution. Trying that now.
Ok, seems I misread the upstream bug report, it seems "4.8 regression"
means a regression in 4.8 not a regression from 4.8. Furthermore that
bug report is marked as a dupe of one that has been fixed in 4.9 for a
while. So I don't think it's our issue. Also my test with 4.8 resulted
in an ICE. 4.7 succeeds on the problem files.

I filed a bug report on the debian gcc-4.9 package.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=757738

I then attempted a build of the libwebp package with gcc-4.7. Unfortunately that failed with another error.

libtool: compile:  gcc-4.7 -DHAVE_CONFIG_H -I. -I../../src/webp -D_FORTIFY_SOURCE=2 -Wall -Wdeclaration-after-statement -Wextra -Wmissing-declarations -Wmissing-prototypes -Wold-style-definition -Wshadow -Wunused-but-set-variable -Wunused -Wvla -g -O2 -Wformat -Werror=format-security -fstack-protector -pthread -c upsampling_neon.c  -fPIC -DPIC -o .libs/libwebpdsp_la-upsampling_neon.o
upsampling_neon.c:1:0: warning: -fstack-protector not supported for this target [enabled by default]
upsampling_neon.c: In function 'UpsampleRgbLinePair':
upsampling_neon.c:234:1: error: incompatible types when initializing type 'int32x4_t' using type 'int32x2_t'
upsampling_neon.c:234:1: error: incompatible types when initializing type 'int32x4_t' using type 'int32x2_t'
upsampling_neon.c:234:1: error: incompatible types when initializing type 'int32x4_t' using type 'int32x2_t'
upsampling_neon.c:234:1: error: incompatible types when initializing type 'int32x4_t' using type 'int32x2_t'
upsampling_neon.c: In function 'UpsampleBgrLinePair':
upsampling_neon.c:235:1: error: incompatible types when initializing type 'int32x4_t' using type 'int32x2_t'
upsampling_neon.c:235:1: error: incompatible types when initializing type 'int32x4_t' using type 'int32x2_t'
upsampling_neon.c:235:1: error: incompatible types when initializing type 'int32x4_t' using type 'int32x2_t'
upsampling_neon.c:235:1: error: incompatible types when initializing type 'int32x4_t' using type 'int32x2_t'
upsampling_neon.c: In function 'UpsampleRgbaLinePair':
upsampling_neon.c:236:1: error: incompatible types when initializing type 'int32x4_t' using type 'int32x2_t'
upsampling_neon.c:236:1: error: incompatible types when initializing type 'int32x4_t' using type 'int32x2_t'
upsampling_neon.c:236:1: error: incompatible types when initializing type 'int32x4_t' using type 'int32x2_t'
upsampling_neon.c:236:1: error: incompatible types when initializing type 'int32x4_t' using type 'int32x2_t'
upsampling_neon.c: In function 'UpsampleBgraLinePair':
upsampling_neon.c:237:1: error: incompatible types when initializing type 'int32x4_t' using type 'int32x2_t'
upsampling_neon.c:237:1: error: incompatible types when initializing type 'int32x4_t' using type 'int32x2_t'
upsampling_neon.c:237:1: error: incompatible types when initializing type 'int32x4_t' using type 'int32x2_t'
upsampling_neon.c:237:1: error: incompatible types when initializing type 'int32x4_t' using type 'int32x2_t'
Makefile:634: recipe for target 'libwebpdsp_la-upsampling_neon.lo' failed
make[4]: *** [libwebpdsp_la-upsampling_neon.lo] Error 1
make[4]: Leaving directory '/libwebp-0.4.1/src/dsp'
Makefile:585: recipe for target 'all-recursive' failed
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory '/libwebp-0.4.1/src'
Makefile:409: recipe for target 'all-recursive' failed
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory '/libwebp-0.4.1'
dh_auto_build: make -j1 returned exit code 2
debian/rules:30: recipe for target 'build-arch' failed
make[1]: *** [build-arch] Error 2
make[1]: Leaving directory '/libwebp-0.4.1'
debian/rules:30: recipe for target 'build' failed
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2
root@debian:/libwebp-0.4.1#

Seems that this file will build with 4.9 but not with 4.7 or 4.8

Ok plan B, switching to an older compiler didn't work but turning off optimisation looks promising.


Reply to: