> On Jul 10, 2018, at 3:15 PM, Thiago Macieira <thi...@macieira.org> wrote: > > On Monday, 9 July 2018 23:31:22 PDT Dirk Hohndel wrote: >> And the same thing is preventing the Qt 5.11 based Android app from working. >> There is some other component or library that we need to select in cmake - >> but I can't figure out what the right keyword might be. On Android it's lib >> declarative_positioning.so that isn't packaged and that one isn't packaged >> because its dependency libQt5PositioningQuick.so is missing. >> >> That sound awfully familiar, doesn't it? > > Yeah. > > My guess is that the deploy applications actually all share the same history > and have the same bug. They work like this (my theory): > 1) check which libraries the application links to > 2) adds regular (non-QML) plugins associated with that library > 3) check what QML imports (including plugins) are needed > > But they don't recheck after #3 if any plugins require libraries the > application doesn't link to. This could be worked around by explicitly > linking > to the new library -- except that library has no public symbols to require, > so > many linkers will just drop it as unnecessary.
So the problem becomes... how do we work around that. Just force the library to be part of the package... is that the way to go? It's what I did for macOS and I think I know how to do that win Windows (but haven't tried, yet). With Android I still haven't figured out how to do that... :-( /D _______________________________________________ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
