Opened 13 years ago

Last modified 7 years ago

#9167 closed defect

cygwin: importing sage.libs.ecl yields a "no such process" error — at Version 38

Reported by: William Stein Owned by: tbd
Priority: major Milestone: sage-5.7
Component: porting: Cygwin Keywords: cygwin spkg ecl
Cc: Mike Hansen, Dima Pasechnik, Jean-Pierre Flori, Jeroen Demeyer Merged in:
Authors: Jean-Pierre Flori Reviewers:
Report Upstream: Reported upstream. No feedback yet. Work issues:
Branch: Commit:
Dependencies: #13324 Stopgaps:

Status badges

Description (last modified by Jean-Pierre Flori)

Though the C-library interface to ecl builds on cygwin, it does not work at all. All tests fail:

sage: import sage.libs.ecl
---------------------------------------------------------------------------
ImportError                               Traceback (most recent call last)

/home/wstein/sage-4.4.3/<ipython console> in <module>()

ImportError: No such process
sage: 

The reason of this is a name clash: there are two different libraries called ecl.dll. One in SAGE_LOCAL/lib/ and one in SAGE_LOCAL/lib/python/site-packages/sage/libs/ It is the second one whose importing fails because it should be linked to the first one, but cygcheck shows that this dependency is resolved to itself! This is of course dysfunctional, whence the import failure.

The easiest solution would be to rename sage/libs/ecl.pyx to something else,thus avoiding a name clash. The solution proposed here is different and more indirect: patch ECL build system so that it follows the name convention proposed by Cygwin. The shared library itself is now in SAGE_LOCAL/bin/cygecl.dll. In addition, an import file is created in SAGE_LOCAL/lib/libecl.dll.a.

An updated spkg, based on the one in #13324, is available at http://perso.telecom-paristech.fr/~flori/sage/ecl-11.1.2.cvs20111120.p3.spkg

Change History (38)

comment:1 Changed 12 years ago by David Kirkby

I don't know if it's related, but gcc reports are couple of rather serious looking warning messages with ecl.

/export/home/drkirkby/sage-4.5.1/spkg/build/ecl-10.2.1.p1/src/src/c/dpp.c:678: warning: too few arguments for format
/export/home/drkirkby/sage-4.5.1/spkg/build/ecl-10.2.1.p1/src/src/c/dpp.c:680: warning: too many arguments for format

I'm surprised that gcc does not reject such code and refuse to compile it.

Dave

comment:2 Changed 11 years ago by Karl-Dieter Crisman

I can confirm this on the most recent versions of everything at the port wiki page.

That is bad, because now the default Maxima (and hence ECL) for calculus is the library one.

comment:3 Changed 11 years ago by Karl-Dieter Crisman

Two possibly irrelevant data points:

  • Tab-completion on from sage.libs.[tab] gives sage.libs.ecl on Mac, not on Cygwin (it also doesn't give .libecm or .ratpoints, though at least ratpoints works).
  • The directory $SAGE_LOCAL/lib/python/site-packages/sage/libs/ DOES include ecl.pyx and ecl.dll, so the library seems to be there, if that is where such imports actually come from (which I'm not sure about).

comment:4 Changed 11 years ago by Karl-Dieter Crisman

A possibly useful explanation of something similar from the Cygwin list:

Now that they are in the cygwin dll, libgfortran doesn't need
> to provide them anymore but this has the unfortunate side-effect of breaking
> old executables, since on Windows an imported function reference in an
> executable has to specify not just the function name but also the particular
> DLL from which the import comes.
>
>  I imagine that on ELF platforms where the executable just has a list of
> undefined functions and a list of shared libs to load and the dynamic linker
> just satisfies an undefined symbol from whichever lib it first comes across a
> definition of it, this probably works without anything needing changing.  But
> we're stuck I'm afraid when exports move around like this.

comment:5 Changed 11 years ago by Karl-Dieter Crisman

Cc: Mike Hansen added

This stackoverflow question also might have a useful piece of information. I don't know how to open/read dlls, though, nor exactly how to trace why it is that it's not finding things.

comment:6 Changed 11 years ago by Karl-Dieter Crisman

Cygwin's cygcheck information was much more helpful, and I find two things.

  • When looking at $SAGE_LOCAL/libs/ecl.dll,
    cygcheck: track_down:  could not find cyggc-1.dll
    
    shows up a lot. I have cyggcc_s-1.dll, cyggcj-*, cyggcr-0.dll and some others, but not this, in /bin/.
  • When looking at devel/sage/build/lib.cygwin.../sage/libs/ecl.dll, I find
    cygcheck: track_down:  could not find csage.dll
    
    This file is in devel/sage/c_lib and local/lib, but maybe that's not enough?

comment:7 in reply to:  6 Changed 11 years ago by Karl-Dieter Crisman

Replying to kcrisman:

Cygwin's cygcheck information was much more helpful, and I find two things.

  • When looking at $SAGE_LOCAL/libs/ecl.dll,
    cygcheck: track_down:  could not find cyggc-1.dll
    
    shows up a lot. I have cyggcc_s-1.dll, cyggcj-*, cyggcr-0.dll and some others, but not this, in /bin/.

Mine, at least, does NOT have cyggc-1.dll anywhere. Apparently it does have libgc (this is a garbage collector) which I've seen connected to cyggc-1.dll on the Cygwin list. But I don't see how I could have libgc without cyggc-1.dll if that were the case... I guess the only thing to try is upgrading my libgc and adding libgc-devel, though I'm a little scared!

comment:8 Changed 11 years ago by Karl-Dieter Crisman

I can't even figure out where this is created! Unless

cygwin* | mingw* | pw32*)
  version_type=windows
  need_version=no
  need_lib_prefix=no
  case $GCC,$host_os in
  yes,cygwin*)
    library_names_spec='$libname.dll.a'
    soname_spec='`echo ${libname} | sed -e 's/^lib/cyg/'``echo ${release} | sed -e 's/[.]/-/g'`${versuffix}.dll'
    postinstall_cmds='dlpath=`bash 2>&1 -c '\''. $dir/${file}i;echo \$dlname'\''`~
      dldir=$destdir/`dirname \$dlpath`~
      test -d \$dldir || mkdir -p \$dldir~
      $install_prog .libs/$dlname \$dldir/$dlname'
    postuninstall_cmds='dldll=`bash 2>&1 -c '\''. $file; echo \$dlname'\''`~
      dlpath=$dir/\$dldll~
       $rm \$dlpath'

and a few similar things in the configure and aclocal files. I can't quite parse those sed things, though I am pretty sure this wouldn't produce that - but I'm not sure what ${release} would be in this context.

comment:9 in reply to:  8 Changed 11 years ago by Leif Leonhardy

Replying to kcrisman:

...
    soname_spec='`echo ${libname} | sed -e 's/^lib/cyg/'``echo ${release} | sed -e 's/[.]/-/g'`${versuffix}.dll'
...

and a few similar things in the configure and aclocal files.

Where does this come from? ECL?

This might be the cause of the problem, since the sed command also replaces the lib prefix by cyg.

comment:10 Changed 11 years ago by Leif Leonhardy

P.S.:

The nm and objdump utilities from the GNU binutils package might be helpful to inspect libraries etc.

I vaguely remember there was also dlltool (perhaps from the MinGW project though).

comment:11 Changed 11 years ago by Karl-Dieter Crisman

Replying to leif:

Replying to kcrisman:

...
    soname_spec='`echo ${libname} | sed -e 's/^lib/cyg/'``echo ${release} | sed -e 's/[.]/-/g'`${versuffix}.dll'
...

and a few similar things in the configure and aclocal files.

Where does this come from? ECL?

No! This is from the configure file for libgc-6.4.1 or so - the Boehm GC, ported to Cygwin. I have libgc, just not cyggc.

This might be the cause of the problem, since the sed command also replaces the lib prefix by cyg.

Right, that is why I pointed to it. But it doesn't seem to replace the -6.4.1 (or -7.1.1, now) with -1, as far as I could tell. And I didn't have anything like cyggc-* on it.

I'm almost done upgrading and adding libgc-devel on my Cygwin - which meant upgrading basically every single Cygwin package, because this Cygwin hadn't been changed in a year or more. Hopefully won't break anything else, but probably will :(

As to the tools, I think that cygcheck helped a lot, so for now I'm going to stick with that because I actually sort of understand it :)

comment:12 in reply to:  11 ; Changed 11 years ago by Karl-Dieter Crisman

Right, that is why I pointed to it. But it doesn't seem to replace the -6.4.1 (or -7.1.1, now) with -1, as far as I could tell. And I didn't have anything like cyggc-* on it.

I'm almost done upgrading and adding libgc-devel on my Cygwin - which meant upgrading basically every single Cygwin package, because this Cygwin hadn't been changed in a year or more. Hopefully won't break anything else, but probably will :(

I think that libgc-devel was what it took to get this file. However, the upgrade upgraded too much - see this Cygwin list thread - so I had to downgrade libgfortran as described there, and gcc, and .... Not for the last time, I have to say that Cygwin definitely is a moving target.

comment:13 in reply to:  12 Changed 11 years ago by Karl-Dieter Crisman

Replying to kcrisman:

Right, that is why I pointed to it. But it doesn't seem to replace the -6.4.1 (or -7.1.1, now) with -1, as far as I could tell. And I didn't have anything like cyggc-* on it.

I'm almost done upgrading and adding libgc-devel on my Cygwin - which meant upgrading basically every single Cygwin package, because this Cygwin hadn't been changed in a year or more. Hopefully won't break anything else, but probably will :(

I think that libgc-devel was what it took to get this file. However, the upgrade upgraded too much - see this Cygwin list thread - so I had to downgrade libgfortran as described there, and gcc, and ...

...and I managed to toast my Cygwin lapack. As far as I can tell I downgraded everything necessary to the right version, rebuilt lapack, rebooted, but still no go.

$ python
>>> import numpy
ImportError <snip>

Nuts. Note that fixing this for the Cygwin Python should fix it for Sage, I think, since we use the same Fortran stuff and even lapack (?), certainly BLAS/ATLAS.

comment:14 Changed 11 years ago by Karl-Dieter Crisman

After a lot of trouble managing to get Cygwin shell to find lapack again, I definitely have the right files now. We definitely need as at least part of the fix to add libgc-devel as a dependency.

However, there is also still a problem that cygcheck finds all the needed dlls for the ecl.dll in local/lib and local/bin, but not for the ones in devel/sage/build/sage/libs/. It cannot find ecl.dll or csage.dll. Which seems weird, since those files certainly exist.

This might be a PATH problem, judging by some similar issues elsewhere. Unfortunately, ./sage -gdb is no help here, nor is ./sage -ipython.

comment:15 in reply to:  14 ; Changed 11 years ago by Karl-Dieter Crisman

However, there is also still a problem that cygcheck finds all the needed dlls for the ecl.dll in local/lib and local/bin, but not for the ones in devel/sage/build/sage/libs/. It cannot find ecl.dll or csage.dll. Which seems weird, since those files certainly exist.

Yeah, after a ./sage -br it still looks like csage.dll is not being found for some reason. Must be a path issue, I think. Where do we set the Sage path? It certainly doesn't include local/lib, but I don't know if that's really the problem.

comment:16 in reply to:  15 ; Changed 11 years ago by Leif Leonhardy

Replying to kcrisman:

However, there is also still a problem that cygcheck finds all the needed dlls for the ecl.dll in local/lib and local/bin, but not for the ones in devel/sage/build/sage/libs/. It cannot find ecl.dll or csage.dll. Which seems weird, since those files certainly exist.

Yeah, after a ./sage -br it still looks like csage.dll is not being found for some reason. Must be a path issue, I think. Where do we set the Sage path?

In local/bin/sage-env. You could special-case Cygwin there and add all directories that contain DLLs, as Windows treats them as executables.

It certainly doesn't include local/lib, but I don't know if that's really the problem.

Well, before editing sage-env, you could just try modifying your PATH from the shell accordingly.

comment:17 in reply to:  16 ; Changed 11 years ago by Karl-Dieter Crisman

Yeah, after a ./sage -br it still looks like csage.dll is not being found for some reason. Must be a path issue, I think. Where do we set the Sage path?

In local/bin/sage-env. You could special-case Cygwin there and add all directories that contain DLLs, as Windows treats them as executables.

It certainly doesn't include local/lib, but I don't know if that's really the problem.

Well, I have good news and bad news.

Well, before editing sage-env, you could just try modifying your PATH from the shell accordingly.

  • Good news: editing PATH from the shell to include local/lib made cygcheck pass for these files.
  • News: sage-env includes
    if [ "$UNAME" = "CYGWIN" ]; then
        PATH="$PATH:$SAGE_LOCAL/lib" && export PATH
    fi
    
  • Bad news: even with this added to PATH and this being in the sage-env, I still have this problem. I'm still pretty sure it's a path issue, but maybe they are in the wrong order or something? I have no idea how complex this could get...

comment:18 in reply to:  17 ; Changed 11 years ago by Karl-Dieter Crisman

  • News: sage-env includes
if [ "$UNAME" = "CYGWIN" ]; then
    PATH="$PATH:$SAGE_LOCAL/lib" && export PATH
fi
  • Bad news: even with this added to PATH and this being in the sage-env, I still have this problem. I'm still pretty sure

For some reason this is not actually in Sage's path, gotten by sys.path in the Sage session. And adding it to sys.path didn't help, either. What the heck is going on?

comment:19 Changed 11 years ago by Karl-Dieter Crisman

Another possibility, suggested by this thread, is that there could be two of some file making things hard. Interestingly, there are several ecl.dll's floating around (everywhere a libecl.{dylib,so} would live, I guess) and cygcheck gives different dependencies for each.

comment:20 in reply to:  18 ; Changed 11 years ago by Leif Leonhardy

Replying to kcrisman:

  • News: sage-env includes
if [ "$UNAME" = "CYGWIN" ]; then
    PATH="$PATH:$SAGE_LOCAL/lib" && export PATH
fi

Yep, but this should IMHO be moved up in the file (including the definition of UNAME), in any case above

if [ "$1" = "-short" ]; then
    return 0
fi

and $SAGE_LOCAL/lib should be prepended to pick up Sage's versions first.

For some reason this is not actually in Sage's path, gotten by sys.path in the Sage session. And adding it to sys.path didn't help, either. What the heck is going on?

No idea. What does os.environ.get("PATH") give?

I also don't know if we have to add some more or different things to PYTHONPATH on Cygwin.

Note that e.g. $SAGE_LOCAL/lib/python (which is added to PYTHONPATH [if it is a directory] in sage-env) is a symbolic link on Linux etc. (pointing to $SAGE_LOCAL/lib/python2.6); I don't know if it is the real directory on Cygwin instead.

comment:21 in reply to:  20 Changed 11 years ago by Karl-Dieter Crisman

and $SAGE_LOCAL/lib should be prepended to pick up Sage's versions first.

That sounds like a good idea. But should it be before $SAGE_ROOT and $SAGE_LOCAL/bin?

For some reason this is not actually in Sage's path, gotten by sys.path in the Sage session. And adding it to sys.path didn't help, either. What the heck is going on?

No idea. What does os.environ.get("PATH") give?

This gives what I would expect - Sage root, Sage local bin, usr/bin, some Cygwin stuff, a Lapack thing I had to add due to my carelessness, and then Sage local lib.

I also don't know if we have to add some more or different things to PYTHONPATH on Cygwin.

This is very sparse. It is just the directory below.

Note that e.g. $SAGE_LOCAL/lib/python (which is added to PYTHONPATH [if it is a directory] in sage-env) is a symbolic link on Linux etc. (pointing to $SAGE_LOCAL/lib/python2.6); I don't know if it is the real directory on Cygwin instead.

It looks like it's the same on Cygwin.

Another interesting thing is that there are libntl.dll files in /local/bin and /local/lib. Moving just one doesn't seem to do much - note that the bin one is the one imported usually, as in your comment above. Furthermore, apparently only the ecl.dll in devel/sage/build/sage/libs needs libntl.dll and cyggmp, while the one in local/{bin,lib} just wants cyggmp-3.dll.

Anyway, I guess I can move files around all day but I'm not getting any nearer.

comment:22 Changed 11 years ago by Karl-Dieter Crisman

Cc: Dima Pasechnik added

Question for Dima or others; is it possible that we have too many copies of the dlls? Either that the ecl.dll files are in too many places - local/lib and local/bin - or that the extra libntl.dll files also are causing problems? See #11635 for where this started - perhaps this is the cause of all the trouble?

comment:23 in reply to:  22 ; Changed 11 years ago by Dima Pasechnik

Replying to kcrisman:

Question for Dima or others; is it possible that we have too many copies of the dlls? Either that the ecl.dll files are in too many places - local/lib and local/bin - or that the extra libntl.dll files also are causing problems? See #11635 for where this started - perhaps this is the cause of all the trouble?

for the record, 2 different copies of ecl.dll in SAGE_ROOT/local/ are created; one in local/lib (and/or local/bin), created from ecl spkg, the other in local/lib/python2.6/site-packages/sage/libs/, which contains Sage/Python? interface to ecl (I don't know details about how and when it is built).

comment:24 in reply to:  23 Changed 11 years ago by Karl-Dieter Crisman

for the record, 2 different copies of ecl.dll in SAGE_ROOT/local/ are created; one in local/lib (and/or local/bin), created from ecl spkg, the other in local/lib/python2.6/site-packages/sage/libs/, which contains Sage/Python? interface to ecl (I don't know details about how and when it is built).

Right, and the third one is the one which which yields "No such process".

Although just by chance I tried (in ./sage -ipython)

from sage.matrix import matrix_integer_dense_hnf
NameError: ZZ

from the import from sage.libs.ntl.ntl_ZZ even though

from sage.libs.ntl import *
ntl_ZZ

works fine. Still going to take a while to track all this down, sigh...

What do you think about the possibility that it's just a path problem suggested above? I just don't know enough about how all this works to be sure.

comment:25 Changed 11 years ago by Karl-Dieter Crisman

Here's something interesting.

User 1@GC02635 /home/SageUser/sage-4.7.2
$ cygcheck local/bin/ecl.dll
C:\cygwin\home\SageUser\sage-4.7.2\local\bin\ecl.dll
  C:\cygwin\bin\cyggc-1.dll
    C:\cygwin\bin\cygwin1.dll
      C:\WINDOWS\system32\ADVAPI32.DLL
        C:\WINDOWS\system32\KERNEL32.dll
          C:\WINDOWS\system32\ntdll.dll
        C:\WINDOWS\system32\RPCRT4.dll
          C:\WINDOWS\system32\Secur32.dll
    C:\cygwin\bin\cyggcc_s-1.dll
  C:\cygwin\bin\cyggmp-3.dll
  C:\cygwin\bin\cygffi-4.dll

User 1@GC02635 /home/SageUser/sage-4.7.2
$ cygcheck local/bin/ecl.exe
C:\cygwin\home\SageUser\sage-4.7.2\local\bin\ecl.exe
  C:\cygwin\bin\cygwin1.dll
    C:\WINDOWS\system32\ADVAPI32.DLL
      C:\WINDOWS\system32\KERNEL32.dll
        C:\WINDOWS\system32\ntdll.dll
      C:\WINDOWS\system32\RPCRT4.dll
        C:\WINDOWS\system32\Secur32.dll
cygcheck: track_down: could not find ecl.dll

Or maybe it's boring. At any rate, I find this weird.

And here is the cygcheck for the offending dll.

User 1@GC02635 /home/SageUser/sage-4.7.2/local/lib/python2.6/site-packages/sage/libs
$ cygcheck ./ecl.dll
C:\cygwin\home\SageUser\sage-4.7.2\devel\sage-main\build\sage\libs\ecl.dll
  C:\cygwin\bin\cygwin1.dll
    C:\WINDOWS\system32\ADVAPI32.DLL
      C:\WINDOWS\system32\KERNEL32.dll
        C:\WINDOWS\system32\ntdll.dll
      C:\WINDOWS\system32\RPCRT4.dll
        C:\WINDOWS\system32\Secur32.dll
  C:\cygwin\home\SageUser\sage-4.7.2\devel\sage-main\build\sage\libs\ecl.dll
cygcheck: track_down: could not find libpython2.6.dll

cygcheck: track_down: could not find libpython2.6.dll

cygcheck: track_down: could not find csage.dll

cygcheck: track_down: could not find csage.dll

That's a lot of things not to find.

comment:26 Changed 11 years ago by Karl-Dieter Crisman

Scratch that - in private comm. Dima points out that we should be in the subshell.

SAGE_ROOT=/home/SageUser/sage-4.7.2
(sage subshell) GC02635:sage-4.7.2 User 1$ cd local/lib/python2.6/site-packages/sage/libs/
SAGE_ROOT=/home/SageUser/sage-4.7.2
(sage subshell) GC02635:libs User 1$ cygcheck ./ecl.dll
C:\cygwin\home\SageUser\sage-4.7.2\devel\sage-main\build\sage\libs\ecl.dll
  C:\cygwin\home\SageUser\sage-4.7.2\local\bin\libpython2.6.dll
    C:\cygwin\bin\cygwin1.dll
      C:\WINDOWS\system32\ADVAPI32.DLL
        C:\WINDOWS\system32\KERNEL32.dll
          C:\WINDOWS\system32\ntdll.dll
        C:\WINDOWS\system32\RPCRT4.dll
          C:\WINDOWS\system32\Secur32.dll
  C:\cygwin\home\SageUser\sage-4.7.2\devel\sage-main\build\sage\libs\ecl.dll
    C:\cygwin\home\SageUser\sage-4.7.2\local\lib\csage.dll
      C:\cygwin\home\SageUser\sage-4.7.2\local\bin\cyggmp-3.dll
      C:\cygwin\bin\cyggcc_s-1.dll
      C:\cygwin\bin\cygstdc++-6.dll
      C:\cygwin\home\SageUser\sage-4.7.2\local\lib\libntl.dll
SAGE_ROOT=/home/SageUser/sage-4.7.2

But doing it outside its own directory yields the same "could not find" message as before. It only finds it if I'm already in site-packages/sage/.

comment:27 in reply to:  26 Changed 11 years ago by Dima Pasechnik

Replying to kcrisman:

Scratch that - in private comm. Dima points out that we should be in the subshell.

still, we need to know details of Sage/Python? extension implementation on Cygwin to solve this. It could be just an artefact of broken Python/Cython? (fork() failures when running sage -b are a pain...)

comment:28 Changed 10 years ago by Jean-Pierre Flori

Cc: Jean-Pierre Flori added

comment:29 Changed 10 years ago by Jean-Pierre Flori

Just for info, on my Cygwin 1.7.16/Sage 5.2 install cygchecking all the ecl.* things shows no problem. So the problem looks more subtle...

comment:30 Changed 10 years ago by Jean-Pierre Flori

I found it quite strange that the problematic ecl.dll links to itself. Maybe it's wanting the other ecl.dll, but gets itself because of the name clash.

I'll try to rename ecl.pyx to ecl_blah.pyx, regenerate it and import it to see what happens.

comment:31 Changed 10 years ago by Jean-Pierre Flori

No problem importing ecl_blah (after removing the former ecl.dll in the same directory sage/libs/)!

comment:32 Changed 10 years ago by Jean-Pierre Flori

And the question is now, why do we get ecl.dll in local/lib/ rather than libecl.dll.

comment:33 in reply to:  32 ; Changed 10 years ago by Dima Pasechnik

Replying to jpflori:

And the question is now, why do we get ecl.dll in local/lib/ rather than libecl.dll.

the following Cygwin doc seems to imply that lib prefix is merely a matter of convenience; it recommends that there should be no libecl.dll; it should rather be cygecl.dll and libecl.dll.a.

comment:34 Changed 10 years ago by Jean-Pierre Flori

Ok, that's because in ecl build system, the shared library is named ${SHAREDPREFIX}ecl.${SHAREDEXT} and these two variables are set to and 'dll' by configure on Cygwin.

comment:35 in reply to:  33 Changed 10 years ago by Jean-Pierre Flori

Replying to dimpase:

Replying to jpflori:

And the question is now, why do we get ecl.dll in local/lib/ rather than libecl.dll.

the following Cygwin doc seems to imply that lib prefix is merely a matter of convenience; it recommends that there should be no libecl.dll; it should rather be cygecl.dll and libecl.dll.a.

I agree with you. The question is now if it's trivial enough to modify the build of the shared library on Cygwin. Unfortunately, ecl does not use libtool.

comment:36 Changed 10 years ago by Jean-Pierre Flori

I think the changes could be quite easy, I'll give it a try.

comment:37 Changed 10 years ago by Jean-Pierre Flori

I based my patch on the two following naming schemes: http://www.mingw.org/wiki/sampleDLL for MinGW and: http://cygwin.com/cygwin-ug-net/dll.html#dll-build for CYGWIN I'll report that upstream.

As I had to run autoconf which modified a lot of data in config*, the patch included and the hg history will be quite big, so it would be better to update to an upstream release including such modifications (if upstream thinks its a good idea of course). Unfortunately, we are quite behind, and I'm not really ready to do both an update and having this fix at the same time. Another solution would be to included a patched src directory in the spkg, but I can already hear people ranting. Or directly patch configure in a minimal way, but I'm not so inclined to doing so.

comment:38 Changed 10 years ago by Jean-Pierre Flori

Authors: Jean-Pierre Flori
Dependencies: #13324
Description: modified (diff)
Keywords: cygwin spkg ecl added
Report Upstream: N/ANot yet reported upstream; Will do shortly.
Status: newneeds_review
Note: See TracTickets for help on using tickets.