← Back to team overview

kicad-developers team mailing list archive

Re: Linker Error (self made...)


Correction, dxf2idf didn't need gal, it needed opengl as a dependency
(which also wans't specified in the CMakeLists.txt file...). But now I will
still run into the circular dependency problem that John posted in that bug
report, so I still want to refactor the common library into smaller chunks.


On Wed, Aug 28, 2019 at 10:47 AM 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
>> 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

Follow ups