[
https://issues.apache.org/jira/browse/IMPALA-11640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17979249#comment-17979249
]
ASF subversion and git services commented on IMPALA-11640:
----------------------------------------------------------
Commit 0a55bf54e121ee6a2f0f36f8fb0a47a07cb10960 in impala's branch
refs/heads/master from Joe McDonnell
[ https://gitbox.apache.org/repos/asf?p=impala.git;h=0a55bf54e ]
IMPALA-14066 (Part 3): Re-applying IMPALA-11640/IMPALA-11641: Workaround errors
in shared library build on Ubuntu 18+
This commit re-applies IMPALA-11640/IMPALA-11641 to the Kudu files after
the Kudu rebase to v1.17.1. The original commit message is below:
Building with -so on Ubuntu 18 or higher fails due to
an issue finding dlopen in unwind_safeness.cc:
unwind_safeness.cc:76] Check failed: !error failed to find symbol dlopen
unwind_safeness.cc is using dlsym to load the dlopen symbol
so that it can wrap it with its own dlopen code. The Impala
build has issues with the ordering of libraries, and this
code does not find dlopen. This has previously happened with
the dl_iterate_phdr symbol in Kudu.
This is a problem starting with Ubuntu 18.04, because Ubuntu 16.04
uses a version of glibc that has a bug in reporting this
error. Ubuntu 18.04 uses a newer glibc with a fix for the bug. See
https://sourceware.org/bugzilla/show_bug.cgi?id=19509 .
As a workaround for this issue, this tolerates not finding
dlopen/dlclose when building with shared libraries. Impala shared
libraries are not used in production, so this bypasses the issue.
This also adds extra validation to make sure the symbols are non-null.
Specifically, this adds another CHECK in dlsym_or_die to verify
that the symbol is non-null. This also adds a DCHECK to verify that
the symbol is non-null at dereference.
This also fixes an issue where Boost was always using static
libraries, even for shared library builds. This makes Boost use
shared libraries for shared library builds.
Testing:
- The shared library build passes on Ubuntu 18 and Ubuntu 20
- Impala can boot and run queries with shared libraries
Change-Id: I0034464a075b3add7ce591a36dab6fda334e6203
Reviewed-on: http://gerrit.cloudera.org:8080/19104
Reviewed-by: Daniel Becker <[email protected]>
Tested-by: Impala Public Jenkins <[email protected]>
Reviewed-on: http://gerrit.cloudera.org:8080/23009
Tested-by: Daniel Becker <[email protected]>
> Build fails on Ubuntu 18/20 when using shared libraries
> -------------------------------------------------------
>
> Key: IMPALA-11640
> URL: https://issues.apache.org/jira/browse/IMPALA-11640
> Project: IMPALA
> Issue Type: Bug
> Components: Backend
> Affects Versions: Impala 4.2.0
> Reporter: Joe McDonnell
> Assignee: Joe McDonnell
> Priority: Major
> Fix For: Impala 4.2.0
>
>
> When building on Ubuntu 18 or Ubuntu 20 with shared libraries (-so), the
> build fails because the unifiedbetests binary fails to run as part of the
> validate-unified-backend-test-filters.py invocation:
> {noformat}
> 16:39:22 F1005 23:39:22.237543 88570 unwind_safeness.cc:76] Check failed:
> !error failed to find symbol dlopen:
> /home/ubuntu/Impala/be/build/release/kudu_util/libkudu_util.so: undefined
> symbol: dlopen
> 16:39:22 FAILED: Unified backend test executable returned an error when trying
> 16:39:22 to list tests.
> 16:39:22 Command: /home/ubuntu/Impala/bin/run-binary.sh
> /home/ubuntu/Impala/be/build/release//service/unifiedbetests
> --gtest_list_tests
> 16:39:22 Return Code: -6
> 16:39:22 stdout:
> 16:39:22
> 16:39:22 stderr:
> 16:39:22 None{noformat}
> When building locally, other binaries also fail to execute with the same
> message.
> One theory is that the code in unwind_safeness.cc has never worked, but
> Ubuntu 16.04 is impacted by a glibc bug that prevents it from setting an
> error ([https://sourceware.org/bugzilla/show_bug.cgi?id=19509]). Newer Ubuntu
> correctly report the error, which leads to the failure.
> One option is to change unwind_safeness.cc to tolerate missing
> dlopen/dlclose. Impala doesn't ship using shared libraries. If the
> unwind_safeness.cc variables that contain dlopen/dlclose are actually used
> after a failure to resolve dlopen/dlclose, then it would result in a SIGSEGV
> and it would be very obvious.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
