|Anonymous | Login | Signup for a new account||2019-02-24 01:40 CET|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0006735||OCaml||runtime system and C interface||public||2014-12-28 06:18||2017-11-26 16:02|
|Target Version||4.07.0+dev/beta2/rc1/rc2||Fixed in Version||4.07.0+dev/beta2/rc1/rc2|
|Summary||0006735: ocamlc -custom should not link to curses|
|Description||Why does it link to curses, actually? That doesn't make sense, and I couldn't find any place this would be explained.|
|Tags||No tags attached.|
AFAIK it links to curses because the standard runtime interfaces with some curses stuff, because the toplevel depends on it.
I agree it would be nice to get rid of this dependency.
|Yes. So if toplevel could Dynlink the curses library, this dependency would be removed. This is another good argument for having Dynlink in stdlib.|
Dynamic loading would be nice but I think another way would be to move $curseslibs from $BYTECCLIBS and only add it when linking the Terminfo module (which is clearly separated in utils/ btw).
Note that this would solve https://caml.inria.fr/mantis/view.php?id=7164 [^] "missing -ltinfo when linking bytecode with -custom".
Also note that doing so would need an update to the manual as a consequence of https://caml.inria.fr/mantis/view.php?id=4920 [^]
|@Camarade_Tux That would require making the toplevel, (I think) bytecode compiler, etc, use a custom runtime. I assume there's a reason for them not to, but I don't know for sure.|
|Hmmm, true, that requires some more care than I had thought at first. I'll try to take a look at it, I'm still quite confident it can be done and this dependency is quite annoying.|
I took a stab at it on yesterday and stopped after it became likely that it would involve bootstrapping the compiler.
The idea was to make a separate Terminfo.cma that would pull a .so for the stubs. There would be no more mention of curses in ocamlrun itself.
I was able to build the compiler but not the standard library. One issue I met involved the -use-prims flag which is undocumented and I didn't feel like spending a lot of time understanding it.
It is indeed fairly annoying. I also noticed that it could creep into files in boot/ so it probably makes sense to build with -no-curses before bootstrapping the compiler.
|Pull request coming soon.|
|See pull request at https://github.com/ocaml/ocaml/pull/1431 [^]|
|PR merged, will be in 4.07|
|2014-12-28 06:18||whitequark||New Issue|
|2015-01-06 22:00||doligez||Note Added: 0013021|
|2015-01-06 22:00||doligez||Status||new => acknowledged|
|2015-01-13 23:43||doligez||Target Version||=> 4.02.3+dev|
|2015-01-13 23:47||whitequark||Note Added: 0013090|
|2015-01-13 23:47||whitequark||Relationship added||related to 0006696|
|2015-07-10 17:38||doligez||Target Version||4.02.3+dev => 4.03.0+dev / +beta1|
|2015-12-03 13:35||frisch||Target Version||4.03.0+dev / +beta1 => later|
|2016-11-11 23:38||Camarade_Tux||Note Added: 0016554|
|2016-11-11 23:43||whitequark||Note Added: 0016555|
|2016-11-11 23:50||Camarade_Tux||Note Added: 0016556|
|2016-11-13 15:14||Camarade_Tux||Note Added: 0016571|
|2017-02-23 16:36||doligez||Category||OCaml general => -OCaml general|
|2017-02-24 13:28||doligez||Relationship added||related to 0007164|
|2017-02-24 13:29||doligez||Category||-OCaml general => runtime system|
|2017-02-24 13:29||doligez||Target Version||later =>|
|2017-03-03 17:45||doligez||Category||runtime system => runtime system and C interface|
|2017-10-15 16:50||xleroy||Note Added: 0018573|
|2017-10-15 16:50||xleroy||Assigned To||=> xleroy|
|2017-10-15 16:50||xleroy||Status||acknowledged => assigned|
|2017-10-15 16:50||xleroy||Target Version||=> 4.07.0+dev/beta2/rc1/rc2|
|2017-10-16 16:44||xleroy||Note Added: 0018582|
|2017-11-26 16:02||xleroy||Note Added: 0018687|
|2017-11-26 16:02||xleroy||Status||assigned => resolved|
|2017-11-26 16:02||xleroy||Resolution||open => fixed|
|2017-11-26 16:02||xleroy||Fixed in Version||=> 4.07.0+dev/beta2/rc1/rc2|
|Copyright © 2000 - 2011 MantisBT Group|