-dynamic-too is not enabled for local library dependencies

[mpickering]

If I have two local libraries in a cabal file then cabal is not smart enough to realise that if I use TemplateHaskell in one, then it must compile dynamic objects for anything it depends on (including local libraries).

Project: https://gist.github.com/1b44efb4e80108c562efa68fac9518a8

> cabal build th-test
Resolving dependencies...
Build profile: -w ghc-8.10.4 -O1
In order, the following will be built (use -v for more details):
 - th-test-0.1.0.0 (lib:library-a) (first run)
 - th-test-0.1.0.0 (lib) (first run)
Configuring library 'library-a' for th-test-0.1.0.0..
Warning: The 'license-file' field refers to the file 'LICENSE' which does not
exist.
Preprocessing library 'library-a' for th-test-0.1.0.0..
Building library 'library-a' for th-test-0.1.0.0..
[1 of 1] Compiling A                ( library-a/A.hs, /home/matt/cabal/cabal-th-test/dist-newstyle/build/x86_64-linux/ghc-8.10.4/th-test-0.1.0.0/l/library-a/build/library-a/A.o )
Configuring library for th-test-0.1.0.0..
Warning: The package has an extraneous version range for a dependency on an
internal library: th-test:library-a >=0 && ==0.1.0.0. This version range
includes the current package but isn't needed as the current package's library
will always be used.
Warning: The 'license-file' field refers to the file 'LICENSE' which does not
exist.
Preprocessing library for th-test-0.1.0.0..
Building library for th-test-0.1.0.0..
[1 of 1] Compiling B                ( B.hs, /home/matt/cabal/cabal-th-test/dist-newstyle/build/x86_64-linux/ghc-8.10.4/th-test-0.1.0.0/build/B.o, /home/matt/cabal/cabal-th-test/dist-newstyle/build/x86_64-linux/ghc-8.10.4/th-test-0.1.0.0/build/B.dyn_o )

<no location info>: warning: [-Wmissed-extra-shared-lib]
    libHSth-test-0.1.0.0-inplace-library-a.so: cannot open shared object file: No such file or directory
    It's OK if you don't want to use symbols from it directly.
    (the package DLL is loaded by the system linker
     which manages dependencies by itself).
ghc: ^^ Could not load 'thzmtestzm0zi1zi0zi0zminplacezmlibraryzma_A_a_closure', dependency unresolved. See top entry above.


ByteCodeLink.lookupCE
During interactive linking, GHCi couldn't find the following symbol:
  thzmtestzm0zi1zi0zi0zminplacezmlibraryzma_A_a_closure
This may be due to you not asking GHCi to load extra object files,
archives or DLLs needed by your current session.  Restart GHCi, specifying
the missing library using the -L/path/to/object/dir and -lmissinglibname
flags, or simply by naming the relevant files on the GHCi command line.
Alternatively, this link failure might indicate a bug in GHCi.
If you suspect the latter, please report this as a GHC bug:
  https://www.haskell.org/ghc/reportabug

We should realise that we need shared object file for library-a as well, and produce this by using -dynamic-too.

[Mikolaj]

I guess that needs a fix and tests (existing tests don't suffice, because otherwise they'd catch the problem). If the tests show any tricky problems, we'd discuss further. Any volunteers?

[philderbeast]

@alt-romes would this reproduction make a good test for -dynamic-too?