[
https://issues.apache.org/jira/browse/MESOS-9323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16653343#comment-16653343
]
Benno Evers commented on MESOS-9323:
------------------------------------
After further investigation, this was caused by mixing `g++` as default
compiiler with `lld` as default linker.
I'm able to reproduce the unique symbol and the DTPOFF32 relocation using this
example program:
{noformat}
$ cat thread_local.cpp
#include <string>
class C {
public:
static void* foo() {
static thread_local void* generator = nullptr;
return generator;
}
};
void* cfoo() {
return C::foo();
}
$ g++ thread-local.cpp -c -O2 -fPIC
{noformat}
But this in itself doesn't seem to be enough to trigger the error, so I still
don't know the actual root cause of this problem.
> Relocation errros against symbol id::UUID::random()
> ---------------------------------------------------
>
> Key: MESOS-9323
> URL: https://issues.apache.org/jira/browse/MESOS-9323
> Project: Mesos
> Issue Type: Bug
> Reporter: Benno Evers
> Priority: Major
>
> Trying to build Mesos on a Fedora 28 machine using a combination of gcc 8.1
> and lld 8-trunk results in the following error:
> {noformat}
> ld: error: can't create dynamic relocation R_X86_64_DTPOFF32 against symbol:
> id::UUID::random()::generator in readonly segment; recompile object files
> with -fPIC or pass '-Wl,-z,notext' to allow text relocations in the output
> >>> defined in
> >>> ./.libs/libmesos_no_3rdparty.a(libmesos_no_3rdparty_la-checker_process.o)
> >>> referenced by uuid.hpp:43 (../../3rdparty/stout/include/stout/uuid.hpp:43)
> >>>
> >>> lt15-libmesos_no_3rdparty_la-manager.o:(mesos::internal::ResourceProviderManagerProcess::newResourceProviderId())
> >>> in archive ./.libs/libmesos_no_3rdparty.a
> ld: error: too many errors emitted, stopping now (use -error-limit=0 to see
> all errors)
> {noformat}
> Both the linker and compiler flags already included `-fPIC`, so this part of
> the error message seems bogus.
> I'm not sure if this an issue of the compiler generating invalid object files
> or the linker misunderstanding the created artifacts. However, the symbol
> `id::UUID::random()::generator` is a very special case because it is a
> function-local static in an inline function, causing gcc to generate a
> special `GNU_UNIQUE` symbol, and also a thread-local variable leading to the
> DTPOFF32 relocation.
> It seems like this combination of uncommon things is somehow tripping up one
> of the involved tools.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
