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

ld: unknown option: --copy-dt-needed-entries #264

Open
ryandesign opened this issue May 18, 2023 · 1 comment
Open

ld: unknown option: --copy-dt-needed-entries #264

ryandesign opened this issue May 18, 2023 · 1 comment

Comments

@ryandesign
Copy link
Contributor

Hi! I'm trying to build litehtml 0.7 on macOS 12. I've used the cmake flag -DEXTERNAL_GTEST=ON and the error I get is:

ld: unknown option: --copy-dt-needed-entries
@ryandesign
Copy link
Contributor Author

I was unfamiliar with this option so I looked it up:

Symbols from libraries linked as dependencies no longer resolved by ld

Previously, the ld linker resolved any symbols present in any linked library, even if some libraries were linked only implicitly as dependencies of other libraries. This allowed developers to use symbols from the implicitly linked libraries in application code and omit explicitly specifying these libraries for linking.

For security reasons, ld has been changed to not resolve references to symbols in libraries linked implicitly as dependencies.

As a result, linking with ld fails when application code attempts to use symbols from libraries not declared for linking and linked only implicitly as dependencies. To use symbols from libraries linked as dependencies, developers must explicitly link against these libraries as well.

To restore the previous behavior of ld, use the -copy-dt-needed-entries command-line option. (BZ#1292230)

I assume that ld here means the GNU linker since the Apple linker doesn't seem to understand this flag. If the flag really is needed on non-Apple linkers, could you do a feature test—use the flag only if you detect that the linker supports it? (I would probably not use if(NOT APPLE) for this in cmake since it is conceivable that a Mac user might try to compile with GCC and link with the GNU linker.)

I tried removing the flag which failed with undefined symbols at link time; here are the first few:

Undefined symbols for architecture x86_64:
  "testing::InitGoogleTest(int*, char**)", referenced from:
      _main in libgtest_main.a(gtest_main.cc.o)
  "testing::AssertionSuccess()", referenced from:
      testing::AssertionResult testing::internal::CmpHelperEQ<bool, bool>(char const*, char const*, bool const&, bool const&) in codepoint_test.cpp.o
      testing::AssertionResult testing::internal::CmpHelperEQ<char const*, char const*>(char const*, char const*, char const* const&, char const* const&) in tstring_view_test.cpp.o
      testing::AssertionResult testing::internal::CmpHelperEQ<int, unsigned long>(char const*, char const*, int const&, unsigned long const&) in tstring_view_test.cpp.o
      testing::AssertionResult testing::internal::CmpHelperEQ<unsigned long, unsigned long>(char const*, char const*, unsigned long const&, unsigned long const&) in tstring_view_test.cpp.o
      testing::AssertionResult testing::internal::CmpHelperEQ<char, char>(char const*, char const*, char const&, char const&) in tstring_view_test.cpp.o
      testing::AssertionResult testing::internal::CmpHelperEQ<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >(char const*, char const*, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) in url_test.cpp.o
      testing::AssertionResult testing::internal::CmpHelperEQ<bool, bool>(char const*, char const*, bool const&, bool const&) in url_path_test.cpp.o
      ...
  "testing::Test::SetUp()", referenced from:
      vtable for CSSTest_Url_Test in cssTest.cpp.o
      vtable for CSSTest_LengthParse_Test in cssTest.cpp.o
      vtable for CSSTest_ElementSelectorParse_Test in cssTest.cpp.o
      vtable for MediaQueryTest_Check_Test in mediaQueryTest.cpp.o
      vtable for CodepointTest_URLReserved_Test in codepoint_test.cpp.o
      vtable for CodepointTest_URLScheme_Test in codepoint_test.cpp.o
      vtable for TStringViewTest_DefaultConstructor_Test in tstring_view_test.cpp.o
      ...
  "testing::Test::TearDown()", referenced from:
      vtable for CSSTest_Url_Test in cssTest.cpp.o
      vtable for CSSTest_LengthParse_Test in cssTest.cpp.o
      vtable for CSSTest_ElementSelectorParse_Test in cssTest.cpp.o
      vtable for MediaQueryTest_Check_Test in mediaQueryTest.cpp.o
      vtable for CodepointTest_URLReserved_Test in codepoint_test.cpp.o
      vtable for CodepointTest_URLScheme_Test in codepoint_test.cpp.o
      vtable for TStringViewTest_DefaultConstructor_Test in tstring_view_test.cpp.o
      ...

This is because googletest in my distribution provides only static libraries which is because of google/googletest#3442.

Also linking with the gtest library fixed the problem for me:

--- CMakeLists.txt.orig	2023-05-13 16:46:25.000000000 -0500
+++ CMakeLists.txt	2023-06-19 01:30:19.000000000 -0500
@@ -179,7 +179,6 @@
     option(EXTERNAL_GTEST "Use external GoogleTest instead of fetching from GitHub" OFF)
 
     if (EXTERNAL_GTEST)
-        link_libraries("-Wl,--copy-dt-needed-entries")
     else()
         include(FetchContent)
         FetchContent_Declare(
@@ -217,6 +217,7 @@
     target_link_libraries(
         ${TEST_NAME}
         ${PROJECT_NAME}
+        gtest
         gtest_main
     )
 

I only tested on macOS 12. I tested both with and without -DEXTERNAL_GTEST=ON. Maybe someone can test on other systems.

Possibly the order of gtest and gtest_main needs to be reversed. I have heard that the GNU linker needs libraries in a specific order but the Apple linker doesn't seem to care so I haven't learned the GNU linker's rules.

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

1 participant