-
Notifications
You must be signed in to change notification settings - Fork 704
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
pkgsUseSharedLibrary logic is incorrect #10050
Labels
Comments
This failure is currently manifested in the way that if you write If you pass both |
mpickering
added a commit
to mpickering/cabal
that referenced
this issue
May 24, 2024
Consider the which determines whether we should build shared libraries. pkgsUseSharedLibrary :: Set PackageId pkgsUseSharedLibrary = packagesWithLibDepsDownwardClosedProperty needsSharedLib where needsSharedLib pkg = fromMaybe compilerShouldUseSharedLibByDefault (liftM2 (||) pkgSharedLib pkgDynExe) where pkgid = packageId pkg pkgSharedLib = perPkgOptionMaybe pkgid packageConfigSharedLib pkgDynExe = perPkgOptionMaybe pkgid packageConfigDynExe In English the intended logic is: If we have enabled shared libraries or dynamic executables then we need to build a shared libary. but, a common mistake: (liftM2 (||) pkgSharedLib pkgDynExe) instead says, if we explicitly request shared libraries and also explicitly configure whether we want dynamic executables then build a shared library. It should instead use the monoid instance: getMax <$> ((Max <$> pkgSharedLib) <> (Max <$> pkgDynExe)) which captures the original logic. This failure is currently manifested in the way that if you write --disable-shared then --enable-shared is still passed to ./Setup. If you pass both --disable-shared and --disable-executable-dynamic then you don't build a shared object. Fixes haskell#10050
5 tasks
mpickering
added a commit
to mpickering/cabal
that referenced
this issue
May 24, 2024
Consider the which determines whether we should build shared libraries. pkgsUseSharedLibrary :: Set PackageId pkgsUseSharedLibrary = packagesWithLibDepsDownwardClosedProperty needsSharedLib where needsSharedLib pkg = fromMaybe compilerShouldUseSharedLibByDefault (liftM2 (||) pkgSharedLib pkgDynExe) where pkgid = packageId pkg pkgSharedLib = perPkgOptionMaybe pkgid packageConfigSharedLib pkgDynExe = perPkgOptionMaybe pkgid packageConfigDynExe In English the intended logic is: If we have enabled shared libraries or dynamic executables then we need to build a shared libary. but, a common mistake: (liftM2 (||) pkgSharedLib pkgDynExe) instead says, if we explicitly request shared libraries and also explicitly configure whether we want dynamic executables then build a shared library. It should instead use the monoid instance: getMax <$> ((Max <$> pkgSharedLib) <> (Max <$> pkgDynExe)) which captures the original logic. This failure is currently manifested in the way that if you write --disable-shared then --enable-shared is still passed to ./Setup. If you pass both --disable-shared and --disable-executable-dynamic then you don't build a shared object. Fixes haskell#10050
mpickering
added a commit
to mpickering/cabal
that referenced
this issue
May 29, 2024
New options for cabal.project and ./Setup interface: * `profiling-shared`: Enable building profiling dynamic way * Passing `--enable-profiling` and `--enable-executable-dynamic` builds profiled dynamic executables. Support for using `profiling-shared` is guarded behind a constraint which ensures you are using `Cabal >= 3.13`. In the cabal file: * `ghc-prof-shared-options`, for passing options when building in profiling dynamic way Other miscellenious fixes and improvements * Some refactoring around ways so that which ways we should build for a library, foreign library and executable is computed by the `buildWays` function (rather than ad-hoc in three different places). * Improved logic for detecting whether a compiler supports compiling a specific way. See functions `profilingVanillaSupported`, `dynamicSupported`, `profilingDynamicSupported` etc These functions report accurate infomation after ghc-9.10.1. * Fixed logic for determining whether to build shared libraries. (see haskell#10050) Now, if you explicitly enable `--*-shared`, then that will always take effect. If it's not specified then `--enable-executable-dynamic` will turn on shared libraries IF `--enable-profiling` is not enabled. * Remove assumption that dynamically linked compilers can build dynamic libraries (they might be cross compilers. * Query the build compiler to determine which library way is necessary to be built for TH support to work. (rather than assume all compilers are dynamically linked) * An extensive test which checks how options for `./Setup` and `cabal-install` are translated into build ways. Fixes haskell#4816, haskell#10049, haskell#10050
mpickering
added a commit
to mpickering/cabal
that referenced
this issue
May 29, 2024
New options for cabal.project and ./Setup interface: * `profiling-shared`: Enable building profiling dynamic way * Passing `--enable-profiling` and `--enable-executable-dynamic` builds profiled dynamic executables. Support for using `profiling-shared` is guarded behind a constraint which ensures you are using `Cabal >= 3.13`. In the cabal file: * `ghc-prof-shared-options`, for passing options when building in profiling dynamic way Other miscellenious fixes and improvements * Some refactoring around ways so that which ways we should build for a library, foreign library and executable is computed by the `buildWays` function (rather than ad-hoc in three different places). * Improved logic for detecting whether a compiler supports compiling a specific way. See functions `profilingVanillaSupported`, `dynamicSupported`, `profilingDynamicSupported` etc These functions report accurate infomation after ghc-9.10.1. * Fixed logic for determining whether to build shared libraries. (see haskell#10050) Now, if you explicitly enable `--*-shared`, then that will always take effect. If it's not specified then `--enable-executable-dynamic` will turn on shared libraries IF `--enable-profiling` is not enabled. * Remove assumption that dynamically linked compilers can build dynamic libraries (they might be cross compilers. * Query the build compiler to determine which library way is necessary to be built for TH support to work. (rather than assume all compilers are dynamically linked) * An extensive test which checks how options for `./Setup` and `cabal-install` are translated into build ways. Fixes haskell#4816, haskell#10049, haskell#10050
mpickering
added a commit
to mpickering/cabal
that referenced
this issue
May 29, 2024
New options for cabal.project and ./Setup interface: * `profiling-shared`: Enable building profiling dynamic way * Passing `--enable-profiling` and `--enable-executable-dynamic` builds profiled dynamic executables. Support for using `profiling-shared` is guarded behind a constraint which ensures you are using `Cabal >= 3.13`. In the cabal file: * `ghc-prof-shared-options`, for passing options when building in profiling dynamic way Other miscellenious fixes and improvements * Some refactoring around ways so that which ways we should build for a library, foreign library and executable is computed by the `buildWays` function (rather than ad-hoc in three different places). * Improved logic for detecting whether a compiler supports compiling a specific way. See functions `profilingVanillaSupported`, `dynamicSupported`, `profilingDynamicSupported` etc These functions report accurate infomation after ghc-9.10.1. * Fixed logic for determining whether to build shared libraries. (see haskell#10050) Now, if you explicitly enable `--*-shared`, then that will always take effect. If it's not specified then `--enable-executable-dynamic` will turn on shared libraries IF `--enable-profiling` is not enabled. * Remove assumption that dynamically linked compilers can build dynamic libraries (they might be cross compilers. * Query the build compiler to determine which library way is necessary to be built for TH support to work. (rather than assume all compilers are dynamically linked) * An extensive test which checks how options for `./Setup` and `cabal-install` are translated into build ways. Fixes haskell#4816, haskell#10049, haskell#10050
mpickering
added a commit
to mpickering/cabal
that referenced
this issue
Jun 12, 2024
New options for cabal.project and ./Setup interface: * `profiling-shared`: Enable building profiling dynamic way * Passing `--enable-profiling` and `--enable-executable-dynamic` builds profiled dynamic executables. Support for using `profiling-shared` is guarded behind a constraint which ensures you are using `Cabal >= 3.13`. In the cabal file: * `ghc-prof-shared-options`, for passing options when building in profiling dynamic way Other miscellenious fixes and improvements * Some refactoring around ways so that which ways we should build for a library, foreign library and executable is computed by the `buildWays` function (rather than ad-hoc in three different places). * Improved logic for detecting whether a compiler supports compiling a specific way. See functions `profilingVanillaSupported`, `dynamicSupported`, `profilingDynamicSupported` etc These functions report accurate infomation after ghc-9.10.1. * Fixed logic for determining whether to build shared libraries. (see haskell#10050) Now, if you explicitly enable `--*-shared`, then that will always take effect. If it's not specified then `--enable-executable-dynamic` will turn on shared libraries IF `--enable-profiling` is not enabled. * Remove assumption that dynamically linked compilers can build dynamic libraries (they might be cross compilers. * Query the build compiler to determine which library way is necessary to be built for TH support to work. (rather than assume all compilers are dynamically linked) * An extensive test which checks how options for `./Setup` and `cabal-install` are translated into build ways. Fixes haskell#4816, haskell#10049, haskell#10050
mpickering
added a commit
to mpickering/cabal
that referenced
this issue
Jun 12, 2024
New options for cabal.project and ./Setup interface: * `profiling-shared`: Enable building profiling dynamic way * Passing `--enable-profiling` and `--enable-executable-dynamic` builds profiled dynamic executables. Support for using `profiling-shared` is guarded behind a constraint which ensures you are using `Cabal >= 3.13`. In the cabal file: * `ghc-prof-shared-options`, for passing options when building in profiling dynamic way Other miscellenious fixes and improvements * Some refactoring around ways so that which ways we should build for a library, foreign library and executable is computed by the `buildWays` function (rather than ad-hoc in three different places). * Improved logic for detecting whether a compiler supports compiling a specific way. See functions `profilingVanillaSupported`, `dynamicSupported`, `profilingDynamicSupported` etc These functions report accurate infomation after ghc-9.10.1. * Fixed logic for determining whether to build shared libraries. (see haskell#10050) Now, if you explicitly enable `--*-shared`, then that will always take effect. If it's not specified then `--enable-executable-dynamic` will turn on shared libraries IF `--enable-profiling` is not enabled. * Remove assumption that dynamically linked compilers can build dynamic libraries (they might be cross compilers. * Query the build compiler to determine which library way is necessary to be built for TH support to work. (rather than assume all compilers are dynamically linked) * An extensive test which checks how options for `./Setup` and `cabal-install` are translated into build ways. Fixes haskell#4816, haskell#10049, haskell#10050
mpickering
added a commit
to mpickering/cabal
that referenced
this issue
Jun 12, 2024
New options for cabal.project and ./Setup interface: * `profiling-shared`: Enable building profiling dynamic way * Passing `--enable-profiling` and `--enable-executable-dynamic` builds profiled dynamic executables. Support for using `profiling-shared` is guarded behind a constraint which ensures you are using `Cabal >= 3.13`. In the cabal file: * `ghc-prof-shared-options`, for passing options when building in profiling dynamic way Other miscellenious fixes and improvements * Some refactoring around ways so that which ways we should build for a library, foreign library and executable is computed by the `buildWays` function (rather than ad-hoc in three different places). * Improved logic for detecting whether a compiler supports compiling a specific way. See functions `profilingVanillaSupported`, `dynamicSupported`, `profilingDynamicSupported` etc These functions report accurate infomation after ghc-9.10.1. * Fixed logic for determining whether to build shared libraries. (see haskell#10050) Now, if you explicitly enable `--*-shared`, then that will always take effect. If it's not specified then `--enable-executable-dynamic` will turn on shared libraries IF `--enable-profiling` is not enabled. * Remove assumption that dynamically linked compilers can build dynamic libraries (they might be cross compilers. * Query the build compiler to determine which library way is necessary to be built for TH support to work. (rather than assume all compilers are dynamically linked) * An extensive test which checks how options for `./Setup` and `cabal-install` are translated into build ways. Fixes haskell#4816, haskell#10049, haskell#10050
mpickering
added a commit
to mpickering/cabal
that referenced
this issue
Jun 17, 2024
New options for cabal.project and ./Setup interface: * `profiling-shared`: Enable building profiling dynamic way * Passing `--enable-profiling` and `--enable-executable-dynamic` builds profiled dynamic executables. Support for using `profiling-shared` is guarded behind a constraint which ensures you are using `Cabal >= 3.13`. In the cabal file: * `ghc-prof-shared-options`, for passing options when building in profiling dynamic way Other miscellenious fixes and improvements * Some refactoring around ways so that which ways we should build for a library, foreign library and executable is computed by the `buildWays` function (rather than ad-hoc in three different places). * Improved logic for detecting whether a compiler supports compiling a specific way. See functions `profilingVanillaSupported`, `dynamicSupported`, `profilingDynamicSupported` etc These functions report accurate infomation after ghc-9.10.1. * Fixed logic for determining whether to build shared libraries. (see haskell#10050) Now, if you explicitly enable `--*-shared`, then that will always take effect. If it's not specified then `--enable-executable-dynamic` will turn on shared libraries IF `--enable-profiling` is not enabled. * Remove assumption that dynamically linked compilers can build dynamic libraries (they might be cross compilers. * Query the build compiler to determine which library way is necessary to be built for TH support to work. (rather than assume all compilers are dynamically linked) * An extensive test which checks how options for `./Setup` and `cabal-install` are translated into build ways. Fixes haskell#4816, haskell#10049, haskell#10050
mpickering
added a commit
to mpickering/cabal
that referenced
this issue
Jun 17, 2024
New options for cabal.project and ./Setup interface: * `profiling-shared`: Enable building profiling dynamic way * Passing `--enable-profiling` and `--enable-executable-dynamic` builds profiled dynamic executables. Support for using `profiling-shared` is guarded behind a constraint which ensures you are using `Cabal >= 3.13`. In the cabal file: * `ghc-prof-shared-options`, for passing options when building in profiling dynamic way Other miscellenious fixes and improvements * Some refactoring around ways so that which ways we should build for a library, foreign library and executable is computed by the `buildWays` function (rather than ad-hoc in three different places). * Improved logic for detecting whether a compiler supports compiling a specific way. See functions `profilingVanillaSupported`, `dynamicSupported`, `profilingDynamicSupported` etc These functions report accurate infomation after ghc-9.10.1. * Fixed logic for determining whether to build shared libraries. (see haskell#10050) Now, if you explicitly enable `--*-shared`, then that will always take effect. If it's not specified then `--enable-executable-dynamic` will turn on shared libraries IF `--enable-profiling` is not enabled. * Remove assumption that dynamically linked compilers can build dynamic libraries (they might be cross compilers. * Query the build compiler to determine which library way is necessary to be built for TH support to work. (rather than assume all compilers are dynamically linked) * An extensive test which checks how options for `./Setup` and `cabal-install` are translated into build ways. Fixes haskell#4816, haskell#10049, haskell#10050
mpickering
added a commit
to mpickering/cabal
that referenced
this issue
Jun 18, 2024
New options for cabal.project and ./Setup interface: * `profiling-shared`: Enable building profiling dynamic way * Passing `--enable-profiling` and `--enable-executable-dynamic` builds profiled dynamic executables. Support for using `profiling-shared` is guarded behind a constraint which ensures you are using `Cabal >= 3.13`. In the cabal file: * `ghc-prof-shared-options`, for passing options when building in profiling dynamic way Other miscellenious fixes and improvements * Some refactoring around ways so that which ways we should build for a library, foreign library and executable is computed by the `buildWays` function (rather than ad-hoc in three different places). * Improved logic for detecting whether a compiler supports compiling a specific way. See functions `profilingVanillaSupported`, `dynamicSupported`, `profilingDynamicSupported` etc These functions report accurate infomation after ghc-9.10.1. * Fixed logic for determining whether to build shared libraries. (see haskell#10050) Now, if you explicitly enable `--*-shared`, then that will always take effect. If it's not specified then `--enable-executable-dynamic` will turn on shared libraries IF `--enable-profiling` is not enabled. * Remove assumption that dynamically linked compilers can build dynamic libraries (they might be cross compilers. * Query the build compiler to determine which library way is necessary to be built for TH support to work. (rather than assume all compilers are dynamically linked) * An extensive test which checks how options for `./Setup` and `cabal-install` are translated into build ways. Fixes haskell#4816, haskell#10049, haskell#10050
mpickering
added a commit
to mpickering/cabal
that referenced
this issue
Jun 18, 2024
New options for cabal.project and ./Setup interface: * `profiling-shared`: Enable building profiling dynamic way * Passing `--enable-profiling` and `--enable-executable-dynamic` builds profiled dynamic executables. Support for using `profiling-shared` is guarded behind a constraint which ensures you are using `Cabal >= 3.13`. In the cabal file: * `ghc-prof-shared-options`, for passing options when building in profiling dynamic way Other miscellenious fixes and improvements * Some refactoring around ways so that which ways we should build for a library, foreign library and executable is computed by the `buildWays` function (rather than ad-hoc in three different places). * Improved logic for detecting whether a compiler supports compiling a specific way. See functions `profilingVanillaSupported`, `dynamicSupported`, `profilingDynamicSupported` etc These functions report accurate infomation after ghc-9.10.1. * Fixed logic for determining whether to build shared libraries. (see haskell#10050) Now, if you explicitly enable `--*-shared`, then that will always take effect. If it's not specified then `--enable-executable-dynamic` will turn on shared libraries IF `--enable-profiling` is not enabled. * Remove assumption that dynamically linked compilers can build dynamic libraries (they might be cross compilers. * Query the build compiler to determine which library way is necessary to be built for TH support to work. (rather than assume all compilers are dynamically linked) * An extensive test which checks how options for `./Setup` and `cabal-install` are translated into build ways. Fixes haskell#4816, haskell#10049, haskell#10050
mpickering
added a commit
to mpickering/cabal
that referenced
this issue
Jun 19, 2024
New options for cabal.project and ./Setup interface: * `profiling-shared`: Enable building profiling dynamic way * Passing `--enable-profiling` and `--enable-executable-dynamic` builds profiled dynamic executables. Support for using `profiling-shared` is guarded behind a constraint which ensures you are using `Cabal >= 3.13`. In the cabal file: * `ghc-prof-shared-options`, for passing options when building in profiling dynamic way Other miscellenious fixes and improvements * Some refactoring around ways so that which ways we should build for a library, foreign library and executable is computed by the `buildWays` function (rather than ad-hoc in three different places). * Improved logic for detecting whether a compiler supports compiling a specific way. See functions `profilingVanillaSupported`, `dynamicSupported`, `profilingDynamicSupported` etc These functions report accurate infomation after ghc-9.10.1. * Fixed logic for determining whether to build shared libraries. (see haskell#10050) Now, if you explicitly enable `--*-shared`, then that will always take effect. If it's not specified then `--enable-executable-dynamic` will turn on shared libraries IF `--enable-profiling` is not enabled. * Remove assumption that dynamically linked compilers can build dynamic libraries (they might be cross compilers. * Query the build compiler to determine which library way is necessary to be built for TH support to work. (rather than assume all compilers are dynamically linked) * An extensive test which checks how options for `./Setup` and `cabal-install` are translated into build ways. Fixes haskell#4816, haskell#10049, haskell#10050
mpickering
added a commit
to mpickering/cabal
that referenced
this issue
Jun 19, 2024
New options for cabal.project and ./Setup interface: * `profiling-shared`: Enable building profiling dynamic way * Passing `--enable-profiling` and `--enable-executable-dynamic` builds profiled dynamic executables. Support for using `profiling-shared` is guarded behind a constraint which ensures you are using `Cabal >= 3.13`. In the cabal file: * `ghc-prof-shared-options`, for passing options when building in profiling dynamic way Other miscellenious fixes and improvements * Some refactoring around ways so that which ways we should build for a library, foreign library and executable is computed by the `buildWays` function (rather than ad-hoc in three different places). * Improved logic for detecting whether a compiler supports compiling a specific way. See functions `profilingVanillaSupported`, `dynamicSupported`, `profilingDynamicSupported` etc These functions report accurate infomation after ghc-9.10.1. * Fixed logic for determining whether to build shared libraries. (see haskell#10050) Now, if you explicitly enable `--*-shared`, then that will always take effect. If it's not specified then `--enable-executable-dynamic` will turn on shared libraries IF `--enable-profiling` is not enabled. * Remove assumption that dynamically linked compilers can build dynamic libraries (they might be cross compilers. * Query the build compiler to determine which library way is necessary to be built for TH support to work. (rather than assume all compilers are dynamically linked) * An extensive test which checks how options for `./Setup` and `cabal-install` are translated into build ways. Fixes haskell#4816, haskell#10049, haskell#10050
mpickering
added a commit
to mpickering/cabal
that referenced
this issue
Jun 19, 2024
New options for cabal.project and ./Setup interface: * `profiling-shared`: Enable building profiling dynamic way * Passing `--enable-profiling` and `--enable-executable-dynamic` builds profiled dynamic executables. Support for using `profiling-shared` is guarded behind a constraint which ensures you are using `Cabal >= 3.13`. In the cabal file: * `ghc-prof-shared-options`, for passing options when building in profiling dynamic way Other miscellenious fixes and improvements * Some refactoring around ways so that which ways we should build for a library, foreign library and executable is computed by the `buildWays` function (rather than ad-hoc in three different places). * Improved logic for detecting whether a compiler supports compiling a specific way. See functions `profilingVanillaSupported`, `dynamicSupported`, `profilingDynamicSupported` etc These functions report accurate infomation after ghc-9.10.1. * Fixed logic for determining whether to build shared libraries. (see haskell#10050) Now, if you explicitly enable `--*-shared`, then that will always take effect. If it's not specified then `--enable-executable-dynamic` will turn on shared libraries IF `--enable-profiling` is not enabled. * Remove assumption that dynamically linked compilers can build dynamic libraries (they might be cross compilers. * Query the build compiler to determine which library way is necessary to be built for TH support to work. (rather than assume all compilers are dynamically linked) * An extensive test which checks how options for `./Setup` and `cabal-install` are translated into build ways. Fixes haskell#4816, haskell#10049, haskell#10050
Mikolaj
pushed a commit
to mpickering/cabal
that referenced
this issue
Jun 25, 2024
New options for cabal.project and ./Setup interface: * `profiling-shared`: Enable building profiling dynamic way * Passing `--enable-profiling` and `--enable-executable-dynamic` builds profiled dynamic executables. Support for using `profiling-shared` is guarded behind a constraint which ensures you are using `Cabal >= 3.13`. In the cabal file: * `ghc-prof-shared-options`, for passing options when building in profiling dynamic way Other miscellenious fixes and improvements * Some refactoring around ways so that which ways we should build for a library, foreign library and executable is computed by the `buildWays` function (rather than ad-hoc in three different places). * Improved logic for detecting whether a compiler supports compiling a specific way. See functions `profilingVanillaSupported`, `dynamicSupported`, `profilingDynamicSupported` etc These functions report accurate infomation after ghc-9.10.1. * Fixed logic for determining whether to build shared libraries. (see haskell#10050) Now, if you explicitly enable `--*-shared`, then that will always take effect. If it's not specified then `--enable-executable-dynamic` will turn on shared libraries IF `--enable-profiling` is not enabled. * Remove assumption that dynamically linked compilers can build dynamic libraries (they might be cross compilers. * Query the build compiler to determine which library way is necessary to be built for TH support to work. (rather than assume all compilers are dynamically linked) * An extensive test which checks how options for `./Setup` and `cabal-install` are translated into build ways. Fixes haskell#4816, haskell#10049, haskell#10050
Now fixed. |
erikd
pushed a commit
to erikd/cabal
that referenced
this issue
Jan 9, 2025
New options for cabal.project and ./Setup interface: * `profiling-shared`: Enable building profiling dynamic way * Passing `--enable-profiling` and `--enable-executable-dynamic` builds profiled dynamic executables. Support for using `profiling-shared` is guarded behind a constraint which ensures you are using `Cabal >= 3.13`. In the cabal file: * `ghc-prof-shared-options`, for passing options when building in profiling dynamic way Other miscellenious fixes and improvements * Some refactoring around ways so that which ways we should build for a library, foreign library and executable is computed by the `buildWays` function (rather than ad-hoc in three different places). * Improved logic for detecting whether a compiler supports compiling a specific way. See functions `profilingVanillaSupported`, `dynamicSupported`, `profilingDynamicSupported` etc These functions report accurate infomation after ghc-9.10.1. * Fixed logic for determining whether to build shared libraries. (see haskell#10050) Now, if you explicitly enable `--*-shared`, then that will always take effect. If it's not specified then `--enable-executable-dynamic` will turn on shared libraries IF `--enable-profiling` is not enabled. * Remove assumption that dynamically linked compilers can build dynamic libraries (they might be cross compilers. * Query the build compiler to determine which library way is necessary to be built for TH support to work. (rather than assume all compilers are dynamically linked) * An extensive test which checks how options for `./Setup` and `cabal-install` are translated into build ways. Fixes haskell#4816, haskell#10049, haskell#10050
erikd
pushed a commit
to erikd/cabal
that referenced
this issue
Jan 9, 2025
New options for cabal.project and ./Setup interface: * `profiling-shared`: Enable building profiling dynamic way * Passing `--enable-profiling` and `--enable-executable-dynamic` builds profiled dynamic executables. Support for using `profiling-shared` is guarded behind a constraint which ensures you are using `Cabal >= 3.13`. In the cabal file: * `ghc-prof-shared-options`, for passing options when building in profiling dynamic way Other miscellenious fixes and improvements * Some refactoring around ways so that which ways we should build for a library, foreign library and executable is computed by the `buildWays` function (rather than ad-hoc in three different places). * Improved logic for detecting whether a compiler supports compiling a specific way. See functions `profilingVanillaSupported`, `dynamicSupported`, `profilingDynamicSupported` etc These functions report accurate infomation after ghc-9.10.1. * Fixed logic for determining whether to build shared libraries. (see haskell#10050) Now, if you explicitly enable `--*-shared`, then that will always take effect. If it's not specified then `--enable-executable-dynamic` will turn on shared libraries IF `--enable-profiling` is not enabled. * Remove assumption that dynamically linked compilers can build dynamic libraries (they might be cross compilers. * Query the build compiler to determine which library way is necessary to be built for TH support to work. (rather than assume all compilers are dynamically linked) * An extensive test which checks how options for `./Setup` and `cabal-install` are translated into build ways. Fixes haskell#4816, haskell#10049, haskell#10050
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Consider the which determines whether we should build shared libraries.
In English the intended logic is:
If we have enabled shared libraries or dynamic executables then we need shared libraries for all dependencies.
but, a common mistake:
instead says, if we explicitly request shared libraries and also explicitly configure whether we want dynamic executables then
It should instead use the monoid instance:
The text was updated successfully, but these errors were encountered: