Skip to content
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.

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

building of clang for SDK fails due to -fPIC is not supported #975

Open
ceggers-arri opened this issue Jul 13, 2024 · 2 comments
Open

building of clang for SDK fails due to -fPIC is not supported #975

ceggers-arri opened this issue Jul 13, 2024 · 2 comments

Comments

@ceggers-arri
Copy link
Contributor

OE Version: Yocto Scarthgap

I've tried to build clang for SDK by adding the meta-clang
layer to my build and setting CLANGSDK = "1" in my local.conf.
But when running bitbake myrootfs -c populate_sdk, linking of
libLLVM.so.18.1 fails with the following error messages:

/build/devel-scarthgap/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-clang/18.1.5/recipe-sysroot-native/usr/bin/x86_64-pokysdk-linux/x86_64-pokysdk-linux-ld: lib/libLLVMSupport.a(CrashRecoveryContext.cpp.o): relocation R_X86_64_TPOFF32 against `_ZN12_GLOBAL__N_121IsRecoveringFromCrashE' can not be used when making a shared object; recompile with -fPIC
/build/devel-scarthgap/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-clang/18.1.5/recipe-sysroot-native/usr/bin/x86_64-pokysdk-linux/x86_64-pokysdk-linux-ld: failed to set dynamic section sizes: bad value
x86_64-pokysdk-linux-clang++: error: linker command failed with exit code 1 (use -v to see invocation)

I can see that -fPIC as actually not set during compilation of CrashRecoveryContext.cpp. In the log.do_compile this switch is only set for 36 out of 6320 source files. When I compare this with the native clang build, I see that -fPIC is set for almost all files.

The log.do_configure for native includes the following:

-- Performing Test C_SUPPORTS_FPIC
-- Performing Test C_SUPPORTS_FPIC - Success
-- Performing Test CXX_SUPPORTS_FPIC
-- Performing Test CXX_SUPPORTS_FPIC - Success
-- Building with -fPIC

But for nativesdk this is different:

-- Performing Test C_SUPPORTS_FPIC
-- Performing Test C_SUPPORTS_FPIC - Failed
-- Performing Test CXX_SUPPORTS_FPIC
-- Performing Test CXX_SUPPORTS_FPIC - Failed
CMake Warning at cmake/modules/HandleLLVMOptions.cmake:320 (message):
  -fPIC is not supported.
Call Stack (most recent call first):
  cmake/modules/HandleLLVMOptions.cmake:380 (add_flag_or_print_warning)
  CMakeLists.txt:936 (include)wq
@kraj
Copy link
Owner

kraj commented Jul 13, 2024

@ceggers-arri are you also using DEBUG_BUILD = "1" ? if so this could be duplicate of #932 we fixed it for master branch already, please test the patch from #955 and report back, if it works then please create a backport pull request for scarthgap

@ceggers-arri
Copy link
Contributor Author

Hi Khem,

after some investigation it turned out that it's in fact a duplicate of #932. On my setup I've set BUILDSDK_OPTIMIZATION similar as for target, so also -feliminate-unused-debug-types was set (independently of BUILD_DEBUG).

In build/CMakeFiles/CMakeConfigureLog.yaml then I see the following errors:

        x86_64-pokysdk-linux-clang: error: argument unused during compilation: '-feliminate-unused-debug-types' [-Werror,-Wunused-command-line-argument]
        x86_64-pokysdk-linux-clang: error: argument unused during compilation: '-feliminate-unused-debug-types' [-Werror,-Wunused-command-line-argument]

So it clear now why the native build works fine while the nativesdk build doesn't (the former uses the host gcc, the latter clang). After removing -feliminate-unused-debug-types from BUILDSDK_OPTIMIZATION, everything looks fine.

Just on Friday Richard sent a patch which removes -feliminate-unused-debug-types at all. Looking into the GCC source I found an entry in Changelog-2012 which states that -feliminate-unused-debug-types is enabled by default since then. So instead of working around this problem as in #955, it may be worth to remove this switch for all maintained OE core branches.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants