Le 16/11/2011 00:07, Stephen McCamant a écrit :
> 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" situatio
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 wr
On 05/24/2011 11:41 AM, Stéphane Glondu wrote:
>> The "strip"ping problem that appeared to motivate the new embedding
>> process had never bothered us, so another suitable workaround from our
>> perspective would be if there was a way to disable the
>> new "-output-obj"-style behavior.
>
> I am wo
Processing commands for cont...@bugs.debian.org:
> clone 627132 -1
Bug#627132: New "-custom" binary generation breaks stack backtraces
Bug 627132 cloned as bug 627761.
> retitle -1 provide a way to use legacy custom linking
Bug #627761 [ocaml] New "-custom" bina
clone 627132 -1
retitle -1 provide a way to use legacy custom linking
thanks
Le 17/05/2011 23:33, Stephen McCamant a écrit :
The "strip"ping problem that appeared to motivate the new embedding
process had never bothered us, so another suitable workaround from our
perspective would be if there wa
Processing commands for cont...@bugs.debian.org:
> clone 627132 -1
Bug#627132: New "-custom" binary generation breaks stack backtraces
Bug 627132 cloned as bug 627756.
> retitle -1 Sys.executable_name is not set properly by caml_startup_code
Bug #627756 [ocaml] New "-cust
clone 627132 -1
retitle -1 Sys.executable_name is not set properly by caml_startup_code
severity -1 important
thanks
Le 20/05/2011 03:11, Stephen McCamant a écrit :
I haven't checked the source code for this, but my first guess is that
the program might be trying to find its own executable by lo
> "SG" == Stephane Glondu writes:
SG> Le 17/05/2011 23:33, Stephen McCamant a ecrit :
SMcC> [...] another suitable workaround from our perspective would be
SMcC> if there was a way to disable the new "-output-obj"-style
SMcC> behavior.
SG> The previous behaviour was compiling a runtime (as w
Le 17/05/2011 23:33, Stephen McCamant a écrit :
> [...] another suitable workaround from our
> perspective would be if there was a way to disable the
> new "-output-obj"-style behavior.
The previous behaviour was compiling a runtime (as with -make-runtime),
a pure bytecode using this runtime (as w
On Tue, May 17, 2011 at 02:33:26PM -0700, Stephen McCamant wrote:
> We have a large OCaml application that links with a number of
> native-code libraries; we use native-code compilation for most
> purposes, but also use byte compilation specifically to support
> debugging. In particular we run with
Package: ocaml
Version: 3.12.0-5
Severity: normal
It appears that the new "-output-obj" style strategy for generating
-custom bytecode executables
(cf. patches/0011-Embed-bytecode-in-C-object-when-using-custom.patch)
has broken the normal usage of stack backtraces in such executables.
We have a la
11 matches
Mail list logo
