> 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
