#13912: Let iconv build on Cygwin without installing Cygwin libiconv package
-------------------------------------+--------------------------------------
Reporter: jpflori | Owner: tbd
Type: defect | Status: closed
Priority: minor | Milestone: sage-5.7
Component: packages | Resolution: fixed
Keywords: cygwin iconv spkg | Work issues:
Report Upstream: N/A | Reviewers: Jeroen Demeyer
Authors: Jean-Pierre Flori | Merged in: sage-5.7.beta0
Dependencies: | Stopgaps:
-------------------------------------+--------------------------------------
Comment (by jpflori):
Replying to [comment:17 dimpase]:
> Replying to [comment:15 kcrisman]:
> > In other words, we should go for maximal Cygwin packages (more like
Sage-on-Gentoo) and not minimal (like the usual Sage Linux Distro)?
>
> this would be the most obvious solution to this, although not the only
one possible; and actually it's not quite a solution, as Sage still has to
include some dlls which can potentially conflict with ones from Cygwin,
e.g. Singular and ECL are available as Cygwin packages, and there could
(potentially) be naming clashes.
>
I don't think name clash is the main issue.
> Another way is to take more care with PATH contents, although this would
require a better understanding of the issue, and in particular how
rebaseall affects this (and whether rebaseall can handle this). There is a
certain database of Cygwin dlls maintained by rebase/rebaseall (as I
gather from e.g. [http://cygwin.com/ml/cygwin-apps/2012-06/msg00062.html
here]), and we need to understand what is stored there etc. Our situation
reminds me of the one discussed [http://cygwin.com/ml/cygwin-
apps/2012-06/msg00062.html here], but I don't understand the details. Note
that there are lots of dlls that are produced on the fly when building
{{{Python/Cython}}} extensions, and these can potentially create dll name
conflicts.
Our PATH looks pretty sane now, we look first in the Sage directories
where the libraries we linked to are installed.
I think the problem of forking, address clash issues, arises with or
without name clashes.
The last one I got where caused by libraries with so creepy names (random
numbers and strange case) that I doubt we were colliding with the Cygwin
namespace.
It was rather that the addressing sapce was full and the hackish rebasing
process failed.
I also encountered such situations when I was tweaking max heap memory
with peflags to let PARI's doctests pass.
If I allocated too much memory to the python process, then loading Sage
failed with forking errors, and putting it back down to the default value
let Sage start again (and the doctests fail :)) without any other
intervention.
>
> We can also considering a special dll naming scheme. E.g. we can give
all the dlls produced by Sage a certain prefix, e.g. "sagecyg", just as
Cygwin's dlls all get prefix "cyg" (much more work, but it looks like a
really watertight way to deal with this).
>
> The biggest problem now seems that we don't (at least I don't) have a
good understanding how Windows loader, Cygwin rebase package (and that
mysterios to me database), and Cygwin itself work together with dlls and
where exactly the name clashes problem can hit.
Yep, that would make things easier hopefully.
>
> A related unanswered question is whether the 32-bit emulation on 64-bit
Windows systems in the only environment in which Sage can be made to
reliably work with the present Cygwin. (Leaving ancient Windows versions
like XP alone).
I don't really get what you're thinking about.
You mean running a 32 bits Windows?
If you have a virtual machine in mind then a virtual Linux is the way to
go.
> My understanding is that in this case the address space available for
Cygwin dlls is much bigger than on "proper" 32-bit systems, and this is
very important for Sage, which has a huge requirement for such a space, if
a static non-overlapping memory layout for dlls is required for proper
functioning.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/13912#comment:20>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
