Building dynamic profiled libraries? #4816
Assignees
Comments
|
To be clear, loading a profiled plugin is only useful when GHC is profiled, because a profiled plugin needs a profiled runtime. So this capability would be a lot less useful than you would think (although, certainly, we should support it...) |
|
Yes, that is true; this was the case that I encountered although my ticket description confused things. I've fixed the text. |
|
I have a use-case for profiled dynamic libraries, and might be able to implement this. The ways of building a library seem to be driven by |
|
In our thesis we ran into an additional use case. We wanted to run profiling on a file containing the Suspect it is then impossible to use Cabal with profiling for anything using the |
4 tasks
mpickering
added a commit
to mpickering/cabal
that referenced
this issue
May 16, 2024
New options for cabal.project and ./Setup interface: * `profiling-shared`: Enable building profiling dynamic way * `library-profiling-only`: Only build profiling libraries (not vanilla and profiling) 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 Fixes haskell#4816
mpickering
added a commit
to mpickering/cabal
that referenced
this issue
May 17, 2024
New options for cabal.project and ./Setup interface: * `profiling-shared`: Enable building profiling dynamic way * `library-profiling-only`: Only build profiling libraries (not vanilla and profiling) 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 Fixes haskell#4816
mpickering
added a commit
to mpickering/cabal
that referenced
this issue
May 17, 2024
New options for cabal.project and ./Setup interface: * `profiling-shared`: Enable building profiling dynamic way 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 Fixes haskell#4816
mpickering
added a commit
to mpickering/cabal
that referenced
this issue
May 22, 2024
New options for cabal.project and ./Setup interface: * `profiling-shared`: Enable building profiling dynamic way 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 Fixes haskell#4816
mpickering
added a commit
to mpickering/cabal
that referenced
this issue
May 22, 2024
New options for cabal.project and ./Setup interface: * `profiling-shared`: Enable building profiling dynamic way 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 Fixes haskell#4816
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
This issue was closed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently it seems that there is no way to convince Cabal to build libraries in the
dyn_pway. This renders it impossible to build projects which have plugin build dependencies with profiling enabled. The reason for this is that a profiledghcwill attempt to load the plugin built in the profiled way, which does not exist.The text was updated successfully, but these errors were encountered: