Replies: 2 comments 11 replies
-
|
Can I reproduce the issue just by building kicad with gcc and mold? What is you gcc version? |
Beta Was this translation helpful? Give feedback.
-
|
Please try again with dfa26d0. |
Beta Was this translation helpful? Give feedback.
-
|
That seems to fix it, thanks |
Beta Was this translation helpful? Give feedback.
-
|
I had to revert it back to the original code in a3b4192 because of regressions. Could you make a change to your build file so that libcommon.a will not be passed to the linker when linking these particular programs? Passing an archive file that shouldn't be used and let the linker to ignore that file is a bit fragile; unless you are stress-testing linker compatibility, you don't want to do that. |
Beta Was this translation helpful? Give feedback.
-
I already made that change the other night to some of the targets where common.a became no longer necessary due to other refactoring. There's one target remaining that actually has not only bad link dependencies but improper code added that drove the dependency so it's taking me longer to figure out how to unwind that mess. But why does C++17 vs. C++20 break it? |
Beta Was this translation helpful? Give feedback.
-
|
I don't know why, but some C++ std symbols are in libcommon.a only when compiled as C++20 as follows: |
Beta Was this translation helpful? Give feedback.
-
|
Is there another way to make mold work with C++20 and KiCad? If |
Beta Was this translation helpful? Give feedback.
-
|
That's exactly what we were discussing in the above thread, no? My understanding is that efforts are underway to fix it on the KiCad side. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, we're still looking at ways to solve this in KiCad, but why does it work fine with other linkers in C++20 mode? |
Beta Was this translation helpful? Give feedback.
-
|
I don't know why it worked with C++17 and doesn't with C++20 (look at my last comment in the above thread for the symbol differences), but the thing is that the same set of symbols are defined by the .so and the .a, and it's somewhat arbitrary for the linker to pick up which one. |
Beta Was this translation helpful? Give feedback.
-
So recently I've migrated Kicad from C++17 to C++20. And I have it compiling under MSVC, Clang (with lld) on both Linux and macOS, and gcc with gold on Linux.
But gcc+mold and clang+mold are running into a linker error that is unique to the usage of mold.
The basic summary in our mess is
libcommon.a references a extern called
extern KIFACE_BASE& Kiface();It is used by a few objects built as part of libcommon.a. The definition of KIFACE_BASE also exists in libcommon.a
The actual Kiface() function only exists in another static library called
gerbview_kiface_objectswhich thegerbviewexecutable does not link to because there's agerbview_kifacethat instead uses it. In fact none of objects thatgerbviewis normally looking to link fromlibcommon.ashould be referencing Kiface().The oddity is this only happens with mold being used to link C++20, changing the project back to C++17 by flipping the std definition makes it work.
I installed the latest mold:
Is there a C++ standard related change that would affect specifically affect only mold?
Beta Was this translation helpful? Give feedback.
All reactions