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.mciner...@ieee.org > <mailto:ian.s.mciner...@ieee.org>> 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.rich...@hogyros.de <mailto:simon.rich...@hogyros.de>> 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@lists.launchpad.net > <mailto:kicad-developers@lists.launchpad.net> > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
