Mold Error Building 9.0.3 From Zip File

So, I am build KiCad 9.0.3 from the zip file. Why, just because…

Anyway, after resolving a number of dependency issues, I have managed to complete the build about 91% of the way. Then I get this error:

mold: error: undefined symbol: Kiface()

referenced by eda_base_frame.cpp
common/libcommon.a(eda_base_frame.cpp.o):(EDA_BASE_FRAME::config() const)
referenced by eda_base_frame.cpp
common/libcommon.a(eda_base_frame.cpp.o):(EDA_BASE_FRAME::sys_search())
referenced by eda_base_frame.cpp
common/libcommon.a(eda_base_frame.cpp.o):(EDA_BASE_FRAME::help_name())
referenced 2 more times
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.

Anybody know what might be going on here?

I just cloned the repository and attempted to build that and got the same error. So, at least it’s got nothing to do with the zip file.

By the way I am building on a Debian 12 system with gcc-12 and g++12. I built and installed a local copy of wxWidgets 3.2.2, which seems to be detected properly.

Here is my configuration command:

cmake -G Ninja -DCMAKE_BUILD_TYPE=RelWithDebInfo -DCMAKE_CXX_FLAGS=“-fuse-ld=mold” -DCMAKE_INSTALL_PREFIX=$HOME/.local -DCMAKE_PREFIX_PATH=$HOME/.local -DCMAKE_FIND_PACKAGE_PREFER_CONFIG=ON -DKICAD_USE_EGL=ON …/…/

[2036/2236] Building CXX object utils/idftools/CMakeFiles/idf2vrml.dir/idf2vrml.cpp.o
[2037/2236] Linking CXX executable utils/idftools/idf2vrml
FAILED: utils/idftools/idf2vrml 
: && /usr/bin/c++ -fuse-ld=mold -Wno-attributes -Wno-ignored-attributes -pthread -Wall -Wsuggest-override -Wduplicated-branches -Wduplicated-cond -Werror=vla -Wimplicit-fallthrough=5 -Werror=return-type -Wshadow -Wsign-compare -Wmissing-field-initializers -Wempty-body -Wreorder -Wmismatched-tags -Wpessimizing-move -Wredundant-move -Wno-psabi -O2 -g -DNDEBUG  utils/idftools/CMakeFiles/idf2vrml.dir/idf2vrml.cpp.o -o utils/idftools/idf2vrml -L/home/fred/.local/lib -Wl,-rpath,/home/fred/.local/lib:/home/fred/Source/kicad/kicad/build/release/common/gal:/home/fred/Source/kicad/kicad/build/release/common:/home/fred/Source/kicad/kicad/build/release/api:  utils/idftools/libidf3.a  libs/kimath/libkimath.a  common/libcommon.a  /usr/lib/x86_64-linux-gnu/libOpenGL.so  /usr/lib/x86_64-linux-gnu/libGLX.so  /usr/lib/x86_64-linux-gnu/libGLU.so  -L/home/fred/.local/lib  -pthread  -lwx_gtk3u_gl-3.2  -lwx_gtk3u_aui-3.2  -lwx_gtk3u_html-3.2  -lwx_gtk3u_core-3.2  -lwx_baseu_net-3.2  -lwx_baseu-3.2  -lwx_gtk3u_propgrid-3.2  -lwx_baseu_xml-3.2  -lwx_gtk3u_stc-3.2  -lwx_gtk3u_richtext-3.2  scripting/libscripting.a  common/libcommon.a  scripting/libscripting.a  thirdparty/libcontext/liblibcontext.a  common/gal/libkigal.so.9.0.3  thirdparty/glew/libglew.a  /usr/lib/x86_64-linux-gnu/libEGL.so  /usr/lib/x86_64-linux-gnu/libcairo.so  /usr/lib/x86_64-linux-gnu/libpixman-1.so  /usr/lib/x86_64-linux-gnu/libOpenGL.so  /usr/lib/x86_64-linux-gnu/libGLX.so  /usr/lib/x86_64-linux-gnu/libGLU.so  thirdparty/nanosvg/libnanosvg.a  thirdparty/dxflib_qcad/libdxflib_qcad.a  thirdparty/tinyspline_lib/libtinyspline_lib.a  thirdparty/nanodbc/libnanodbc.a  -lodbc  /usr/lib/x86_64-linux-gnu/libboost_locale.so.1.74.0  /usr/lib/x86_64-linux-gnu/libboost_chrono.so.1.74.0  /usr/lib/x86_64-linux-gnu/libboost_system.so.1.74.0  /usr/lib/x86_64-linux-gnu/libboost_thread.so.1.74.0  /usr/lib/x86_64-linux-gnu/libboost_atomic.so.1.74.0  common/libkicommon.so.9.0.3  libs/kimath/libkimath.a  thirdparty/clipper2/libclipper2.a  -lm  libs/kiplatform/libkiplatform.a  libs/core/libcore.a  -L/home/fred/.local/lib  -pthread  -lgtk-3  -lgdk-3  -lz  -lpangocairo-1.0  -lpango-1.0  -lharfbuzz  -latk-1.0  -lcairo-gobject  -lcairo  -lgdk_pixbuf-2.0  -lgio-2.0  -lgobject-2.0  -lglib-2.0  -lsecret-1  -lgio-2.0  -lgobject-2.0  -lglib-2.0  -lsecret-1  /usr/lib/x86_64-linux-gnu/libwayland-client.so  thirdparty/fmt/libfmt.a  libs/kinng/libkinng.a  /usr/lib/x86_64-linux-gnu/libnng.so.1.5.2  api/libkiapi.so.9.0.3  /home/fred/.local/lib/libprotobuf.so.31.1.0  /home/fred/.local/lib/libabsl_log_internal_check_op.a  /home/fred/.local/lib/libabsl_die_if_null.a  /home/fred/.local/lib/libabsl_log_internal_conditions.a  /home/fred/.local/lib/libabsl_log_internal_message.a  /home/fred/.local/lib/libabsl_log_internal_nullguard.a  /home/fred/.local/lib/libabsl_examine_stack.a  /home/fred/.local/lib/libabsl_log_internal_format.a  /home/fred/.local/lib/libabsl_log_internal_structured_proto.a  /home/fred/.local/lib/libabsl_log_internal_log_sink_set.a  /home/fred/.local/lib/libabsl_log_sink.a  /home/fred/.local/lib/libabsl_log_entry.a  /home/fred/.local/lib/libabsl_log_internal_proto.a  /home/fred/.local/lib/libabsl_flags_internal.a  /home/fred/.local/lib/libabsl_flags_marshalling.a  /home/fred/.local/lib/libabsl_flags_reflection.a  /home/fred/.local/lib/libabsl_flags_config.a  /home/fred/.local/lib/libabsl_flags_program_name.a  /home/fred/.local/lib/libabsl_flags_private_handle_accessor.a  /home/fred/.local/lib/libabsl_flags_commandlineflag.a  /home/fred/.local/lib/libabsl_flags_commandlineflag_internal.a  /home/fred/.local/lib/libabsl_log_initialize.a  /home/fred/.local/lib/libabsl_log_internal_globals.a  /home/fred/.local/lib/libabsl_log_globals.a  /home/fred/.local/lib/libabsl_vlog_config_internal.a  /home/fred/.local/lib/libabsl_log_internal_fnmatch.a  /home/fred/.local/lib/libabsl_raw_hash_set.a  /home/fred/.local/lib/libabsl_hashtablez_sampler.a  /home/fred/.local/lib/libabsl_random_distributions.a  /home/fred/.local/lib/libabsl_random_seed_sequences.a  /home/fred/.local/lib/libabsl_random_internal_entropy_pool.a  /home/fred/.local/lib/libabsl_random_internal_randen.a  /home/fred/.local/lib/libabsl_random_internal_randen_hwaes.a  /home/fred/.local/lib/libabsl_random_internal_randen_hwaes_impl.a  /home/fred/.local/lib/libabsl_random_internal_randen_slow.a  /home/fred/.local/lib/libabsl_random_internal_platform.a  /home/fred/.local/lib/libabsl_random_internal_seed_material.a  /home/fred/.local/lib/libabsl_random_seed_gen_exception.a  /home/fred/.local/lib/libabsl_statusor.a  /home/fred/.local/lib/libabsl_status.a  /home/fred/.local/lib/libabsl_cord.a  /home/fred/.local/lib/libabsl_cordz_info.a  /home/fred/.local/lib/libabsl_cord_internal.a  /home/fred/.local/lib/libabsl_hash.a  /home/fred/.local/lib/libabsl_city.a  /home/fred/.local/lib/libabsl_cordz_functions.a  /home/fred/.local/lib/libabsl_exponential_biased.a  /home/fred/.local/lib/libabsl_cordz_handle.a  /home/fred/.local/lib/libabsl_crc_cord_state.a  /home/fred/.local/lib/libabsl_crc32c.a  /home/fred/.local/lib/libabsl_crc_internal.a  /home/fred/.local/lib/libabsl_crc_cpu_detect.a  /home/fred/.local/lib/libabsl_leak_check.a  /home/fred/.local/lib/libabsl_strerror.a  /home/fred/.local/lib/libabsl_str_format_internal.a  /home/fred/.local/lib/libabsl_synchronization.a  /home/fred/.local/lib/libabsl_stacktrace.a  /home/fred/.local/lib/libabsl_symbolize.a  /home/fred/.local/lib/libabsl_debugging_internal.a  /home/fred/.local/lib/libabsl_demangle_internal.a  /home/fred/.local/lib/libabsl_demangle_rust.a  /home/fred/.local/lib/libabsl_decode_rust_punycode.a  /home/fred/.local/lib/libabsl_utf8_for_code_point.a  /home/fred/.local/lib/libabsl_graphcycles_internal.a  /home/fred/.local/lib/libabsl_kernel_timeout_internal.a  /home/fred/.local/lib/libabsl_malloc_internal.a  /home/fred/.local/lib/libabsl_tracing_internal.a  /home/fred/.local/lib/libabsl_time.a  /home/fred/.local/lib/libabsl_civil_time.a  /home/fred/.local/lib/libabsl_time_zone.a  /home/fred/.local/lib/libabsl_strings.a  /home/fred/.local/lib/libabsl_int128.a  /home/fred/.local/lib/libabsl_strings_internal.a  /home/fred/.local/lib/libabsl_string_view.a  /home/fred/.local/lib/libabsl_base.a  /home/fred/.local/lib/libabsl_spinlock_wait.a  -lrt  /home/fred/.local/lib/libabsl_throw_delegate.a  /home/fred/.local/lib/libabsl_raw_logging_internal.a  /home/fred/.local/lib/libabsl_log_severity.a  thirdparty/json_schema_validator/libnlohmann_json_schema_validator.a  /usr/lib/x86_64-linux-gnu/libcurl.so  /usr/lib/x86_64-linux-gnu/libzstd.so  -lwx_gtk3u_gl-3.2  -lwx_gtk3u_aui-3.2  -lwx_gtk3u_html-3.2  -lwx_gtk3u_core-3.2  -lwx_baseu_net-3.2  -lwx_baseu-3.2  -lwx_gtk3u_propgrid-3.2  -lwx_baseu_xml-3.2  -lwx_gtk3u_stc-3.2  -lwx_gtk3u_richtext-3.2  /usr/lib/x86_64-linux-gnu/libgit2.so  /usr/lib/x86_64-linux-gnu/libfreetype.so  /usr/lib/x86_64-linux-gnu/libfontconfig.so  /usr/lib/x86_64-linux-gnu/libpython3.11.so  -Wl,-rpath-link,/home/fred/.local/lib && :
mold: error: undefined symbol: Kiface()
>>> referenced by eda_base_frame.cpp
>>>               common/libcommon.a(eda_base_frame.cpp.o):(EDA_BASE_FRAME::config() const)>>> referenced by eda_base_frame.cpp
>>>               common/libcommon.a(eda_base_frame.cpp.o):(EDA_BASE_FRAME::sys_search())>>> referenced by eda_base_frame.cpp
>>>               common/libcommon.a(eda_base_frame.cpp.o):(EDA_BASE_FRAME::help_name())>>> referenced 3 more times

collect2: error: ld returned 1 exit status
[2038/2236] Building CXX object kicad/pcm/CMakeFiles/pcm.dir/dialogs/panel_packages_view.cpp.o
[2039/2236] Building CXX object qa/qa_utils/CMakeFiles/qa_utils.dir/wx_utils/unit_test_utils.cpp.o
[2040/2236] Building CXX object qa/pcbnew_utils/CMakeFiles/qa_pcbnew_utils.dir/board_construction_utils.cpp.o
[2041/2236] Building CXX object kicad/pcm/CMakeFiles/pcm.dir/pcm_task_manager.cpp.o
[2042/2236] Building CXX object qa/qa_utils/CMakeFiles/qa_utils.dir/uuid_test_utils.cpp.o
[2043/2236] Building CXX object qa/pcbnew_utils/CMakeFiles/qa_pcbnew_utils.dir/board_file_utils.cpp.o
[2044/2236] Building CXX object kicad/pcm/CMakeFiles/pcm.dir/pcm.cpp.o
[2045/2236] Building CXX object qa/pcbnew_utils/CMakeFiles/qa_pcbnew_utils.dir/board_test_utils.cpp.o
[2046/2236] Building CXX object qa/schematic_utils/CMakeFiles/qa_schematic_utils.dir/eeschema_test_utils.cpp.o
ninja: build stopped: subcommand failed.

Try using a different linker.

You can use lld or try asking mold maintainer for help.

What is the standard linker the the KiCad devs use?

We use the default linker provided by the standard toolchain on the Linux distros we support. This is generally GNU ld.

Hmm, has any run time errors been connected to the use of lld or gold for that matter as the linker?

Don’t know. You are welcome to experiment with linkers, but if you run into issues, there probably won’t be much help available.

Well gee, it takes me an hour just to find out if the linker will get past this issue. lld seems to work. I suppose I should have just used ld at the start. So, what’s one more hour just to insure my build follows a well trodden path. I just want a KiCad that works. :slight_smile:

Mold unfortunately while a faster linker also has issues the maintainer denies exist (or rather probably too hard for a one man project to cover all the test cases). In particular when kicad simply switched c++17 to c++20 by simply changing the standard flag, mold suddenly produced linker errors that did not exist previously. That can’t even be explained because the gcc object dumps linked similar for the complained about symbols.

The errors you are getting are amusing because they are different then the previous issues that occurred.

Literally every other linker on all platforms works fine. Mold is just special and cutting too many corners.

Kicad builds and links with the std GCC toolchain, gold linker or the clang toolchain (with lld)

Mold and bolt are still quite experimental

1 Like

This level of coding and debugging is rather above my experience level, although I tried to solve this issue with the help of Google’s AI assistant. We went down the rabbit hole for a few hours trying to figure out what was going on here. Apparently, as has been mentioned this is actually a non-existent issue created solely by a mold bug, however my travails wandering though wonderland did raise some interesting questions. Perhaps someone here knows the answers.

So, the problem was stated as an undefined symbol kiface(). I found where kiface() was declared. The assistant stated that the issue with mold arose because mold had trouble finding the related object or library file to link with the object being linked at the time:

Linking CXX executable utils/idftools/idf2vrml

idf2vrml was identified as a utility object, and the objects to link with it were defined in utils/idftools/CMakeLists.txt.

We then traced the linking objects defined for idf2vrml to this bit of code in that file:

    target_link_libraries( idf2vrml
        idf3
        kimath
        common
        ${OPENGL_LIBRARIES}
        ${wxWidgets_LIBRARIES}
        )

This being a non-issue, I would image that ordinarily the common entry or another above takes care of this.

The assistant and I then went off on a tanget investigating kicad_3dsg for it also apparently linked to the object providing kiface().

Anyway, it seems like the list of objects being linked to any particular object are dynamically produced at linking time rather then being defined in some static list somewhere. This supposedly is in part to prevent multiple definition errors at linking time. As I mentioned this is quite above my coding experience, although it makes for an interesting situation. The assistant lacked the ability to determine or explain how the linking lists were being dynamically produced at linking time.

So, my question is, what is going on here with these linking lists in a general way?

So you have lto enabled?

Also these experimental linkers (mold bolt) mess with the link order to speed up but they are experimental for a reason so it’s clearly loosing symbols

Just stick with regular GCC or clang… Maybe use gold-ldd but not mold…

1 Like

Linking is a hugely complex topic, and our compilation and library setup is non-trivial, so I would never expect an LLM-based AI (or any type of AI) to be able to know or reason about what’s going on. (As an aside - see this study for the utility of AI in software engineering: Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity - METR)

If you want to learn about the complexity of linking, there is lots of material out there to study. Start to look at static vs. dynamic linking, how different platforms handle dynamic linking (and how the toolchain linker enables this), how memory layouts work, how linker stubs function, how link time optimisation can help runtime (but not linktime) speed, …

It’s a huge topic.

Basically, all of the above (and more).

Regarding the aside, I have been using various AI assistants to help me with coding a number of Python projects for I suppose over a year now. From that I can draw some conclusions from personal experience. Basically, that AI assistants have limited ability to help with coding. They can be helpful, although that limited to particular ways. The slow down mentioned in the study I can readily believe, because AI assistants are completely context driven, that means you have to take the time to explain exactly what you want from them in full detail. Otherwise they will make presumptions on their own about what to do. That of course then is a gamble as to the usability of the result. Simply having to explain, and quite often re-explain, every detail increases the time spent. If the coder knew what to do in the first place, it very possibly could be faster to just do it.

Also, if the algorithm being implement gets beyond trivial or standard practice, then the AIs have trouble with it. I ended up writing my own Boolean binary tree library because the AIs had trouble finding an existing one that could be adapted to my purposes. It ended up being quite simple, just different from the several that already exist. That one pretty much stumped all the assistants. It was kind of surprising. It would seem AI are weak in creativity. They can mix and match, and find existing solution to known problems although when trying to create a novel algorithm to accomplish a new task they have trouble.

Without wishing to make assumptions of your background knowledge on AI, I’d encourage you to go and study exactly what it is they do, and how they do it. That would make your statement self-evident. They are not creativity machines, they are statistical models based on the characteristics of some latent space which is trained on a whole load of existing data.

2 Likes

Well, are you saying I’m preaching to the choir?

Apparently you know this, although much of the hype about AI is completely detached from the reality of AI.

About me, once upon a time I was a computer science major back when they were still teaching Fortran 77 and IBM 360/390 assembly language, I did well enough in classes, although due to certain adversities I failed to complete a degree. And so I have been limited to just indulging some C coding and lately some Python coding to serve my passing interests.

I have coded a NMIST classifier just for fun. That classifier with some tweaking achieved 93% accuracy with only 39 neurons. The YouTube video that motivated my interest in that effort achieved only 86% accuracy with 29 neurons.

I’ve gone on to study the general structure and training of LLMs, transformers in particular, although have yet to delve into any code with them mostly due to lack of sufficient hardware or funds for extensive cloud use.

I remember back around 2000 looking into playing with neural nets and at that time with the available hardware, a network of four neurons would take hours to train. It was like watching paint dry. So, I left all that alone until just recently.


Thinking about your reply a little more, in regard to this:

“They are not creativity machines, they are statistical models based on the characteristics of some latent space which is trained on a whole load of existing data.”

They are deterministic, although it has been demonstrated, or at least claimed so, that they can apply higher level concepts to new context, and synthesize new information that is absent from their training data. I see this as just part of the pattern recognition function of a neural network. Although artificial neural networks are so much simpler than biological one, it’s amazing that they function at all.

Going massively off-topic, but it’s relevant to the burden that AI-everywhere places on open source software proejcts…

Likewise, back in the early 2000s my early PhD work included coding neural network backpropagation and genetic algorithm training algorithms, and working with the likes of NVidea to look at scaling training across heterogenous multiple GPU and CPU systems. The point is, I’ve been working with ‘AI’ long enough to not drink the kool-aid, but to understand the landscape of the various things-called-AI strengths and weaknesses. The thing that gets me at the moment is the ‘here’s a hard thing in a very difficult context let’s ask an AI to solve it’ approach with little effort to actually learn the topic at hand; it makes more work for maintainers, supports, and suchlike. I worry we’re going to forget how to learn. Hard topics take hard graft to research, learn, fail, find mentors, fail again (but less), etc etc.

I’m no AI rejectionist - I use various AIs daily, but in bounded scopes which work to the task and the model / process / integrations in hand.

Anywho - if you want some decent resource to play with training your own models with Tensorflow, take a look at Google Colab. You can get some beefy training resource for free.

2 Likes

The objects being linked is static. Every gcc produced object file contains a list of exported symbols and additional symbols that need to be “found”/imported to link the final output.

There are ways to workaround the issue in kicad, but we won’t, because it’s not our job to workaround bad linkers that aren’t mainstream.

1 Like

Well, then you might get this. I recognize your concerns and share them. My perspective on the AI revolution is that it is the equivalent of the industrial revolution. In the industrial revolution machines were created that multiplied human physical labor. That is, one human in an excavator can dig the same amount as 50 to 100 humans or more by hand.

The AI revolution is the creation of machines that can multiply human mental labor. My main point about this is that in heavy equipment, a human still drives the machine. One human drives the machine, one human is responsible for what the machine does. As far as AI is concerned I think it should be the same way.

And here is where things go off the rails, and this is because the monied interest want to replace humans with AIs. The want the AI to do all the coding. The value of any product is based on the human input. If there’s an absence of any human input in the product, how is its relative value determined?

If all the production is done by machines, how do the people earn any money to buy any products. If the people lack money to buy any products, how do producers sell anything?

I guess my point is that the development of AI is being misguided by the big money people who are investing to create the big machine that will do everything, and yet give them all the profit.