← Back to team overview

kicad-developers team mailing list archive

Re: Linker Error (self made...)



I'm guessing that getting rid of the circular build dependencies would
probably get rid of most if not all of these issues so I'm all for this.



On 8/28/19 5:33 AM, Ian McInerney wrote:
> 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.
> -Ian
> On Wed, Aug 28, 2019 at 10:47 AM Ian McInerney <Ian.S.McInerney@xxxxxxxx
> <mailto:Ian.S.McInerney@xxxxxxxx>> wrote:
>     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 <mailto: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
>         <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>         Unsubscribe : https://launchpad.net/~kicad-developers
>         More help   : https://help.launchpad.net/ListHelp
> _______________________________________________
> 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