kicad-developers team mailing list archive

[Ian McInerney <Ian.S.McInerney@xxxxxxxx>]

Thanks for the pointers. After digging into this some more, I think what is
happening is that including the sanitizers changes the behavior of the
linker. It seems that it really doesn't like undefined symbols when linking
executables, even if there is no visible dependency path that leads to
them. I have resolved the issues on the main executables by resurrecting
the singletop library and linking the main executables off of that. So far
that seems to have fixed the issues with the main programs.

Now though I am being bitten by this for some of the utility programs, such
as dxf2idf. In this case, it seems it requies gal and the trigo.cpp file,
and these look to be valid dependencies (there are calls made from
vrml_layer.cpp to them). I am somewhat surprised, since these were not
given as link targets originally. The problem is that including gal
requires common currently (https://bugs.launchpad.net/kicad/+bug/1832229),
so it ends up with similar undefined references to Pgm() and Kiface(),
which makes sense since these tools don't need them.

I think that the only way to really fix this is to split common up into
some smaller units, to try to separate some of these dependencies (and in
the process resolve that circular dependency). My thoughts are to at least
create the following new libraries:
edacommon (contains the base frame, library management, tool framework,
plotters, etc.)
utilities (contains the simple files that provide helper functions, such as
utf8, exceptions, base_units, dlist, etc.)
kimath (contains the geometry folder + some other related math functions)
ui (contains the dialogs, widgets, and custom UI classes)

My hope here is that this will make it so it is easier to link these
smaller utilities into only what they need (such as the kimath/utilities)
without bringing in the entire EDA frame stack (since that seems to be the
root cause of these reference issues).

Thoughts?
-Ian


On Tue, Aug 27, 2019 at 1:43 PM Simon Richter <Simon.Richter@xxxxxxxxxx>
wrote:

> Hi,
>
> On Tue, Aug 27, 2019 at 02:56:37AM +0200, Ian McInerney wrote:
>
> > I was trying to do a fresh build of master with the address sanitizer
> > enabled in Clang, and I am receiving a strange linker error, and was
> > curious if anyone else had any thoughts on it.
>
> I fixed a similar error on MSVC once. MSVC encodes the return type in the
> mangled symbol, while gcc does not, and the build fell over on MSVC because
> we had two different declarations for Pgm(), one returning a reference to
> PGM_BASE, the other returning a reference to a compatible type (so this
> wasn't a runtime problem).
>
> My suspicion is that something similar is going on here. This could be
> something stupid even like a mismatch in compiler flags (which are a mix of
> CMAKE_CXX_FLAGS, CMAKE_SHARED_LINKER_FLAGS, CMAKE_MODULE_LINKER_FLAGS and
> CMAKE_EXE_LINKER_FLAGS).
>
> Compiling with -flto on gcc gives a few warnings[1] about different types
> being used in the 3D viewer, usually related to GLM vector types (so
> presumably different translation units use different preprocessor macros
> when including GLM), but nothing Kiface related (this wouldn't catch any
> mismatch in modules that are not linked together though).
>
>    Simon
>
> [1]
> https://jenkins.simonrichter.eu/job/linux-kicad-head-lto/lastStableBuild/gcc/
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>