Bug#1024898: mozc: FTBFS on armel

[Gunnar Hjalmarsson]

Hi Nobuhiro,

On 2022-12-09 01:52, Nobuhiro Iwamatsu wrote:

Thanks for your help!

2022年12月9日(金) 9:03 Gunnar Hjalmarsson :

Under the assumption that it's better to have mozc without the
armel arch in testing than seeing mozc go away (see
), I'm about to do an NMU to
unstable where armel has been dropped from the lists of supported
architectures in d/control.


From the build log, the cause is Libatomic's link error. It is
possible to fix this.


Ah, great!


I will return Armel.


Ok. Since I uploaded in the meantime, I suppose that adding back armel 
may need to pass the NEW queue... Sorry for that inconvenience.


--
Cheers,
Gunnar

Bug#1024898: mozc: FTBFS on armel

[Nobuhiro Iwamatsu]

Hi,

Thanks for your help!

2022年12月9日(金) 9:03 Gunnar Hjalmarsson :
>
> On 2022-12-01 11:28, Gunnar Hjalmarsson wrote:
> > How important is it that mozc is available on armel? Would it be an
> > option to drop the armel support in bookworm?
>
> Under the assumption that it's better to have mozc without the armel
> arch in testing than seeing mozc go away (see
> ), I'm about to do an NMU to unstable
> where armel has been dropped from the lists of supported architectures
> in d/control.

>From the build log, the cause is Libatomic's link error. It is
possible to fix this.
I will return Armel.

Best regards,
  Nobuhiro

-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org / kernel.org}
   GPG ID: 32247FBB40AD1FA6

Bug#1024898: mozc: FTBFS on armel

[Gunnar Hjalmarsson]

On 2022-12-01 11:28, Gunnar Hjalmarsson wrote:

How important is it that mozc is available on armel? Would it be an
option to drop the armel support in bookworm?


Under the assumption that it's better to have mozc without the armel 
arch in testing than seeing mozc go away (see 
), I'm about to do an NMU to unstable 
where armel has been dropped from the lists of supported architectures 
in d/control.


--
Gunnar

Bug#1024898: mozc: FTBFS on armel

[Gunnar Hjalmarsson]

How important is it that mozc is available on armel? Would it be an 
option to drop the armel support in bookworm?


--
Gunnar

Bug#1024898: mozc: FTBFS on armel

[Gunnar Hjalmarsson]

In the hope that working around https://bugs.debian.org/1023525 would 
fix also this build failure on armel, I NMU'ed a workaround to experimental:


https://salsa.debian.org/debian/mozc/-/commit/cc5301a0

It made no difference wrt the armel FTBFS, though.

--
Gunnar Hjalmarsson

Bug#1024898: mozc: FTBFS on armel

[Sebastian Ramacher]

Source: mozc
Version: 2.28.4715.102+dfsg-2
Severity: serious
Tags: ftbfs sid bookworm
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=mozc&arch=armel&ver=2.28.4715.102%2Bdfsg-2&stamp=1669203429&raw=0

FAILED: ibus_mozc 
/usr/bin/g++ -Wl,-z,relro -Wl,--as-needed -lstdc++ -pthread -o ibus_mozc 
-Wl,--start-group obj/unix/ibus/ibus_mozc.main.o obj/base/libbase.a 
obj/base/libversion.a obj/unix/ibus/libibus_mozc_lib.a 
obj/unix/ibus/libibus_mozc_metadata.a obj/base/libbase_core.a 
obj/base/libclock.a obj/base/libsingleton.a obj/base/libhash.a 
obj/base/libnumber_util.a obj/base/libjapanese_util.a obj/client/libclient.a 
obj/ipc/libipc.a obj/ipc/libipc_protocol.a obj/protocol/libcommands_proto.a 
obj/protocol/libcandidates_proto.a obj/protocol/libconfig_proto.a 
obj/protocol/libengine_builder_proto.a 
obj/protocol/libuser_dictionary_storage_proto.a 
obj/session/libime_switch_util.a obj/config/libconfig_handler.a 
obj/base/libconfig_file_stream.a obj/session/libkey_info_util.a 
obj/composer/libkey_event_util.a obj/composer/libkey_parser.a 
obj/session/libkeymap.a obj/unix/ibus/libibus_config_proto.a 
obj/unix/ibus/libibus_property_handler.a obj/unix/ibus/libmessage_translator.a 
obj/unix/ibus/libpath_util.a obj/protocol/librenderer_proto.a 
obj/unix/ibus/libgtk_candidate_window_handler.a 
obj/renderer/librenderer_client.a obj/unix/ibus/libselection_monitor.a  
-libus-1.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lxcb -lxcb-xfixes -labsl_base 
-labsl_int128 -labsl_base -labsl_hash -labsl_city -labsl_flags_reflection 
-labsl_raw_hash_set -labsl_str_format_internal -labsl_throw_delegate 
-labsl_time_zone -labsl_hashtablez_sampler -labsl_synchronization -labsl_time 
-labsl_strings_internal -labsl_strings -labsl_spinlock_wait -labsl_status 
-labsl_statusor -labsl_flags_internal -labsl_flags_usage_internal 
-labsl_flags_marshalling -labsl_flags_parse -lprotobuf -Wl,--end-group
/usr/bin/ld: obj/unix/ibus/ibus_mozc.main.o: undefined reference to symbol 
'__atomic_load_8@@LIBATOMIC_1.0'
/usr/bin/ld: /usr/lib/arm-linux-gnueabi/libatomic.so.1: error adding symbols: 
DSO missing from command line
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.
Traceback (most recent call last):
  File "/<>/src/build_mozc.py", line 892, in 
sys.exit(main())
  File "/<>/src/build_mozc.py", line 877, in main
BuildMain(cmd_opts, cmd_args)
  File "/<>/src/build_mozc.py", line 617, in BuildMain
BuildWithNinja(options, targets)
  File "/<>/src/build_mozc.py", line 591, in BuildWithNinja
RunOrDie([ninja, '-v', '-C', build_arg, target_name])
  File "/<>/src/build_tools/util.py", line 96, in RunOrDie
raise RunOrDieError('\n'.join(['',
build_tools.util.RunOrDieError: 
==
 ERROR: ninja -v -C out_linux/Release ibus_mozc
==
make[1]: *** [debian/rules:44: build_dynamic_link] Error 1
make[1]: Leaving directory '/<>'
make: *** [debian/rules:30: build-arch] Error 2
dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
status 2

Cheers
-- 
Sebastian Ramacher