* [Caml-list] Suggest ocamlopt's -dstartup place file locally, like -S does.
@ 2002-10-10 16:55 Mitchell N Charity
2002-10-10 17:57 ` Chris Hecker
0 siblings, 1 reply; 4+ messages in thread
From: Mitchell N Charity @ 2002-10-10 16:55 UTC (permalink / raw)
To: caml-list
I am using ocamlopt to generate object files which can be loaded by
_non_ ocaml processes. So I compile the code with -c. And then link
against libasmrun.a, std_exit.o, and stdlib.a. And the .a versions of
any .cmxa's used. This is not exactly convenient, but is not a big deal.
However, the final component, camlstartupXXXX.s, is a problem. One
creates it by running ocamlopt with the undocumented argument -dstartup,
which says "do not delete camlstartupXXXX.s after compilation". Which is
fine. I just throw away the resulting standalone executable. But where
does ocamlopt leave the camlstartup file? In the current directory like
-S does? No. The file is left in /tmp . With a semi-random name.
So after running ocamlopt, my program has to grovel through /tmp looking
for camlstartupXXXX.s files. And then find the one that resulted from
the current compilation (it adds a randomly named symbol to the source).
This is a horrible kludge.
Which wouldn't be necessary if -dstartup, rather than just preventing
the deletion of the file in /tmp, instead also placed the file someplace
convenient. Like "a.out.s". Or wherever.
Why don't I just edit asmcomp/asmlink.ml myself? Because my application
is intended to work with unmodified ocaml installations. (It's a Perl
Inline module, Inline::OCamlOpt. Which allows you to include ML code in
perl source files, with glue code generation, cached compilation, and
linking, all handled automagically. Thus one can use ML, without the
cliff-face learning curve of having to code the entire application in ML.
It's a two-evening hack, but I'm already finding it useful.)
So I suggest -dstartup's behavior be slightly modified.
Though my ML is rusty, I'll do a patch if that would help.
Thank you for your work,
Mitchell Charity
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Caml-list] Suggest ocamlopt's -dstartup place file locally, like -S does.
@ 2002-10-10 5:02 Mitchell N Charity
0 siblings, 0 replies; 4+ messages in thread
From: Mitchell N Charity @ 2002-10-10 5:02 UTC (permalink / raw)
To: caml-list
I am using ocamlopt to generate object files which can be loaded by
_non_ ocaml processes. So I compile the code with -c. And then link
against libasmrun.a, std_exit.o, and stdlib.a. And the .a versions of
any .cmxa's used. This is not exactly convenient, but is not a big deal.
However, the final component, camlstartupXXXX.s, is a problem. One
creates it by running ocamlopt with the undocumented argument -dstartup,
which says "do not delete camlstartupXXXX.s after compilation". Which is
fine. I just throw away the resulting standalone executable. But where
does ocamlopt leave the camlstartup file? In the current directory like
-S does? No. The file is left in /tmp . With a semi-random name.
So after running ocamlopt, my program has to grovel through /tmp looking
for camlstartupXXXX.s files. And then find the one that resulted from
the current compilation (it adds a randomly named symbol to the source).
This is a horrible kludge.
Which wouldn't be necessary if -dstartup, rather than just preventing
the deletion of the file in /tmp, instead also placed the file someplace
convenient. Like "a.out.s". Or whatever.
Why don't I just edit asmcomp/asmlink.ml myself? Because my application
is intended to work with unmodified ocaml installations. (It's a Perl
Inline module, Inline::OCamlOpt. Which allows you to include ML code in
perl source files, with glue code generation, cached compilation, and
linking, all handled automagically. Thus one can use ML, without the
cliff-face learning curve of having to code the entire application in ML.
It's a two-evening hack, but I'm already finding it useful.)
So I suggest -dstartup's behavior be slightly modified.
Though my ML is rusty, I'll do a patch if that would help.
Thank you for your work,
Mitchell Charity
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2002-10-10 19:40 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-10-10 16:55 [Caml-list] Suggest ocamlopt's -dstartup place file locally, like -S does Mitchell N Charity
2002-10-10 17:57 ` Chris Hecker
2002-10-10 19:42 ` Mitchell N Charity
-- strict thread matches above, loose matches on Subject: below --
2002-10-10 5:02 Mitchell N Charity
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).