kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

Ian,

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.

Cheers,

Wayne

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
>         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
>         <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
>