Bug#627132: New "-custom" binary generation breaks stack backtraces
SMcC> The "strip"ping problem that appeared to motivate the new
SMcC> embedding process had never bothered us, so another suitable
SMcC> workaround from our perspective would be if there was a way to
SMcC> disable the new "-output-obj"-style behavior.
SG> On 05/24/2011 11:41 AM, Stéphane Glondu wrote:
SG> I am working on that...
[...]
SG> Actually, there is already one: just put "c" in an environment
SG> variable called "OCAML_COMPAT" to get the upstream behaviour.
SG> Is that enough for you?
It's an effective workaround for the problem I mentioned in the
original email, yes. IMO, the one way in which it feels like a
workaround rather than a proper solution is that it's still a
divergence from the upstream behavior, but once you know about the
issue it's not hard to set the environment variable.
What we actually chose to do as the default behavior for the project
where this arose is to switch to just compiling a native code binary
with debugging symbols. This makes sense for us because we mostly care
just about backtraces and not running "ocamldebug", and skipping the
bytecode makes the build process noticeably faster. So in that sense
none of the issues fixed under this bug have been blocking us.
Though maybe what you're really asking is whether you should close
this bug? As I understand the history you forked off and then resolved
two sub-bugs, which make possible two different solutions/workarounds
to the problem I originally posed:
#627756 Sys.executable_name is not set properly by caml_startup_code
#627761 provide a way to use legacy custom linking
Setting those aside, I guess this original bug stands for the
proposition that certain ways of ways of generating an executable with
"-custom", which work to produce debuggable executables on previous
and upstream versions of ocaml, produce non-debuggable executables
when one uses the same compilation command with the current Debian
version. There are a number of workarounds for this issue, as the
previous messages discuss. Because of that, I'd gotten the impression
that you did not consider fixing the original issue a very high
priority, but I still think doing so would be technically possible,
and would have some value in making the Debian version of OCaml "just
work" for more use cases.
So my personal opinion is that the original bug isn't really "fixed",
but it's close enough that I think it would be within your
maintainer's discretion to declare it so. Or alternatively this feels
somewhat like a "help" or "wontfix" situation, though it's not a
perfect match for either of those either IMO.
Thanks,
-- Stephen
Reply to: