#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 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.
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.
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.
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).
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:17>
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.
