Re: lld undefined symbol errors for static methods despite their class exported its symbols

[Amr Aboelkher]

+Chromium-dev 

On Tue, Oct 19, 2021 at 5:27 PM Amr Aboelkher <amrabo...@chromium.org> wrote:

Hi everyone,

I am still trying to support component build for private_membership third_party library in this CL, and stumbled into unusual linking errors.

StatusOrHelper is a class in private_membership, and has three static methods, as follows:
class StatusOrHelper {
public:
// Move type-agnostic error handling to the .cc.
static absl::Status HandleInvalidStatusCtorArg();
static absl::Status HandleNullObjectCtorArg();
static void Crash(const absl::Status& status);
...
}

After marking the class to support component build by adding component_export, as follows:
class COMPONENT_EXPORT(PRIVATE_MEMBERSHIP_EXPORT) StatusOrHelper { ... }

I am getting lld error as undefined symbols for all these three static methods (see build error log), as follows:

ld.lld: error: undefined symbol: rlwe::internal::StatusOrHelper::HandleInvalidStatusCtorArg()

>>> referenced by statusor.h:150 (../../third_party/shell-encryption/src/statusor.h:150)
>>> obj/third_party/private_membership/private_membership/aes_ctr_256_with_fixed_iv.o:(rlwe::StatusOr<std::__Cr::unique_ptr<private_membership::AesCtr256WithFixedIV, std::__Cr::default_delete<private_membership::AesCtr256WithFixedIV> > >::StatusOr(absl::Status const&))
ld.lld: error: undefined symbol: rlwe::internal::StatusOrHelper::HandleNullObjectCtorArg()
>>> referenced by statusor.h:177 (../../third_party/shell-encryption/src/statusor.h:177)
>>> obj/third_party/private_membership/private_membership/aes_ctr_256_with_fixed_iv.o:(rlwe::StatusOr<std::__Cr::unique_ptr<private_membership::AesCtr256WithFixedIV, std::__Cr::default_delete<private_membership::AesCtr256WithFixedIV> > >::StatusOr(std::__Cr::unique_ptr<private_membership::AesCtr256WithFixedIV, std::__Cr::default_delete<private_membership::AesCtr256WithFixedIV>
ld.lld: error: undefined symbol: rlwe::internal::StatusOrHelper::Crash(absl::Status const&)
>>> referenced by statusor.h:218 (../../third_party/shell-encryption/src/statusor.h:218)
>>> obj/third_party/private_membership/private_membership/crypto_utils.o:(rlwe::StatusOr<unsigned int>::ValueOrDie() &&)

I am not sure how these function symbols aren't exported correctly, despite their wrapped class being already exported. Any idea how to fix that? Or any hypothesis what's the root cause here?

Looking forward to hearing from all of you!
-Amr

[Bruce Dawson]

I took a quick look at third_party/private_membership/base/private_membership_export.h and I was wondering why there are three levels of checks here around the definition of PRIVATE_MEMBERSHIP_EXPORT (two if we ignore __has_attribute)?

Consider following the pattern of base_export.h:
https://source.chromium.org/chromium/chromium/src/+/main:base/base_export.h;l=6?q=base_export.h&sq=

Following the "standard" pattern will be easier to understand and will be more portable.

That said, I don't know what the problem is.

--
You received this message because you are subscribed to the Google Groups "build" group.
To unsubscribe from this group and stop receiving emails from it, send an email to build+un...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/build/CAKOqoXb8X_Qn0B463q7NuBEmoNPkbx2v2jDaUDK8rAO2yQ9tZQ%40mail.gmail.com.

--

Bruce Dawson, he/him

[Amr Aboelkher]

Thanks for your reply, Bruce!

Thanks for pointing that out! I had the impression that this is the standard pattern. But, I will take a look into that later on when everything is working (have created a CL comment in order not to forget). There're a lot of other failures during the linking time that need to be solved :) 

Also, that problem has been solved by using the library's macro only for these functions.

-Amr