[
https://issues.apache.org/jira/browse/HDFS-12026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16075278#comment-16075278
]
James Clampffer commented on HDFS-12026:
----------------------------------------
Thanks for looking into this [~anatoli.shein].
I got the error below when I first tried to compile. Looks like the fix is to
install the libstdc++ source (libstdc+\+-dev package on ubuntu). Could you
have cmake run a sanity test on a little file that includes <string> or any
other c++ std header and warn if can't build? Looks like CMake's try_compile
function is built for this sort of thing. A more open question is if this
should also be added to the dockerfile. Looks like it'd need clang as well to
build in the docker environment.
{code}
[exec] In file included from
/apache_hadoop/hadoop-hdfs-project/hadoop-hdfs-native-client/src/main/native/libhdfspp/lib/proto/protoc_gen_hrpc.cc:19:
[exec]
/apache_hadoop/hadoop-hdfs-project/hadoop-hdfs-native-client/src/main/native/libhdfspp/third_party/protobuf/protobuf/cpp_helpers.h:38:10:
fatal error: 'string' file not found
[exec] #include <string>
[exec] ^
[exec] 1 error generated.
{code}
After fixing that I get link errors on protoc-gen-hrpc. If the fix is to
rebuild protoc and libprotobuf with clang could you add another try_compile and
if it fails explain what's going on? If nothing else getting clang and
libstdc++ into the dockerfile for the review would help so that we are both
looking at the same environment.
In block_location.h make the class members have the trailing underscore rather
than the argument so it's consistent with the rest of the library.
{code}
void setHostname(const std::string & hostname_) {
this->hostname = hostname_;
}
{code}
turns to:
{code}
void setHostname(const std::string & hostname) {
this->hostname_ = hostname;
}
{code}
The definition of a function with a __cxa prefix in hdfs.cc might have a better
alternative (not sure what though). __cxa deals with ABI stuff so I think
relying on a function at that level might not be stable across major versions
of compilers. If we have to go this route can you put in a version check for
glibc like the one mentioned on
https://stackoverflow.com/questions/29322666/undefined-reference-to-cxa-thread-atexitcxxabi-when-compiling-with-libc?
More minor stuff:
In optional_wrapper.h is the pragma for ignoring extra semicolons due to ones
in our code or third-party headers? If it's ours I think it'd be best to try
and clean those up and get GCC to complain about them as well so things stay
clean. Likewise ignoring -Wweak-vtables can most likely be removed after
making sure all virtual functions are defined and there isn't some include
that's forcing different vtable instantiations for the same class in different
translation units. Once I can get this built I can try and look into it too.
> libhdfspp: Fix compilation errors and warnings when compiling with Clang
> -------------------------------------------------------------------------
>
> Key: HDFS-12026
> URL: https://issues.apache.org/jira/browse/HDFS-12026
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: hdfs-client
> Reporter: Anatoli Shein
> Assignee: Anatoli Shein
> Attachments: HDFS-12026.HDFS-8707.000.patch,
> HDFS-12026.HDFS-8707.001.patch
>
>
> Currently multiple errors and warnings prevent libhdfspp from being compiled
> with clang. It should compile cleanly using flags:
> -std=c++11 -stdlib=libc++
> and also warning flags:
> -Weverything -Wno-c++98-compat -Wno-missing-prototypes
> -Wno-c++98-compat-pedantic -Wno-padded -Wno-covered-switch-default
> -Wno-missing-noreturn -Wno-unknown-pragmas -Wconversion -Werror
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
