Hi Thiago. Thanks for this. My link dependencies do presently obey this constraint (directed acyclic graph), but I’ll add the setting you suggest to enforce that! :->
Cheers, -B. Benjamin C. Haller Messer Lab Cornell University > On Apr 29, 2020, at 11:43 PM, Thiago Macieira <thiago.macie...@intel.com> > wrote: > > On Wednesday, 29 April 2020 18:57:24 PDT Ben Haller via Interest wrote: >> Aha! And I figured out that the order in which I declare the dependencies >> in my .pro file determines the order in which those dependencies appear in >> the link command. I fixed that, and now it builds. >> >> I guess this was not biting me before because I used to link these >> internal libraries dynamically instead; perhaps the link order is not >> important with dynamic linking? > > Correct, searching for symbols in dynamic libraries is different because the > linker searches all of them. It doesn't need to solve from one to the other, > since that was resolved when each library was itself linked. > > Hint: make sure you're using -Wl,--no-undefined. In your .pro file, for each > library and plugin: > > QMAKE_LFLAGS += $$QMAKE_LFLAGS_NOUNDEF > >> So when I recently changed to static >> linking for these internal libraries, the link order suddenly mattered, and >> my build broke. And I guess perhaps the linker on macOS doesn’t have this >> requirement, and so the build continued to work there? > > I don't know how the Apple linker works. > > The traditional linker works sequentially to avoid a very long link time. > After it's created the list of all outstanding undefined symbols from your > binary's .o files, it iterates over the library list. For each one, it checks > if the library solves some symbols and then each individual .o in the static > library to the build. After that, it promptly forgets about the library and > moves on to the next one. That's why libB.a can't depend on libA.a: the > linker > won't search it again. > > If it did, you could write: > -lA -lB -lA > > Then the linker will search libA.a again for other .o that have symbols that > libB requires. > > Note that this may add .o that need more symbols from libB.a that haven't > been > added to the build yet. That means your linker line would need to be: > > -lA -lB -lA -lB > > This isn't infinite because there's a finite number of .o files in each > library. The GNU linker has a shorthand for this but I won't mention it here. > Read the docs if needed. > > Conclusion: break the cycle. The library dependency graph should be one way > (directed acyclic graph). That's why I recommended that --no-undefined for > dynamic linking: it'll prevent you from making the cycles. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel System Software Products > > > > _______________________________________________ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest _______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest