another problem building maxima on cygwin

[Dima Pasechnik]

Having another go at building Sage on Cygwin, I get, somewhere very near the end of building Maxima spkg, the following:

.......

building Maxima as an ecl library

;;; Loading #P"/home/Dima/sage-4.7.2/local/lib/ecl/asdf.fas"

;;; Loading #P"/home/Dima/sage-4.7.2/local/lib/ecl/cmp.fas"

;;; Loading "/home/Dima/sage-4.7.2/spkg/build/maxima-5.23.2.p0/src/src/maxima-build.lisp"

;;; Loading "/home/Dima/sage-4.7.2/spkg/build/maxima-5.23.2.p0/src/src/../lisp-utils/defsystem.lisp"

;;; Loading "/home/Dima/sage-4.7.2/spkg/build/maxima-5.23.2.p0/src/src/maxima-package.lisp"

;;; OPTIMIZE levels: Safety=2, Space=0, Speed=3, Debug=0

;;;

;;; End of Pass 1.

;;; Note:

;;;   Invoking external command:

;;;   gcc -I. -I/home/dima/sage-4.7.2/local/include/ -I/home/dima/sage-4.7.2/local/include -g -O2 -Dcygwin -O2 -w -c /tmp/ecl001K7CyZk.c -o /tmp/ecl001K7CyZk.o

;;; Note:

;;;   Invoking external command:

;;;   gcc -o /tmp/ecl001K7CyZk.fas -L/home/dima/sage-4.7.2/local/lib/ /tmp/ecl001K7CyZk.o -shared -L/home/dima/sage-4.7.2/local/lib -L/home/dima/sage-4.7.2/local/lib -lecl -lgmp -lgc -lm

; Loading system definition from

; /home/Dima/sage-4.7.2/spkg/build/maxima-5.23.2.p0/src/src/maxima.asd into

; #<ASDF0 package>

;;; Loading "/home/Dima/sage-4.7.2/spkg/build/maxima-5.23.2.p0/src/src/maxima.asd"

; Registering #<system :MAXIMA> as MAXIMA

An error occurred during initialization:

In function PATHNAME, the value of the only argument is

  NIL

which is not of the expected type (OR FILE-STREAM STRING PATHNAME).

installing Maxima library as /home/Dima/sage-4.7.2/local/lib/ecl//maxima.fas

cp: cannot stat `maxima.fasb': No such file or directory

***********************************************************

Failed to install maxima.fasb as a library

----------------------------

the command responsible for this seems to be

(asdf:make-build :maxima :type :fasl :move-here ".")

invoked from spkg-install.

and it certainly works anywhere else. 

The parameter 'move-here' does not seem to be documented anywhere...

Is it due to usual Cygwin/windows misnaming (I see in src/binary-ecl/ file maxima.exe) ?

[Dima Pasechnik]

by running ecl stand-alone on the maxima spkg, I can confirm that the error comes from 

(asdf:make-build :maxima :type :fasl :move-here ".")

Unfortunately I cannot find any information on how to use the ecl's debugger.

Any pointers much appreciated.

By the way,

In maxima.asd I see plenty of :pathname "", and the error is

;;; Loading "/home/Dima/sage-4.7.2/spkg/build/maxima-5.23.2.p0/src/src/maxima.asd"

; Registering #<system :MAXIMA> as MAXIMA

An error occurred during initialization:

In function PATHNAME, the value of the only argument is

  NIL

which is not of the expected type (OR FILE-STREAM STRING PATHNAME).

So somehow it might be that due to some LF/CR weirdness, "" cannot be an argument to pathname

(*** my pure speculation***)

Dima

[Dima Pasechnik]

I just checked, and saw that under Sage's ECL lisp (i.e. sage -lisp),

(pathname "")

produces an error (illegal seek) on Cygwin,

while on MacOSX and Linux it's perfectly OK.

[Nils Bruin]

I'd say that's a bug for ECL/Cygwin (which of the two is at fault I do
not know), since the documentation clearly indicates that
(pathname "")
should be valid. See http://ecls.sourceforge.net/ecl/user_2.html#SEC28

However, the error you are quoting above:

In function PATHNAME, the value of the only argument is NIL which is
not of the expected type (OR FILE-STREAM STRING PATHNAME).

indicates something else. (pathname NIL) and (pathname "") are not the
same thing, so what you're seeing might be caused by yet something
else.

I did brew the (asdf:make-build :maxima :type :fasl :move-here ".")
incantation at some point. Maxima needs to be set up with "autoconf"
before this works [there may be other ways too]. Did you try to run it
without the ':move here "." ' part? We can work around the move-here
in some other way if that is the problem.

Did you check that up to (asdf:make-build :maxima :type :fasl :move-
here ".") everything works fine? [i.e., you should have a functional
maxima executable] If there is an error before, then there is very
little chance that asdf:make-build could ever succeed (since it'll try
the same thing and fail again).

That's all I can think of. We could ask Juanjo if he has some insight.
It probably is a cygwin deficiency, but he is at least very familiar
with the ecl internals and might know a workaround.

[Dima Pasechnik]

I guess the root of the problem is here:

here is another weirdness, which might explain the PATHNAME error message

On Cygwin, ECL gives

> (directory "")

NIL

>

while on supported systems (MacOSX, Linux) you get the current directory:

> (directory "")

(#P"/private/tmp/")

> 

And on Cygwin directory function is broken in different ways, too - returning wrong contents, e.g.

(directory "/tmp/*") should return the list(?) of files in /tmp, but on Cygwin it doesn't.

Any clues how to fix this?

----------

I get maxima.exe along the way, it starts and seems to work OK (e.g. "factor(10!);" works)

Dima

[Nils Bruin]

[Nils Bruin]

My apologies for the last message. That didn't tell you anything you
didn't already know. A little digging in the source got me to:

http://ecls.git.sourceforge.net/git/gitweb.cgi?p=ecls/ecl;a=blob;f=src/c/pathname.d;h=d35bcc58eeeb1f3766b8fc25140253852d94e216;hb=HEAD#l736

which tries to define the variable *default-pathname-defaults* . On
linux, it seems to be equal to a path to the current directory, which
is the value one gets from (directory "") . [On one sage install on
linux, I'm just getting #P"" from (pathname ""), which seems to work
there. At least it's not NIL]

Perhaps this variable is unset on cygwin? (meaning its initialization
goes wrong somewhere).
You can see its value by just typing *default-pathname-defaults* at
the ECL prompt.

If its value is inappropriate you might try setting it:

(setf *default-pathname-defaults* #P"/tmp/")

or something like that.

[note that the source for cl_pathname is at line 753 of the same file]

[Dima Pasechnik]

On Tuesday, November 29, 2011 1:49:59 AM UTC+8, Nils Bruin wrote:

My apologies for the last message. That didn't tell you anything you
didn't already know. A little digging in the source got me to:

http://ecls.git.sourceforge.net/git/gitweb.cgi?p=ecls/ecl;a=blob;f=src/c/pathname.d;h=d35bcc58eeeb1f3766b8fc25140253852d94e216;hb=HEAD#l736

which tries to define the variable *default-pathname-defaults* . On
linux, it seems to be equal to a path to the current directory, which
is the value one gets from (directory "") . [On one sage install on
linux, I'm just getting #P"" from (pathname ""), which seems to work
there. At least it's not NIL]

Perhaps this variable is unset on cygwin? (meaning its initialization
goes wrong somewhere).
You can see its value by just typing *default-pathname-defaults* at
the ECL prompt.

no, it's OK on Cygwin, it's set to the directory I start ECL in.

(Same as on MacOSX, say).

I also tried to set the argument of :move-to to an absolute path, but

this did not help. 

[Nils Bruin]

On Nov 28, 11:12 am, Dima Pasechnik <dimp...@gmail.com> wrote:
> I also tried to set the argument of :move-to to an absolute path, but
> this did not help.

And just removing the ":move-here ..."? The normal behaviour of ASDF
should just place the result somewhere in a local tree. The variable
asdf::*user-cache* specifies where, if I'm not mistaken (we also set
that before building maxima, to avoid filling ~/.cache/common-lisp/...
with building debris).

So basically, you should try to do (in ECL):

(require `asdf)
(load "maxima-build.lisp")
(asdf:make-build :maxima :type :fasl)

If that works, then we can basically build maxima.fas . We just have
to figure out where it is put and/or build/move it to a more
convenient spot.

If it does not work then the problem is to figure out how to build
maxima.fas in the first place. [meaning that either Maxima+ECL+ASDF
+cygwin is broken or that it needs some other incantation and/or
workaround] Producing maxima.fas instead of a stand-alone executable
is essentially a different linking step (by then the required .o files
have been produced). ASDF was the most straightforward way I saw to
achieve that goal, but there may be other ways.

If there is remote access to some cygwin installation somewhere I
would be willing to try some things out to see if I can help.

[Juanjo]

Hi Dima,

I am sorry, but I do not read this group frequently -- too much work to do --. Following your request I just built ECL from CVS/git on a cygwin box and definitely I do not see the problems you seem to experience.

On Monday, November 28, 2011 10:29:28 AM UTC+1, Dima Pasechnik wrote:

I guess the root of the problem is here:

here is another weirdness, which might explain the PATHNAME error message

On Cygwin, ECL gives

> (directory "")

NIL

Nope

 

And on Cygwin directory function is broken in different ways, too - returning wrong contents, e.g.

(directory "/tmp/*") should return the list(?) of files in /tmp, but on Cygwin it doesn't.

Again no.

See below for a trivial transcript from my system:

ECL (Embeddable Common-Lisp) 11.1.1 (git:78442fa7bcb4ef486b704e16d0e7cefbd4bf7680)

Copyright (C) 1984 Taiichi Yuasa and Masami Hagiya

Copyright (C) 1993 Giuseppe Attardi

Copyright (C) 2000 Juan J. Garcia-Ripoll

ECL is free software, and you are welcome to redistribute it

under certain conditions; see file 'Copyright' for details.

Type :h for Help.  

Top level.

> 

(#P"/home/Juanjo/")

> 

(#P"/tmp/fooZn9LId" #P"/tmp/fooMuvYb1" #P"/tmp/fooFsAFJw")

> 

Any followup to this, should it need my input, should be done on the ECL mailing list.

Cheers

Juanjo

[Dima Pasechnik]

Hi Juanjo,

On Tuesday, November 29, 2011 5:57:04 AM UTC+8, Juanjo wrote:

Hi Dima,

I am sorry, but I do not read this group frequently -- too much work to do --. Following your request I just built ECL from CVS/git on a cygwin box and definitely I do not see the problems you seem to experience.

could you please specify data of your cygwin system?

(mine is 1.7.9-1)

In particular, the version of cygwin dll, and the output of the command mount

(to see whether this might be due to differences in textfile mode (for me, everything is mounted

as binary).

I'll build ECL from the CVS source and report.

Thanks!

Dima

[Dima Pasechnik]

I guess I figured this out. This problem was in weird behavior of capitalization of filenames and directory names, and/or in the fact that

I was building in a subdirectory of the home directory of a WIndows domain user...

Moving the build tree to a saner place fixed this weirdness.

And then I was back to where I got stuck last Spring, namely, that the temporary DDLs created by ECL were breaking Cygwin's fork command.

So I tried to pass options to the external linker, by setting

(setf c:*user-ld-flags* "-Wl,--enable-auto-image-base")

before calling asdf.

It didn't help, but

(setf c:*user-ld-flags* "-Wl,--image-base=0x79000000")

did! This means, create temporary DLLs starting at the address 0x79000000; all the other Cygwin and Sage DDLs are rebased from 0x77000000, and

that's probably what makes the thing work OK. Of course it's a terrible hack, but in the absence of a better one it would do, hopefully. 

OK, I'll make an updated maxima spkg, with this Cygwin-specific addition...

Dima

 

[kcrisman]

That is weird that you have to do this. Juanjo suggested that he had
made a bunch of changes to totally change how forking works in ECL
this summer, but maybe they weren't merged? I'm cc:ing him on this.

- kcrisman

[Juan Jose Garcia-Ripoll]

On Wed, Nov 30, 2011 at 9:32 PM, kcrisman <kcri...@gmail.com> wrote:

That is weird that you have to do this.  Juanjo suggested that he had
made a bunch of changes to totally change how forking works in ECL
this summer, but maybe they weren't merged?  I'm cc:ing him on this.

I did not change the way fork is used: fork is broken in cyginw, period. However, I managed to avoid using fork() altogether, at least when compiling programs. This does not solve the problem; it just hides it.

Juanjo

--
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com

[kcrisman]

On Nov 30, 4:40 pm, Juan Jose Garcia-Ripoll
<juanjose.garciarip...@googlemail.com> wrote:

> On Wed, Nov 30, 2011 at 9:32 PM, kcrisman <kcris...@gmail.com> wrote:
> > That is weird that you have to do this.  Juanjo suggested that he had
> > made a bunch of changes to totally change how forking works in ECL
> > this summer, but maybe they weren't merged?  I'm cc:ing him on this.
>
> I did not change the way fork is used: fork is broken in cyginw, period.
> However, I managed to avoid using fork() altogether, at least when
> compiling programs. This does not solve the problem; it just hides it.
>

Sorry, I misunderstood - as you know, I'm not an expert on ECL or
Cygwin, just a grunt trying to help out. I guess the point is whether
there is a way to avoid this problem when we compile Maxima. Or is
Dima's solution the best one for this?

- kcrisman

[Dima Pasechnik]

On Thursday, 1 December 2011 05:40:35 UTC+8, Juanjo wrote:

On Wed, Nov 30, 2011 at 9:32 PM, kcrisman <kcri...@gmail.com> wrote:

That is weird that you have to do this.  Juanjo suggested that he had
made a bunch of changes to totally change how forking works in ECL
this summer, but maybe they weren't merged?  I'm cc:ing him on this.

I did not change the way fork is used: fork is broken in cyginw, period. However, I managed to avoid using fork() altogether, at least when compiling programs. This does not solve the problem; it just hides it.

I don't see how you managed to completely avoid it (I hope we talk about the same ECL version, do we?! We use http://sage.math.washington.edu/home/kcrisman/ecl-11.1.1.p3.spkg).  

Without the hack I found, one still often gets things like this one:

-----------------------------------------

...

;;; Compiling /usr/local/sage/sage-4.7.2/spkg/build/maxima-5.23.2.p0/src/src/command-line.lisp.

;;; OPTIMIZE levels: Safety=2, Space=0, Speed=3, Debug=2

;;;

;;; Compiling (DEFSTRUCT CL-OPTION ...).

[...]

;;; End of Pass 1.

;;; Note:

;;;   Refusing to propagate #<form C2PRINC 129fdf8>

;;; Note:

;;;   Refusing to propagate #<form C2PRINC 129fcd8>

;;; Emitting code for MAKE-CL-OPTION.

[...]

;;; Emitting code for REMOVE-IMPLEMENTATION-ARGS.

      3 [main] ecl 2880 C:\cygwin\usr\local\sage\sage-4.7.2\local\bin\ecl.exe: *** fatal error - unable to remap \\?\C:\cygwin\tmp\eclcWIpUD.dll to same address as parent: 0x530000 != 0x810000

Stack trace:

Frame     Function  Args

0022A118  6102796B  (0022A118, 00000000, 00000000, 00000000)

0022A408  6102796B  (6117EC60, 00008000, 00000000, 61180977)

0022B438  61004F1B  (611A7FAC, 6124E2FC, 00530000, 00810000)

End of stack trace

      3 [main] ecl 2964 fork: child 2880 - died waiting for dll loading, errno 11

;;; Note:

;;;   Invoking external command:

;;;   gcc -I. -I/usr/local/sage/sage-4.7.2/local/include/ -I/usr/local/sage/sage-4.7.2/local/include -g -O2 -Dcygwin -O2 -w -c binary-ecl/command-line.c -o binary-ecl/command-line.o

Could not spawn subprocess to run "gcc".

Available restarts:

...

------------------------------------------------

The reason my hack helps fork() to work is due to these temporary DLLs (I still don't know where they come from, by the way) being placed in memory in a more favourable way, which does not give Windows a reason to move them around (and moving them around is exactly the reason for that "*** fatal error - unable to remap \\?\C:\cygwin\tmp\eclcWIpUD.dll" things)

Dima

[kcrisman]

On Nov 30, 9:38 pm, Dima Pasechnik <dimp...@gmail.com> wrote:
> On Thursday, 1 December 2011 05:40:35 UTC+8, Juanjo wrote:
>
> > On Wed, Nov 30, 2011 at 9:32 PM, kcrisman <kcri...@gmail.com> wrote:
>
> >> That is weird that you have to do this.  Juanjo suggested that he had
> >> made a bunch of changes to totally change how forking works in ECL
> >> this summer, but maybe they weren't merged?  I'm cc:ing him on this.
>
> > I did not change the way fork is used: fork is broken in cyginw, period.
> > However, I managed to avoid using fork() altogether, at least when
> > compiling programs. This does not solve the problem; it just hides it.
>
> I don't see how you managed to completely avoid it (I hope we talk about
> the same ECL version, do we?! We usehttp://sage.math.washington.edu/home/kcrisman/ecl-11.1.1.p3.spkg).

No, I don't think so! See http://trac.sagemath.org/sage_trac/ticket/11884
and the spkg there, which contains CVS/git/whatever from mid-
November. This is merged in 4.8.alpha3.

- kcrisman

[Dima Pasechnik]

On Thursday, 1 December 2011 10:57:21 UTC+8, kcrisman wrote:

On Nov 30, 9:38 pm, Dima Pasechnik <dim...@gmail.com> wrote:
> On Thursday, 1 December 2011 05:40:35 UTC+8, Juanjo wrote:
>

> > On Wed, Nov 30, 2011 at 9:32 PM, kcrisman <kcr...@gmail.com> wrote:
>
> >> That is weird that you have to do this.  Juanjo suggested that he had
> >> made a bunch of changes to totally change how forking works in ECL
> >> this summer, but maybe they weren't merged?  I'm cc:ing him on this.
>
> > I did not change the way fork is used: fork is broken in cyginw, period.
> > However, I managed to avoid using fork() altogether, at least when
> > compiling programs. This does not solve the problem; it just hides it.
>
> I don't see how you managed to completely avoid it (I hope we talk about
> the same ECL version, do we?! We usehttp://sage.math.washington.edu/home/kcrisman/ecl-11.1.1.p3.spkg).

No, I don't think so!  See http://trac.sagemath.org/sage_trac/ticket/11884
and the spkg there, which contains CVS/git/whatever from mid-
November.  This is merged in 4.8.alpha3.

You didn't mention that thing here: 

http://trac.sagemath.org/sage_trac/ticket/6743 

or here:

http://trac.sagemath.org/sage_trac/wiki/CygwinPort

How could anyone have known...

Oh well.

Dima

- kcrisman

[Juan Jose Garcia-Ripoll]

On Thu, Dec 1, 2011 at 3:38 AM, Dima Pasechnik <dim...@gmail.com> wrote:

I don't see how you managed to completely avoid it (I hope we talk about the same ECL version, do we?! We use http://sage.math.washington.edu/home/kcrisman/ecl-11.1.1.p3.spkg).

I do not know what stage of change this includes. What I meant is that ECL does not, by itself, call execve(), fork(), or relatives at all when using Cygwin, and instead relies on "system". What cygwin does under the hood (for instance if it is so unfortunate to use fork() when executing system()) is a mistery to me.

 

Without the hack I found, one still often gets things like this one: [...]

      3 [main] ecl 2880 C:\cygwin\usr\local\sage\sage-4.7.2\local\bin\ecl.exe: *** fatal error - unable to remap \\?\C:\cygwin\tmp\eclcWIpUD.dll to same address as parent: 0x530000 != 0x810000

Stack trace:

Frame     Function  Args

0022A118  6102796B  (0022A118, 00000000, 00000000, 00000000)

0022A408  6102796B  (6117EC60, 00008000, 00000000, 61180977)

0022B438  61004F1B  (611A7FAC, 6124E2FC, 00530000, 00810000)

End of stack trace

Seems again fork has been used.

 

The reason my hack helps fork() to work is due to these temporary DLLs (I still don't know where they come from, by the way) being placed in memory in a more favourable way, which does not give Windows a reason to move them around (and moving them around is exactly the reason for that "*** fatal error - unable to remap \\?\C:\cygwin\tmp\eclcWIpUD.dll" things)

I find that hack questionable. Will it work everywhere with any library loaded? Does it block other user's software from running? Hardcoding memory addresses is what has been pestering all Common Lisp implementations in the history and prevented not only portability but also maintainability.

Regarding the "due to these temporary DLLs (I still don't know where they come from, by the way)", the explanation is simple. Maxima is asking ECL to compile fragments of code via the C compiler, probably using the Common Lisp function COMPILE. A way to circumvent this problem (which makes sense for it also eliminates the use of the C compiler when Sage is used) is to replace this function with the bytecodes compiler, which is cheaper and does not invoke gcc.

> (progn

    (ext:package-lock "CL" nil)

    (setf (fdefinition 'compile) #'ext::bc-compile)

    (ext:package-lock "CL" t))

#<"COMMON-LISP" package>

> #'compile

#<compiled-function EXT::BC-COMPILE>

> (compile 'foo '(lambda (x) (print x)))

FOO

NIL

NIL

> (foo 2)

2 

2

> #'foo

#<bytecompiled-closure #<bytecompiled-function 00000001039b9000>>

The first four lines may be inserted in Maxima's code, probably at the end of ECL's portability section.

#+cygwin

(progn

    (ext:package-lock "CL" nil)

    (setf (fdefinition 'compile) #'ext::bc-compile)

    (ext:package-lock "CL" t))

[Dima Pasechnik]

On Thursday, December 1, 2011 4:27:56 PM UTC+8, Juanjo wrote:

On Thu, Dec 1, 2011 at 3:38 AM, Dima Pasechnik <dim...@gmail.com> wrote:

I don't see how you managed to completely avoid it (I hope we talk about the same ECL version, do we?! We use http://sage.math.washington.edu/home/kcrisman/ecl-11.1.1.p3.spkg).

I do not know what stage of change this includes.

OK, our fault - the information on which ECL version should be used did not get to the appropriate Cygwin-related sage Trac pages (such as ticket #6743) on time, 

and I was experimenting (and fighting) with an ld ECL.

Now it's fixed, and I am happy to report that I was able to build this new ECL and use it to build Maxima on Cygwin without any problems.

(I'm using ECL CVS release 20111120 now).

 

What I meant is that ECL does not, by itself, call execve(), fork(), or relatives at all when using Cygwin, and instead relies on "system". What cygwin does under the hood (for instance if it is so unfortunate to use fork() when executing system()) is a mistery to me.

 

Without the hack I found, one still often gets things like this one: [...]

      3 [main] ecl 2880 C:\cygwin\usr\local\sage\sage-4.7.2\local\bin\ecl.exe: *** fatal error - unable to remap \\?\C:\cygwin\tmp\eclcWIpUD.dll to same address as parent: 0x530000 != 0x810000

Stack trace:

Frame     Function  Args

0022A118  6102796B  (0022A118, 00000000, 00000000, 00000000)

0022A408  6102796B  (6117EC60, 00008000, 00000000, 61180977)

0022B438  61004F1B  (611A7FAC, 6124E2FC, 00530000, 00810000)

End of stack trace

Seems again fork has been used.

 

The reason my hack helps fork() to work is due to these temporary DLLs (I still don't know where they come from, by the way) being placed in memory in a more favourable way, which does not give Windows a reason to move them around (and moving them around is exactly the reason for that "*** fatal error - unable to remap \\?\C:\cygwin\tmp\eclcWIpUD.dll" things)

I find that hack questionable. Will it work everywhere with any library loaded? Does it block other user's software from running? Hardcoding memory addresses is what has been pestering all Common Lisp implementations in the history and prevented not only portability but also maintainability.

well, it is hardcoring addresses of temporary DLLs, that are gone after the compilation is done. This should not be too harmful. Anyway, with the new ECL this also does not seem to be needed!

 

Regarding the "due to these temporary DLLs (I still don't know where they come from, by the way)", the explanation is simple. Maxima is asking ECL to compile fragments of code via the C compiler, probably using the Common Lisp function COMPILE. A way to circumvent this problem (which makes sense for it also eliminates the use of the C compiler when Sage is used) is to replace this function with the bytecodes compiler, which is cheaper and does not invoke gcc.

> (progn

    (ext:package-lock "CL" nil)

    (setf (fdefinition 'compile) #'ext::bc-compile)

    (ext:package-lock "CL" t))

#<"COMMON-LISP" package>

> #'compile

#<compiled-function EXT::BC-COMPILE>

> (compile 'foo '(lambda (x) (print x)))

FOO

NIL

NIL

> (foo 2)

2 

2

> #'foo

#<bytecompiled-closure #<bytecompiled-function 00000001039b9000>>

The first four lines may be inserted in Maxima's code, probably at the end of ECL's portability section.

#+cygwin

(progn

    (ext:package-lock "CL" nil)

    (setf (fdefinition 'compile) #'ext::bc-compile)

    (ext:package-lock "CL" t))

Thank you, this is very good to know, just in case we start to hit a similar snag again.

Dima

[Dima Pasechnik]

somehow belatedly, I created a ticket to document this weirdness:

http://trac.sagemath.org/sage_trac/ticket/13343