Re: [gentoo-user] haven't been able to build android-tools for months [ RESOLVED ]

[n952162]

On 9/6/21 11:04 PM, cal wrote:

On 9/6/21 12:23 PM, n952162 wrote:


Given the error message implies a compiler error, perhaps try upgrading
sys-devel/gcc first?


Aggh!

00~/adm/gentoo/emerged>eselect gcc list
  [1] x86_64-pc-linux-gnu-9.3.0 *
  [2] x86_64-pc-linux-gnu-10.3.0


$ eselect news list | grep gcc

doesn't turn up anything.  When should/may one upgrade?

Thank you for the tip!   That's surely what's going on.

https://wiki.gentoo.org/wiki/Upgrading_GCC (note: most of the content
here appears to be related to upgrading to GCC 5.x).

Like the kernel, new versions of GCC are automatically pulled in, but
you have to eselect the new one manually (I don't know the reason; I
assume it is to avoid leaving the user with a broken compiler).
Personally, I just check the emerge output to see if a new version of
GCC was merged, and if so, I eselect it and rebuild libtool as described
on the wiki.

cal



Yes, that fixed it, thank you.  I have to read about libtool now, though.

Re: [gentoo-user] haven't been able to build android-tools for months

[cal]

On 9/6/21 12:23 PM, n952162 wrote:

>>
>> Given the error message implies a compiler error, perhaps try upgrading
>> sys-devel/gcc first?
>>
> 
> Aggh!
> 
> 00~/adm/gentoo/emerged>eselect gcc list
>  [1] x86_64-pc-linux-gnu-9.3.0 *
>  [2] x86_64-pc-linux-gnu-10.3.0
> 
> 
> $ eselect news list | grep gcc
> 
> doesn't turn up anything.  When should/may one upgrade?
> 
> Thank you for the tip!   That's surely what's going on.

https://wiki.gentoo.org/wiki/Upgrading_GCC (note: most of the content
here appears to be related to upgrading to GCC 5.x).

Like the kernel, new versions of GCC are automatically pulled in, but
you have to eselect the new one manually (I don't know the reason; I
assume it is to avoid leaving the user with a broken compiler).
Personally, I just check the emerge output to see if a new version of
GCC was merged, and if so, I eselect it and rebuild libtool as described
on the wiki.

cal

Re: [gentoo-user] haven't been able to build android-tools for months

[antlists]

On 06/09/2021 20:23, n952162 wrote:

Aggh!

00~/adm/gentoo/emerged>eselect gcc list
  [1] x86_64-pc-linux-gnu-9.3.0 *
  [2] x86_64-pc-linux-gnu-10.3.0


$ eselect news list | grep gcc

doesn't turn up anything.  When should/may one upgrade?

Thank you for the tip!   That's surely what's going on.


Others may chime in and say I'm wrong, but my immediate reaction would 
be an "eselect gcc set 2" to upgrade the active gcc. An "emerge 
--depclean" without that could easily leave you with a broken system - 
probably easy enough to fix but still a nightmare until you realise 
what's happened ...


If there's no news, then the change *should* not be a problem.

And if you're at all worried, follow that with an "emerge -e @system". 
Provide it runs successfully ... you will have a working system, even if 
bits of it break. Only downside, it will probably take quite a while to 
run ...


Cheers,
Wol

Re: [gentoo-user] haven't been able to build android-tools for months

[n952162]

On 9/6/21 8:19 PM, cal wrote:

On 9/6/21 11:14 AM, n952162 wrote:

On any of my 7 gentoo machines:

FAILED: ^[[0mvendor/CMakeFiles/libbase.dir/libbase/logging.cpp.o
/usr/bin/x86_64-pc-linux-gnu-g++  -Ivendor
-I/var/tmp/portage/dev-util/android-tools-31.0.0_p1/work/android-tools-31.0.0p1/vendor/libbase/include

-I/var/tmp/portage/dev-util/android-tools-31.0.0_p1/work/android-tools-31.0.0p1/vendor/core/include

-I/var/tmp/portage/dev-util/android-tools-31.0.0_p1/work/android-tools-31.0.0p1/vendor/logging/liblog/include

-O2 -pipe -std=gnu++2a -Wno-attributes -D_FILE_OFFSET_BITS=64 -MD -MT
vendor/CMakeFiles/libbase.dir/libbase/logging.cpp.o -MF
vendor/CMakeFiles/libbase.dir/libbase/logging.cpp.o.d -o
vendor/CMakeFiles/libbase.dir/libbase/logging.cpp.o -c
/var/tmp/portage/dev-util/android-tools-31.0.0_p1/work/android-tools-31.0.0p1/vendor/libbase/logging.cpp

during RTL pass: expand
/var/tmp/portage/dev-util/android-tools-31.0.0_p1/work/android-tools-31.0.0p1/vendor/libbase/logging.cpp:

In member function â~@~Xvoid
android::base::LogdLogger::operator()(android::base::LogId,
android::base::LogSeverity, const char*, const char*, unsigned int,
const char*)â~@~Y:
/var/tmp/portage/dev-util/android-tools-31.0.0_p1/work/android-tools-31.0.0p1/vendor/libbase/logging.cpp:330:6:

internal compiler error: in expand_expr_real_1, at expr.c:10012
   330 | void LogdLogger::operator()(LogId id, LogSeverity severity,
const char* tag, const char* file,
   |  ^~
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
[107/659] /usr/bin/x86_64-pc-linux-gnu-g++  -Ivendor
-I/var/tmp/portage/dev-util/android-tools-31.0.0_p1/work/android-tools-31.0.0p1/vendor/libbase/include

-I/var/tmp/portage/dev-util/android-tools-31.0.0_p1/work/android-tools-31.0.0p1/vendor/core/include

-I/var/tmp/portage/dev-util/android-tools-31.0.0_p1/work/android-tools-31.0.0p1/vendor/logging/liblog/include

-O2 -pipe -std=gnu++2a -Wno-attributes -D_FILE_OFFSET_BITS=64 -MD -MT
vendor/CMakeFiles/libbase.dir/libbase/mapped_file.cpp.o -MF
vendor/CMakeFiles/libbase.dir/libbase/mapped_file.cpp.o.d -o
vendor/CMakeFiles/libbase.dir/libbase/mapped_file.cpp.o -c
/var/tmp/portage/dev-util/android-tools-31.0.0_p1/work/android-tools-31.0.0p1/vendor/libbase/mapped_file.cpp

ninja: build stopped: subcommand failed.
  * ERROR: dev-util/android-tools-31.0.0_p1::gentoo failed (compile phase):
  *   ninja -v -j2 -l0 failed
  *
  * Call stack:
  * ebuild.sh, line  127:  Called src_compile
  *   environment, line 3186:  Called cmake_src_compile
  *   environment, line 1231:  Called cmake_build
  *   environment, line 1200:  Called eninja
  *   environment, line 1707:  Called die
  * The specific snippet of code:
  *   "$@" || die "${nonfatal_args[@]}" "${*} failed"

I find no mention of this problem here, in the mailing list. There was
one hit in an internet search, but the conclusion was a bug in go, which
I don't have as described.

Anybody seen this?


I have not experienced this issue; android-tools has emerged
successfully (most recently in August) for me.

Per your build.log, you're still using GCC 9.3.0, which isn't even
listed on https://packages.gentoo.org/packages/sys-devel/gcc anymore
(9.4.0 and 10.3.0 are stable on amd64; I'm on 10.3.0 myself).

Given the error message implies a compiler error, perhaps try upgrading
sys-devel/gcc first?



Aggh!

00~/adm/gentoo/emerged>eselect gcc list
 [1] x86_64-pc-linux-gnu-9.3.0 *
 [2] x86_64-pc-linux-gnu-10.3.0


$ eselect news list | grep gcc

doesn't turn up anything.  When should/may one upgrade?

Thank you for the tip!   That's surely what's going on.

Re: [gentoo-user] haven't been able to build android-tools for months

[cal]

On 9/6/21 11:14 AM, n952162 wrote:
> On any of my 7 gentoo machines:
> 
> FAILED: ^[[0mvendor/CMakeFiles/libbase.dir/libbase/logging.cpp.o
> /usr/bin/x86_64-pc-linux-gnu-g++  -Ivendor
> -I/var/tmp/portage/dev-util/android-tools-31.0.0_p1/work/android-tools-31.0.0p1/vendor/libbase/include
> 
> -I/var/tmp/portage/dev-util/android-tools-31.0.0_p1/work/android-tools-31.0.0p1/vendor/core/include
> 
> -I/var/tmp/portage/dev-util/android-tools-31.0.0_p1/work/android-tools-31.0.0p1/vendor/logging/liblog/include
> 
> -O2 -pipe -std=gnu++2a -Wno-attributes -D_FILE_OFFSET_BITS=64 -MD -MT
> vendor/CMakeFiles/libbase.dir/libbase/logging.cpp.o -MF
> vendor/CMakeFiles/libbase.dir/libbase/logging.cpp.o.d -o
> vendor/CMakeFiles/libbase.dir/libbase/logging.cpp.o -c
> /var/tmp/portage/dev-util/android-tools-31.0.0_p1/work/android-tools-31.0.0p1/vendor/libbase/logging.cpp
> 
> during RTL pass: expand
> /var/tmp/portage/dev-util/android-tools-31.0.0_p1/work/android-tools-31.0.0p1/vendor/libbase/logging.cpp:
> 
> In member function â~@~Xvoid
> android::base::LogdLogger::operator()(android::base::LogId,
> android::base::LogSeverity, const char*, const char*, unsigned int,
> const char*)â~@~Y:
> /var/tmp/portage/dev-util/android-tools-31.0.0_p1/work/android-tools-31.0.0p1/vendor/libbase/logging.cpp:330:6:
> 
> internal compiler error: in expand_expr_real_1, at expr.c:10012
>   330 | void LogdLogger::operator()(LogId id, LogSeverity severity,
> const char* tag, const char* file,
>   |  ^~
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.
> [107/659] /usr/bin/x86_64-pc-linux-gnu-g++  -Ivendor
> -I/var/tmp/portage/dev-util/android-tools-31.0.0_p1/work/android-tools-31.0.0p1/vendor/libbase/include
> 
> -I/var/tmp/portage/dev-util/android-tools-31.0.0_p1/work/android-tools-31.0.0p1/vendor/core/include
> 
> -I/var/tmp/portage/dev-util/android-tools-31.0.0_p1/work/android-tools-31.0.0p1/vendor/logging/liblog/include
> 
> -O2 -pipe -std=gnu++2a -Wno-attributes -D_FILE_OFFSET_BITS=64 -MD -MT
> vendor/CMakeFiles/libbase.dir/libbase/mapped_file.cpp.o -MF
> vendor/CMakeFiles/libbase.dir/libbase/mapped_file.cpp.o.d -o
> vendor/CMakeFiles/libbase.dir/libbase/mapped_file.cpp.o -c
> /var/tmp/portage/dev-util/android-tools-31.0.0_p1/work/android-tools-31.0.0p1/vendor/libbase/mapped_file.cpp
> 
> ninja: build stopped: subcommand failed.
>  * ERROR: dev-util/android-tools-31.0.0_p1::gentoo failed (compile phase):
>  *   ninja -v -j2 -l0 failed
>  *
>  * Call stack:
>  * ebuild.sh, line  127:  Called src_compile
>  *   environment, line 3186:  Called cmake_src_compile
>  *   environment, line 1231:  Called cmake_build
>  *   environment, line 1200:  Called eninja
>  *   environment, line 1707:  Called die
>  * The specific snippet of code:
>  *   "$@" || die "${nonfatal_args[@]}" "${*} failed"
> 
> I find no mention of this problem here, in the mailing list. There was
> one hit in an internet search, but the conclusion was a bug in go, which
> I don't have as described.
> 
> Anybody seen this?
> 
I have not experienced this issue; android-tools has emerged
successfully (most recently in August) for me.

Per your build.log, you're still using GCC 9.3.0, which isn't even
listed on https://packages.gentoo.org/packages/sys-devel/gcc anymore
(9.4.0 and 10.3.0 are stable on amd64; I'm on 10.3.0 myself).

Given the error message implies a compiler error, perhaps try upgrading
sys-devel/gcc first?