#9914: Remove libraries from extension modules when they are not needed there at
build time
------------------------------+---------------------------------------------
Reporter: leif | Owner: leif
Type: defect | Status: needs_work
Priority: major | Milestone: sage-4.6
Component: build | Keywords: module_list.py PARI ImportError
newforms homspace mwrank upgrade update
Author: Leif Leonhardy | Upstream: N/A
Reviewer: | Merged:
Work_issues: |
------------------------------+---------------------------------------------
Comment(by GeorgSWeber):
Replying to [comment:5 leif]:
>
> Even if e.g. {{{libg0nntl.so}}} directly depended on PARI, none of the
extension modules whose {{{libraries}}} I've changed does.
>
Even if the -lpari dependency in the build/compile call of the libg0nntl
is technically superfluous, and/or none of the extension modules used
libpari functionality in the end --- this parameter -lpari is *there* (in
the Makefile line mentioned). This might be a bug in this eclib Makefile.
Which probably doesn't matter on most systems, but might very well matter
on Cygwin (and the presence of lpari in the module_list.py entries just a
q'n'd workaround). Put in other words: the module_list.py patch might be
incomplete without also updating (correcting?) this Makefile.
>
> So I'll update the patch to use {{{uname_specific()}}} (if that makes
you happy ;-) - I'd really like to give it a try ''as is'' on Cygwin),
which then should be tested (also) on MacOS X 10.4 (Tiger).
So both of us are kind of stuck here --- neither of us seems to have
access to some Cygwin system, to do "real life" testing. Personally, I do
have access to Mac OS X 10.4 systems (both MacIntel and MacPPC), but does
that suffice to work on the ticket? I mean, wouldn't updating Sage-4.5.3
to Sage-4.6 still break on Cygwin (even if we fixed all other OS's)?
In general, such update problems are not new. The Sage build/update
mechanisms have shortcomings that are well known. In the past, one had to
(and did) give hints to them. I can't put my finger to a specific release
or sage-devel thread right now, but the idea is as simple as powerful,
I'll explain it at the example at hand.
Solution:
Just artificially bump up the version number of the eclib spkg.
(No real changes are done to its contents --- and often in the past, even
the update of the SPKG.txt was forgotten, but that's another matter, one
should do that always).
As a result, during an update, the eclib spkg *will* be built anew, and as
a consequence, also during "sage -b" the mentioned extensions are rebuilt.
Et voila.
Leif, I couldn't follow each and every of the recent threads on sage-devel
and sage-release, let alone trac. Has this "old way" been discussed, or
even considered (for Sage-4.6)? If not, should a message thread on sage-
release be opened?
I think there's a very good chance to get the update from Sage-4.5.3 to
Sage-4.6 working, just by artificially bumping up the version numbers of a
handful spkg's (in the sense I described above).
Cheers,
Georg
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/9914#comment:6>
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 post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
