-g not used at link time
UnixJunkie opened this issue · 18 comments
Steps to reproduce, in any obuild project with -g in the oflags:
obuild configure --enable-executable-bytecode --enable-library-bytecode
obuild --debug+ build # look for -g in the linking command, it is not there
export OCAMLRUNPARAM=b
then run your exe throwing an exception; it will say:
(Cannot print stack backtrace: program not linked with -g)
Here is a minimalistic project to reproduce the behavior I observe:
https://github.com/UnixJunkie/obuild-bug-02
I use obuild 0.1.3 from opam
Even if you use --enable-executable-debugging during configure?
That's how you're supposed to set -g.
I guess --enable-executable-debugging during configure will work.
It is not cool however that -g was ignored / not used at compile time.
It would have been nice if obuild warned me about the -g option in oflags
and told me to use --enable-executable-debugging at configure time instead.
You should not use -g in oflags, since there is an option to do it (maybe) consistently for every case (bytecode, native, library, executable, etc.).
oflags is for exceptional cases (special warnings, etc.).
However, oflags is pretty limited because (not at link, etc.) because many options are mutually exclusive. So, a more comprehensive API would be nice. It would be interesting to know how oasis and other build systems are dealing with additional parameters for the toolchain.
I understand.
Maybe we should detect -g in oflags and report a configuration error then.
With oasis, I was forced to edit the header of the Makefile
(automatically generated by oasis) in a special section where
you can pass extra options to ocamlbuild.
I didn't like it: it scatters the build description, reflecting one of the many drawbacks
of ocamlbuild.
@gildor478 may know more
I don't want to provide an obuild API for each option (it wouldn't be maintainable), but it is useful to have a way to pass extra options for each tool at each stage (assuming the user is skilled enough to understand what she/he's doing).
So, there are ocamlc, ocamlopt, and 2 stages, build and link (including with C code).
Ideally, an expression to check the tool version should be provided too.
Am I missing something ?
ocaml has both cryptic options and non consistent usage, that an API for each options is the only good choice so that you don't end up with mutually exclusive opts in the CLI, properly used options, plus also a way to provides a more high level api. It's also the only way to deal with compiler versioning properly, and filter things that are not supported (or do something else)
oflags is just a useful stop-gap until obuild get to this point, but it's clearly a bad solution to expose if/when obuild reach perfection.
I think we already had in the past @jpdeplaix wanting to pass very specific options to menhir.
The feature just suggested by @jeromemaloberti looks quite useful.
well again, extra options per tools, is a fine stop-gap because realistically, unless more people contribute to obuild, it's never going to "get there". But it's also going to create new problems of weird failures.
@UnixJunkie can you be more precise in your question ?
You can run 'ocaml setup.ml -configure --enable-debug' to turn on the -g flag when compiling. As for OCAMLRUNPARAM=b you should set it in your environment (because it is meant to be that way).
I probably don't understand your question and I am not sure what kind of editing you have to do in oasis generated files.
I think -g in oflags should generate a warning at configure time, at least.
I can try to provide this fix if maintainers are OK with it.
No, I don't see the point of that kind of check.
A better documentation is better.
Oflags is useful only for compilation flags that are common to ocamlopt and ocamlc, there are not so many. It should only be used by expert users.
A non exhaustive list: -rectypes, special warnings (safe-string), unsafe, -ppx (until a good API is implemented in obuild).
So, is the fix to enforce that oflags contain only options which are common to both ocamlc and ocamlopt?
I guess this will be compiler-version dependent.
There is no fix :), because there is no bug. oflags is intended to be used in case of emergency. -g is not one of them.
Maybe there should be configure --enable-debug (instead one option for executable and one for libs), that would make it harder to miss.
We should be user friendly: passing silently things under the carpet is not cool.
oflags is a hack, so by definition it is not user friendly, and not intended to be, nobody should use it without understanding its danger.