Skip to content

Upgrade to platform-tools-35.0.1 #144

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
merged 2 commits into from
Apr 25, 2024
Merged

Upgrade to platform-tools-35.0.1 #144

merged 2 commits into from
Apr 25, 2024

Conversation

Biswa96
Copy link
Collaborator

@Biswa96 Biswa96 commented Apr 24, 2024

No description provided.

@Biswa96
Copy link
Collaborator Author

Biswa96 commented Apr 24, 2024

I do not know how to troubleshoot the compiler error in Fedora.

@munix9
Copy link
Contributor

munix9 commented Apr 24, 2024

I can reproduce the error in openSUSE Tumbleweed with gcc 14.

With the following patch the build works with clang, gcc 13 and gcc 14, but I'm not sure if this is the clean way to do it:

--- a/vendor/boringssl/crypto/internal.h
+++ b/vendor/boringssl/crypto/internal.h
@@ -1144,7 +1144,7 @@ static inline uint64_t CRYPTO_rotr_u64(u
 
 // CRYPTO_addc_* returns |x + y + carry|, and sets |*out_carry| to the carry
 // bit. |carry| must be zero or one.
-#if OPENSSL_HAS_BUILTIN(__builtin_addc)
+#if OPENSSL_HAS_BUILTIN(__builtin_addc) && (!defined(__GNUC__) || (defined(__GNUC__) && (__GNUC__ < 14)))
 
 #define CRYPTO_GENERIC_ADDC(x, y, carry, out_carry) \
   (_Generic((x),                                    \
@@ -1196,7 +1196,7 @@ static inline uint64_t CRYPTO_addc_u64(u
 
 // CRYPTO_subc_* returns |x - y - borrow|, and sets |*out_borrow| to the borrow
 // bit. |borrow| must be zero or one.
-#if OPENSSL_HAS_BUILTIN(__builtin_subc)
+#if OPENSSL_HAS_BUILTIN(__builtin_subc) && (!defined(__GNUC__) || (defined(__GNUC__) && (__GNUC__ < 14)))
 
 #define CRYPTO_GENERIC_SUBC(x, y, borrow, out_borrow) \
   (_Generic((x),                                      \

@Biswa96
Copy link
Collaborator Author

Biswa96 commented Apr 24, 2024

That seems more like workaround. Is gcc 14 released yet?

@munix9
Copy link
Contributor

munix9 commented Apr 24, 2024

Yes of course, that would be a workaround.
Fedora apparently already uses gcc 14 by default.
openSUSE Tumbleweed already offers gcc 14, but gcc 13 is currently still the default.

Another possibility would be to adapt the checks for fedora so that gcc 13 is used (if it is offered).

@Biswa96
Copy link
Collaborator Author

Biswa96 commented Apr 24, 2024

I have added the above workaround for gcc 14. Waiting for reviews...

@anatol
Copy link
Collaborator

anatol commented Apr 24, 2024

The remaining issue is with opensuse/leap:latest:

/usr/bin/ld: warning: libabsl_die_if_null.so.2308.0.0, needed by /usr/lib64/libprotobuf.so.25.1.0, may conflict with libabsl_die_if_null.so.2401.0.0
/usr/bin/ld: warning: libabsl_statusor.so.2308.0.0, needed by /usr/lib64/libprotobuf.so.25.1.0, may conflict with libabsl_statusor.so.2401.0.0
/usr/bin/ld: warning: libabsl_log_internal_check_op.so.2308.0.0, needed by /usr/lib64/libprotobuf.so.25.1.0, may conflict with libabsl_log_internal_check_op.so.2401.0.0
/usr/bin/ld: warning: libabsl_log_internal_conditions.so.2308.0.0, needed by /usr/lib64/libprotobuf.so.25.1.0, may conflict with libabsl_log_internal_conditions.so.2401.0.0
/usr/bin/ld: warning: libabsl_log_internal_message.so.2308.0.0, needed by /usr/lib64/libprotobuf.so.25.1.0, may conflict with libabsl_log_internal_message.so.2401.0.0
...
/usr/bin/ld: vendor/libliblpdump.a(dynamic_partitions_device_info.pb.cc.o): in function `android::DynamicPartitionsDeviceInfoProto::GetMetadata() const':
dynamic_partitions_device_info.pb.cc:(.text+0x1ab6): undefined reference to `google::protobuf::internal::AssignDescriptors(google::protobuf::internal::DescriptorTable const* (*)(), absl::lts_20240116::once_flag*, google::protobuf::Metadata const&)'
/usr/bin/ld: vendor/liblibjsonpbparse.a(jsonpb.cpp.o): in function `android::jsonpb::MessageToJsonString[abi:cxx11](google::protobuf::Message const&)':
jsonpb.cpp:(.text+0x209): undefined reference to `google::protobuf::util::NewTypeResolverForDescriptorPool(absl::lts_20240116::string_view, google::protobuf::DescriptorPool const*)'
/usr/bin/ld: vendor/liblibjsonpbparse.a(jsonpb.cpp.o): in function `android::jsonpb::internal::JsonStringToMessage(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, google::protobuf::Message*)':
jsonpb.cpp:(.text+0x5cc): undefined reference to `google::protobuf::util::NewTypeResolverForDescriptorPool(absl::lts_20240116::string_view, google::protobuf::DescriptorPool const*)'
/usr/bin/ld: jsonpb.cpp:(.text+0x62e): undefined reference to `google::protobuf::json::JsonToBinaryString(google::protobuf::util::TypeResolver*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, absl::lts_20240116::string_view, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*, google::protobuf::json::ParseOptions const&)'
/usr/bin/ld: jsonpb.cpp:(.text+0x65f): undefined reference to `google::protobuf::MessageLite::ParseFromString(absl::lts_20240116::string_view)'
clang-15.0: error: linker command failed with exit code 1 (use -v to see invocation)

could it be opensuse problem given that their system has libabsl version clash?

@munix9
Copy link
Contributor

munix9 commented Apr 25, 2024

That is correct. The problem is known and a solution is being worked on. It has probably already been fixed for the next version Leap 15.6, but unfortunately not yet for the current "latest" version, i.e. Leap 15.5.

@anatol
Copy link
Collaborator

anatol commented Apr 25, 2024

It is great to hear. @munix9 do you have a link to the upstream discussion to learn more about the root of the problem and proposed solution?

@munix9
Copy link
Contributor

munix9 commented Apr 25, 2024

The basic problem is probably that Leap also uses binary packages from the SUSE distribution (the commercial one with support).
There protobuf is linked with libabsl 2308.0.0, but other packages only in Leap are linked with libabsl 2401.0.0.
This leads to conflicts with some other packages.
This must now be resolved.

#143
https://bugzilla.opensuse.org/show_bug.cgi?id=1222343

@anatol
Copy link
Collaborator

anatol commented Apr 25, 2024

As the opensuse bot issue is identified as the upstream one I am +1 with merging this PR into master. Opensuse will catch up and the buildbot will be eventually fixed.

@Biswa96 Biswa96 merged commit 1801428 into nmeum:master Apr 25, 2024
@Biswa96 Biswa96 deleted the 35.0.1 branch April 25, 2024 07:00
@anatol
Copy link
Collaborator

anatol commented Apr 27, 2024

master looks good to me. It is time for a new 35.0.1 release!

@s1341
Copy link

s1341 commented Mar 6, 2025

I'm having issues with this 35.0.1 version, on NixOS.

Specifically, if I have multiple devices connected to a machine with adb running, and I restart one of the devices, the adb server process aborts with the following ADB_TRACE output on it's standard-out:

03-06 10:30:31.089 378139 378139 I adb     : usb_libusb.cpp:669 libusb_cancel_transfer failed: LIBUSB_ERROR_NOT_FOUND
03-06 10:30:31.089 378139 378139 I adb     : usb_libusb.cpp:669 libusb_cancel_transfer failed: LIBUSB_ERROR_NOT_FOUND
03-06 10:30:31.089 378139 378139 I adb     : usb_libusb.cpp:669 libusb_cancel_transfer failed: LIBUSB_ERROR_NOT_FOUND
03-06 10:30:31.089 378139 378139 I adb     : usb_libusb.cpp:669 libusb_cancel_transfer failed: LIBUSB_ERROR_NOT_FOUND
03-06 10:30:31.089 378139 378139 I adb     : usb_libusb.cpp:669 libusb_cancel_transfer failed: LIBUSB_ERROR_NOT_FOUND
03-06 10:30:31.089 378139 378139 I adb     : usb_libusb.cpp:669 libusb_cancel_transfer failed: LIBUSB_ERROR_NOT_FOUND
03-06 10:30:31.089 378139 378139 I adb     : usb_libusb.cpp:669 libusb_cancel_transfer failed: LIBUSB_ERROR_NOT_FOUND
double free or corruption (!prev)

Note that the same scenario under the same conditions using version 34.0.5 does not crash!

See DeviceFarmer/stf#845 for further info.

@Biswa96
Copy link
Collaborator Author

Biswa96 commented Mar 6, 2025

I'm having issues with this 35.0.1 version, on NixOS.

Does the issue happen with 35.0.2? It has an option to use system libusb or the bundled one. Please try with it being enabled and disabled.

@s1341 s1341 mentioned this pull request Mar 6, 2025
Closed
13 tasks
@s1341
Copy link

s1341 commented Mar 6, 2025

I tested the android-tools 35.0.2 from the pending PR NixOS/nixpkgs#382382, and observed the same behavior.

It seems that PR uses the bundled libusb. I don't think I can easily test with the system libusb, as if I understand correctly, android-tools uses libusb functionality not yet released in upstream libusb?

In any event, something is off here...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
4 participants
@Biswa96 @munix9 @anatol @s1341