[Ecls-list] Build system on Cygwin
Juan Jose Garcia-Ripoll
juanjose.garciaripoll at gmail.com
Fri Aug 17 11:09:55 UTC 2012
On Fri, Aug 17, 2012 at 12:46 PM, Jean-Pierre Flori <jpflori at gmail.com>wrote:
> 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
> IIRC [...]
> 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.
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ecl-devel