RE: [ITA] ocaml 4.14.0
Hi David,
> What were the missing symbols? With the OCaml 4.10 package, I hit problems
> with this:
>
> echo 'print_endline "hello, world"' > hello.ml
>
> ocamlc -custom -runtime-variant _shared -o hello.exe hello.ml
>
> I think that may be an issue upstream (libasmrun_shared.so IIRC is broken on
> all platforms - on Cygwin, you can just about to persuade it to get to the
> same symbol errors because of the extra .dll.a file which gets generated).
It's a very long list of missing symbols (~400) so it's included as an
attachment in case the mailing list truncates extremely lengthy emails. Also,
just to note, the .dll.a file doesn't seem to be automatically generated by
upstream OCaml.
> What's the full configuration command and what gets inferred for the build,
> host and target triplets? fma should work without emulation in Cygwin32 and
> it should be detecting as failing on Cygwin64 but the emulation should be
> enabled by default unless you explicitly passed
> --disable-imprecise-c99-float-ops.
Configuration command:
./configure --prefix=/usr --enable-ocamltest
If it's relevant, I'm compiling on a 64-bit machine with Cygwin32 installed to
compile the 32-bit version. Inferred build/host/target:
configure:2779: Configuring OCaml version 4.14.0
configure:3007: checking build system type
configure:3021: result: i686-pc-cygwin
configure:3041: checking host system type
configure:3054: result: i686-pc-cygwin
configure:3074: checking target system type
configure:3087: result: i686-pc-cygwin
On Cygwin64, the test does fail and emulate by default:
configure:14872: result: no
configure:14896: WARNING: fma does not work; emulation enabled
However, on Cygwin32, I get
configure:14872: result: no
configure:14894: error: fma does not work, enable emulation with
--enable-imprecise-c99-float-ops
config.log conveniently includes the program that fails, so I copy-pasted some
very redundant code (attached) and ran it on the different architectures:
Cygwin64:
t264| ans: 0x0p+0 accept: 0x1.0989687cp-1044 0x1.09df287cp-1044 0x1.0ap-1044
t264| pass?: 0
t265| ans: 0x0p+0 accept: 0x1.0988p-1060 0x1.09ep-1060 0x1.0ap-1060
t265| pass?: 0
t266| ans: 0x1p-1074 accept: 0x1p-1073
t266| pass?: 0
Cygwin32:
t264| ans: 0x1.0ap-1044 accept: 0x1.0989687cp-1044 0x1.09df287cp-1044
0x1.0ap-1044
t264| pass?: 1
t265| ans: 0x1.0ap-1060 accept: 0x1.0988p-1060 0x1.09ep-1060 0x1.0ap-1060
t265| pass?: 1
t266| ans: 0x1p-1073 accept: 0x1p-1073
t266| pass?: 1
The numbers look like they agree but configure doesn't think so for some reason.
> The camlheader files are data files and definitely mustn't be installed with
> a .exe extension (nor do they need to be executable).
>
> Incidentally, OCaml 4.12+ is also likely to run into problems if flexlink is
> older than 0.39 - I just removed the test mark from the flexdll 0.39 package
> (which I thought I'd done quite some time ago...)
>
> HTH,
>
>
> David
Yep, these pointers help a ton! Thank you!
William#include
#include
int main (void) {
static volatile double x, y, z;
double t264, t265, t266;
x = 0x3.bd5b7dde5fddap-496;
y = 0x3.bd5b7dde5fddap-496;
z = -0xd.fc352bc352bap-992;
t264 = fma(x, y, z);
x = 0x3.bd5b7dde5fddap-504;
y = 0x3.bd5b7dde5fddap-504;
z = -0xd.fc352bc352bap-1008;
t265 = fma(x, y, z);
x = 0x8p-540;
y = 0x4p-540;
z = 0x4p-1076;
t266 = fma(x, y, z);
printf("t264| ans: %a accept: %a %a %a\nt264| pass?: %d\n",
t264,
0x1.0989687cp-1044,
0x0.04277ca1fp-1022,
0x0.0428p-1022,
t264 == 0x1.0989687cp-1044 ||
t264 == 0x0.04277ca1fp-1022 ||
t264 == 0x0.0428p-1022
);
printf("t265| ans: %a accept: %a %a %a\nt265| pass?: %d\n",
t265,
0x1.0988p-1060,
0x0.04278p-1022,
0x0.0428p-1022,
t265 == 0x1.0988p-1060 ||
t265 == 0x0.04278p-1022 ||
t265 == 0x0.0428p-1022
);
printf("t266| ans: %a accept: %a\nt266| pass?: %d\n",
t266,
0x8p-1076,
t266 == 0x8p-1076
);
return 0;
}
$ /usr/bin/ocamlc -verbose -custom -runtime-variant _shared -o hello.exe
hello.ml
+ flexlink -chain cygwin64 -merge-manifest -stack 16777216 -exe -o 'hello.exe'
'-L/usr/lib/ocaml' '-link'
'-fdebug-prefix-map=/tmp/camlprim56f84c.c=camlprim.c' '/tmp/camlprim56f84c.c'
'-lcamlrun_shared' -I'/usr/lib/ocaml' -lm -lpthread
** Cannot resolve symbols for /tmp/dyndll87882d.o:
caml_abs_float
caml_acos_float
caml_acosh_float
caml_add_float
caml_alloc_dummy
RE: [ITA] ocaml 4.14.0
> 1) libcamlrun: Oops, that's another oversight, forgot to look at the old
> patches. The other 3 patches seem unnecessary, but I had trouble linking
> either libcamlrun_shared.so or libcamlrun_shared.dll.a into a program
> (unresolved symbol errors). Added but it possibly needs further patching.
> I'll keep on digging.
What were the missing symbols? With the OCaml 4.10 package, I hit problems with
this:
echo 'print_endline "hello, world"' > hello.ml
ocamlc -custom -runtime-variant _shared -o hello.exe hello.ml
I think that may be an issue upstream (libasmrun_shared.so IIRC is broken on
all platforms - on Cygwin, you can just about to persuade it to get to the same
symbol errors because of the extra .dll.a file which gets generated).
> 1.5) I checked for other differences between the cygports to make sure I
> didn't miss anything else. I made some edits to src_install: I removed
> `dodoc Updating` since there doesn't seem to be a file named "Updating".
> I also removed symlinking header files to /usr/include. From what I
> understood, the OCaml documentation says the headers should "reside in
> the caml/ subdirectory of the OCaml standard library directory, which is
> returned by the command ocamlc -where (usually /usr/local/lib/ocaml or
> /usr/lib/ocaml)". Obviously the symlink doesn't move anything, but since
> their location is well documented I didn't see a reason to have the extra
> symlinks. Please let me know if this is too large of a change or there's
> a Cygwin (or non-Cygwin) convention that precludes this - I'm still
> getting the hang of this.
> 2) fma on x86: I'm actually getting the same error, but the tests should
> ostensibly pass on Cygwin32. I'll also look into this.
What's the full configuration command and what gets inferred for the build,
host and target triplets? fma should work without emulation in Cygwin32 and it
should be detecting as failing on Cygwin64 but the emulation should be enabled
by default unless you explicitly passed --disable-imprecise-c99-float-ops.
> 3) Interesting - on my machine, the camlheader[di] files had the .exe
> extensions. I did some digging around and found the files are *built*
> without the .exe suffix, and even *initially installed* without the .exe
> suffix, but ultimately come out with the .exe suffix. I ran cyport in
> debug mode and apparently the files are being renamed with the suffix
> post-install:
>
> + case "${exe##*/}" in
> + mv usr/lib/ocaml/camlheaderd usr/lib/ocaml/camlheaderd.exe
> + exe+=.exe
>
> and did a little more digging and I think these lines in cygport are the
> cause:
> https://github.com/cygwin/cygport/blob/096f27644bd3b28f29d7522e816bebd327c
> f24cb/lib/src_postinst.cygpart#L1010
>
> On the topic of "testing more thoroughly", I attempted to use ocamlc to
> compile a simple program and it fails with "Cannot find file camlheader"
> but works when I remove the ".exe", so it seems that the presence of the
> .exe suffixes breaks the compiler. Is there a way to prevent cygport from
> adding it?
The camlheader files are data files and definitely mustn't be installed with a
.exe extension (nor do they need to be executable).
Incidentally, OCaml 4.12+ is also likely to run into problems if flexlink is
older than 0.39 - I just removed the test mark from the flexdll 0.39 package
(which I thought I'd done quite some time ago...)
HTH,
David
Re: [PATCH setup 0/2] Simplify setting group ownership of installed files
Jon Turney wrote:
Jon Turney (2):
Drop group change while running postinstall scripts
Defer setting group until after All Users/Just For Me is chosen
main.cc| 2 +-
postinstall.cc | 13 -
root.cc| 5 +
win32.cc | 13 ++---
win32.h| 2 +-
5 files changed, 9 insertions(+), 26 deletions(-)
Works for me as expected. Primary group of dirs/files of "All Users"
installed files are now local administrator (like before Feb 2012),
including those generated by postinstall scripts (new behavior).
As already mentioned in the '--no-write-registry' thread, "Just me"
installs only work with non-elevated user and '-B' option. Attached is a
temporary patch I used to log changes of root_scope variable.
diff --git a/state.cc b/state.cc
index 111b890..b4e3410 100644
--- a/state.cc
+++ b/state.cc
@@ -24,7 +24,7 @@ int source;
std::string local_dir;
-int root_scope;
+root_scope_holder root_scope;
int root_menu;
int root_desktop;
diff --git a/state.h b/state.h
index b211de3..c561ea5 100644
--- a/state.h
+++ b/state.h
@@ -32,6 +32,7 @@
*/
#include
+#include "LogSingleton.h"
enum attend_mode { attended = 0, unattended, chooseronly };
extern enum attend_mode unattended_mode;
@@ -42,7 +43,22 @@ extern int source;
extern std::string local_dir;
extern int root_text;
-extern int root_scope;
+
+class root_scope_holder
+{
+public:
+ void operator=(int v) {
+int old = val;
+val = v;
+Log(LOG_TIMESTAMP) << "root_scope: " << old << " -> " << v << endLog;
+ }
+ operator int() const { return val; }
+private:
+ int val = 0;
+};
+
+extern root_scope_holder root_scope;
+
extern int root_menu;
extern int root_desktop;
