0002378: Bytecode only compilation fails when linking to stdlib

(0006752)
madroach (reporter)
2019-02-24 23:58
edited on: 2019-02-24 23:59

I suspect the build error is caused by +vmthreads/stdlib.cma having a different ordering and set of modules than +stdlib.cma. Since vmthreads are being deprecated anyway I would consider always building with system threads. Alternatively, do at least prefer system threads even on bytecode builds as is done by the patch I just uploaded.

(0006856)
madroach (reporter)
2019-08-27 22:06

Please commit at least the configure patch. There is a misunderstanding of what "native system threads" implies in the OCaml world. Native system threads are available for native and for bytecode compilation and are the only available threading since vmthreads, which were only supported for bytecode, have been dropped.

(0006857)
maroneze (administrator)
2019-08-28 18:04

I hadn't seen this issue before, so in March I applied a similar patch to the Makefile, which should have the same effect as yours, I think (and it should already be available in the latest Frama-C release, 19.0). But the configure patch has not been applied. We don't currently have an OpenBSD VM to test it, but I tried applying the patch using my fork of Frama-C's Github repository (https://github.com/maroneze/Frama-C-snapshot). If it looks good to you, we'll probably commit it soon.

(0006858)
madroach (reporter)
2019-08-29 00:38

Looks good to me. You might consider applying patch-configure_in_2 instead because it is simpler while yielding the same results. There is no difference in threading between byte- and nativecode anymore.

(0006860)
madroach (reporter)
2019-08-29 00:47

Now also updated to patch-Makefile_2 adding a fix to allow bytecode only installation.

(0006862)
maroneze (administrator)
2019-08-29 09:14

Thanks a lot. I adapted a bit the patch Makefile_2 to make it work, and we will try to integrate it quickly. Concerning the threads detection, though, maybe it's better to completely remove the test from the configure, assuming native threads are always available. Is there a deadline concerning OpenBSD package releases? In other words, would it be useful if the patches were integrated ASAP, or could it wait for the next Frama-C release (likely sometime in November/December)?

(0006863)
madroach (reporter)
2019-08-29 09:54
edited on: 2019-08-29 09:55

I have no idea which platforms would run Frama-C without threads and therefore no idea whether they need thread-detection. No need to hurry the release; we are patching Frama-C in our ports. But it would be nice if we could stop maintaining the patches with the next Frama-C update.

(0006864)
virgile (developer)
2019-08-29 10:38

The fact that vmthreads are deprecated in 4.08 (https://github.com/ocaml/ocaml/pull/2038), with the suggestion to move to system threads regardless of the OS on which the application is run is in my opinion a good hint that assuming native thread support everywhere is not too far fetched.

(0006865)
madroach (reporter)
2019-08-29 12:52

According to https://ocaml.org/learn/portability.html threads are supported everywhere.

(0006867)
madroach (reporter)
2019-08-30 00:50

I'm afraid I forgot to test native code builds, which are broken by my Makefile patch. That's why I just uploaded a fixed 3rd version of the Makefile patch.

(0006869)
virgile (developer)
2019-09-12 17:44

Changes have been merged internally and will be part of Frama-C 20.0 Calcium

Issue History
Date Modified	Username	Field	Change
2018-06-18 16:48	madroach	New Issue
2018-06-18 16:48	madroach	Status	new => assigned
2018-06-18 16:48	madroach	Assigned To	=> virgile
2018-11-30 10:41	signoles	Assigned To	virgile => bobot
2019-02-24 23:56	madroach	File Added: patch-configure_in
2019-02-24 23:58	madroach	Note Added: 0006752
2019-02-24 23:59	madroach	Note Edited: 0006752	View Revisions
2019-02-25 02:01	madroach	File Added: patch-Makefile
2019-08-27 22:06	madroach	Note Added: 0006856
2019-08-28 17:37	maroneze	Assigned To	bobot => maroneze
2019-08-28 18:04	maroneze	Note Added: 0006857
2019-08-29 00:36	madroach	File Added: patch-configure_in_2
2019-08-29 00:38	madroach	Note Added: 0006858
2019-08-29 00:46	madroach	File Added: patch-Makefile_2
2019-08-29 00:47	madroach	Note Added: 0006860
2019-08-29 09:14	maroneze	Note Added: 0006862
2019-08-29 09:54	madroach	Note Added: 0006863
2019-08-29 09:55	madroach	Note Edited: 0006863	View Revisions
2019-08-29 10:38	virgile	Note Added: 0006864
2019-08-29 12:52	madroach	Note Added: 0006865
2019-08-30 00:49	madroach	File Added: patch-Makefile_3
2019-08-30 00:50	madroach	Note Added: 0006867
2019-09-12 17:44	virgile	Note Added: 0006869
2019-09-12 17:44	virgile	Status	assigned => resolved
2019-09-12 17:44	virgile	Fixed in Version	=> Frama-C 20-Calcium
2019-09-12 17:44	virgile	Resolution	open => fixed

Notes
(0006752) madroach (reporter) 2019-02-24 23:58 edited on: 2019-02-24 23:59	I suspect the build error is caused by +vmthreads/stdlib.cma having a different ordering and set of modules than +stdlib.cma. Since vmthreads are being deprecated anyway I would consider always building with system threads. Alternatively, do at least prefer system threads even on bytecode builds as is done by the patch I just uploaded.

(0006856) madroach (reporter) 2019-08-27 22:06	Please commit at least the configure patch. There is a misunderstanding of what "native system threads" implies in the OCaml world. Native system threads are available for native and for bytecode compilation and are the only available threading since vmthreads, which were only supported for bytecode, have been dropped.

(0006857) maroneze (administrator) 2019-08-28 18:04	I hadn't seen this issue before, so in March I applied a similar patch to the Makefile, which should have the same effect as yours, I think (and it should already be available in the latest Frama-C release, 19.0). But the configure patch has not been applied. We don't currently have an OpenBSD VM to test it, but I tried applying the patch using my fork of Frama-C's Github repository (https://github.com/maroneze/Frama-C-snapshot). If it looks good to you, we'll probably commit it soon.

(0006858) madroach (reporter) 2019-08-29 00:38	Looks good to me. You might consider applying patch-configure_in_2 instead because it is simpler while yielding the same results. There is no difference in threading between byte- and nativecode anymore.

(0006860) madroach (reporter) 2019-08-29 00:47	Now also updated to patch-Makefile_2 adding a fix to allow bytecode only installation.

(0006862) maroneze (administrator) 2019-08-29 09:14	Thanks a lot. I adapted a bit the patch Makefile_2 to make it work, and we will try to integrate it quickly. Concerning the threads detection, though, maybe it's better to completely remove the test from the configure, assuming native threads are always available. Is there a deadline concerning OpenBSD package releases? In other words, would it be useful if the patches were integrated ASAP, or could it wait for the next Frama-C release (likely sometime in November/December)?

(0006863) madroach (reporter) 2019-08-29 09:54 edited on: 2019-08-29 09:55	I have no idea which platforms would run Frama-C without threads and therefore no idea whether they need thread-detection. No need to hurry the release; we are patching Frama-C in our ports. But it would be nice if we could stop maintaining the patches with the next Frama-C update.

(0006864) virgile (developer) 2019-08-29 10:38	The fact that vmthreads are deprecated in 4.08 (https://github.com/ocaml/ocaml/pull/2038), with the suggestion to move to system threads regardless of the OS on which the application is run is in my opinion a good hint that assuming native thread support everywhere is not too far fetched.

(0006865) madroach (reporter) 2019-08-29 12:52	According to https://ocaml.org/learn/portability.html threads are supported everywhere.

(0006867) madroach (reporter) 2019-08-30 00:50	I'm afraid I forgot to test native code builds, which are broken by my Makefile patch. That's why I just uploaded a fixed 3rd version of the Makefile patch.

(0006869) virgile (developer) 2019-09-12 17:44	Changes have been merged internally and will be part of Frama-C 20.0 Calcium

Relationships