On Fri, Aug 17, 2012 at 12:46 PM, Jean-Pierre Flori <firstname.lastname@example.org>
On Cygwin at least, when the linker is given the -lecl flag, it will
look for files in PATH in a certain order.
First libecl.dll.a, then ..., then cygecl.dll, then ... then ecl.dll
So if we only have cygecl.dll every thing should be fine, provided
xxx/bin is in PATH (or wherever it was installed).
That is not a problem: it is already a requirement.
>From what I understand, the linking process will be somehow slower,
There's nothing that prevents ECL from using import libraries, but the fact that Lisp users expect only one file to be generated by COMPILE-FILE, not two. However, in the case of full DLLs (as with ecl.dll) we could afford to use an import library.
As there seems to be a free version floating around, I think I'll give
it a try... What pieces of the ECL suite do actually link to ecl.dll?
The executable itself plus all compiled files (*.fas). When a Lisp user compiles a library, such as those distributed with quicklisp, or Maxima, or the modules that ECL builds (ecl-curl, asdf, etc), they have to be linked with the library.
Oh, and a final remark, on Cygwin at least, the dllimport magic is broken.
The dllexport stuff gets defined in the headers at build time because
"cygwin" is defined by the build system.
But when included from another project (let's say Sage :), the
dllimport is included only if "cygwin" is defined... which has no
reason to be.
The easiest fix I found was to define "cygwin" when "__CYGWIN__" is
(and that gcc does define on Cygwin).
We would have to fix the ECL headers.