Get rid of flexdll - Githubissues

skaller commented 6 years ago

It says in the notes that on Windows DLLs can't refer to symbols in the executable or previously loaded DLLs. The latter claim is not quite correct, it should say implicitly.

This is not actually a problem, it is correct behaviour and should NOT be fixed. Instead ocaml should be fixed. The issue is due to the historical development of Unix. Modern Unix linkers allow the archaic incorrect behaviour for compatibility but are moving away from it. OSX has moved well away and Linux is catching up with Windows too.

The correct way to link is to explicitly refer to a library. As mentioned, on Windows you have to link against a library to refer to its symbols because Windows actually uses a linker which has NO SUPPORT AT ALL for dynamic linkage. Windows always used a linker which could only do static linkage, so special import libraries are built which you link against instead. Calls to the symbols in the library trigger run time dynamic loading of a DLL and binding of the symbol at that time.

Linux and OSX also provide visibility control now and two level linkage, something that should have been enforced a long time ago. Unfortunately C and more recently C++ have impeded correcting the age old design fault. Still, it works right on OSX.

The question is: how can we build Ocaml correctly so we don't need flexdll? Currently I get the tiresome error "** Cannot resolve symbols for C:\ocaml\lib\libasmrun.lib(win32.obj): flexdll_wdlopen". I did have it working for Ocaml 4.02 but this is an upgrade someone built for Ocaml 4.06. "ocaml" works fine, the problem is only for ocamlopt.

dra27 commented 6 years ago

You appear to have a libasmrun.lib compiled against flexdll 0.36 or 0.37 but which you're then using on a system which has an older flexdll? We finally fixed the support on Windows for Unicode in 4.06.0 and it required a new symbol to be added to flexdll. Sorry about that.

More detail on your setup, and less detail of your wishes might help!

skaller commented 6 years ago

i wish i knew, i didn't build it. Its here:

https://github.com/felix-lang/win64ocaml

dra27 commented 6 years ago

Whoever committed it needed to clean the tree first - you've got manually installed flexdll 0.34 from your 2015 version left in bin (and presumably ocamlbuild from 4.02.3, etc) which will override the lib/flexdll objects from what, at least from the commit, looks like an msvc64 bootstrapped build.

skaller commented 6 years ago

so delete the flexdll stuff in bin?

skaller commented 6 years ago

Yep, that fixed it! Thanks! I'd still like to get rid of flexdll.

dra27 commented 4 years ago

It is possible to compile OCaml on Cygwin without FlexDLL (which disables all shared library support) and it is at present not possible to do that for the native Windows ports, which might be nice, if somewhat academic.

It's up to you if you want to transfer the issue to OCaml's issue tracker, but the issue here can be closed - FlexDLL isn't going anywhere while OCaml needs it (clearly).

I have found in previous discussions with other OCaml core devs that it's easy to have a rose-tinted view of what Windows OCaml was like pre-3.11 (i.e. when FlexDLL causes pain now, it turns out our memories have blocked out all the previous pain we used to suffer):

the inability to load C code dynamically in the OCaml toplevel on Cygwin was a fairly frequent source of confusion and unnecessary bug reports, and the feature is in general extremely useful. The truth of this demonstrated by the open problem with Cygwin64...
the native toplevel is presently receiving a lot of attention, and it's not available without FlexDLL on any of the Windows ports.
C header mangling both for C stubs (which never had the correct CAMLexport markings) and for the OCaml runtime itself, which complicatedly existed as a DLL and a library, was a maintenance nightmare. FlexDLL may facilitate (native) dynlink on Windows, but flexlink is equally as important in keeping the ports maintainable.

So I would humbly suggest that an issue on ocaml/ocaml may begin with "I would like to eliminate FlexDLL" but also needs to include at least a detailed description, if not also prototype implementation, which cleanly addresses those three points...