RE: [Caml-list] flexdll circular dependency on ocamlc: Impossible to built ocaml for mingw without using some prebuilt binaries?

[David Allsopp <dra-news@metastack.com>]

Alain Frisch wrote:
> On 24/10/2015 11:50, Soegtrop, Michael wrote:
> > Also I wonder why flexdll/flexlink is required. The documentation of
> > flexdll states:
> >
> > Windows DLL cannot refer to symbols defined in the main application or
> > in previously loaded DLLs.
> >
> > In my experience this is not true. At least when using MSVC one can
> > declare functions in the main executable as DLL-export. Then when
> > linking the main executable an import library is created in the same
> > way as when building a DLL by the linker. The DLL can then link to
> > this import library and can access the functions  in the main
> executable.
> 
> Dynlink follows a different model: dynlinked units are not tied to a
> specific main executable.  A myplugin.cmxs can be dynamically linked by
> any application that provides the required interfaces.

Wouldn't that still be true with the .def/.a approach, though?

> As for the dependency between OCaml and flexdll: the simplest approach is
> to consider flexdll as any other external tool required to build OCaml (do
> you recompile "gcc", "make", etc  from sources?). It just happens to be
> implemented in OCaml.  Alternatively, you could create a bytecode version
> of flexlink, which would only require ocamlrun.

It's not about *do* you, it's *can* you! Ignoring the fact that these days I think gcc has to be built with gcc, historically all those tools (gcc, make, etc.) could be built using *someone else's* C compiler and make implementation and then bootstrapped to create a "pure" one. There is no other implementation of flexlink (or ocaml) to achieve that, which is what makes classing flexlink (rather than the core of FlexDLL) as "external" taste weird, even if only in a philosophical manner.


David