On Fri, Jan 28, 2022 at 08:29:36AM -0700, Neil Mayhew wrote:
> On 2022-01-28 07:59, tony mancill wrote:
> > it is surprising to see it fail with this:
> > > /<<PKGBUILDDIR>>/cpp/src/phonenumbers/geocoding/geocoding_data.cc:787278:13:
> > > error: ‘i18n::phonenumbers::{anonymous}::prefix_86_zh_descriptions’
> > > defined but not used [-Werror=unused-variable]
> > > 787278 | const char* prefix_86_zh_descriptions[] = {
> > > | ^~~~~~~~~~~~~~~~~~~~~~~~~
> > > cc1plus: all warnings being treated as errors
> > > make[3]: *** [CMakeFiles/geocoding-shared.dir/build.make:353:
> > > CMakeFiles/geocoding-shared.dir/src/phonenumbers/geocoding/geocoding_data.cc.o]
> > > Error 1
>
> That's not the original error, which is this:
>
> > [ 35%] Building CXX object
> > CMakeFiles/phonenumber_testing.dir/src/phonenumbers/logger.cc.o
> > /usr/bin/c++ -DI18N_PHONENUMBERS_USE_ALTERNATE_FORMATS
> > -DI18N_PHONENUMBERS_USE_ICU_REGEXP
> > -DI18N_PHONENUMBERS_USE_TR1_UNORDERED_MAP -I/<<PKGBUILDDIR>>/cpp/src
> > -I/<<PKGBUILDDIR>>/cpp/test -pthread -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2
> > -ffile-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat
> > -Werror=format-security -fPIC -Wall -Werror -std=gnu++11 -MD -MT
> > CMakeFiles/phonenumber_testing.dir/src/phonenumbers/logger.cc.o -MF
> > CMakeFiles/phonenumber_testing.dir/src/phonenumbers/logger.cc.o.d -o
> > CMakeFiles/phonenumber_testing.dir/src/phonenumbers/logger.cc.o -c
> > /<<PKGBUILDDIR>>/cpp/src/phonenumbers/logger.cc
> > /<<PKGBUILDDIR>>/cpp/src/phonenumbers/geocoding/geocoding_data.cc:888498:
> > error: expected ‘}’ at end of input
> > 888498 |
> > "\xe5""\x9b""\x9b""\xe5""\xb7""\x9d""\xe7""\x9c""\x81""\xe8""\x87""\xaa""\xe8""\xb4""\xa1""\xe5""\xb8""\x82",
> > |
> > /<<PKGBUILDDIR>>/cpp/src/phonenumbers/geocoding/geocoding_data.cc:787278:43:
> > note: to match this ‘{’
> > 787278 | const char* prefix_86_zh_descriptions[] = {
> > | ^
>
> It looks like geocoding_data.cc is truncated and my working hypothesis is
> that it's still in the process of being generated, which in turn is due to
> race condition in the parallel build. This could explain why it built
> successfully on some architectures and not others.Got it - thank you. I checked and the amd64 buildd is using DEB_BUILD_OPTIONS=parallel=4 whereas my local build uses parallel=8. Since I'm not able to reproduce locally, I'm considering setting parallel=1 for the next upload. Thoughts? Thank you, tony
signature.asc
Description: PGP signature
