Opened 16 months ago

Last modified 3 months ago

#14636 needs_review defect

ECL spkg : dirty workarounds?

Reported by: Snark Owned by: jdemeyer
Priority: major Milestone: sage-pending
Component: packages: standard Keywords:
Cc: jpflori Merged in:
Authors: Volker Braun Reviewers:
Report Upstream: N/A Work issues: add doctest
Branch: Commit:
Dependencies: Stopgaps:

Description (last modified by Snark)

My debian/sage experiments have uncovered that sage's ecl package was compiled with a few tweaks:

(1) it is compiled with unicode disabled ; this is to avoid errors, like those which can be read about in this gentoo report. But that doesn't look like a real solution!

(2) SIGCHLD is disabled by directly patching the sources (patches/disable_sigchdl_handler.patch)

(3) threading is disabled ; I'll open another ticket for that, so let's that aside for now (and for this ticket)

To fix this ticket: (1) use this ecl spkg (spkg diff) ; (2) apply trac_14636_1.patch and trac_14636_2.patch to sagelib (in that order).

This fix is against sage 5.12.beta4.

Attachments (6)

ecl-12.12.1.p4.spkg (2.5 MB) - added by Snark 16 months ago.
ECL spkg without the SIGCHLD patch to upstream
trac_14636_sigchld.patch (996 bytes) - added by Snark 16 months ago.
Patch programmatically disabling SIGCHLD in sagelib's ECL code
ecl-12.12.1.p4.patch (2.8 KB) - added by Snark 15 months ago.
Patch against ecl's p3 for p4
trac_14636_1.patch (1012 bytes) - added by Snark 15 months ago.
Patch for sagelib -- about (1)
trac_14636_2.patch (3.4 KB) - added by Snark 15 months ago.
Patch for sagelib -- about (2)
ecl_p4_to_p5.patch (2.4 KB) - added by Snark 12 months ago.
Patch against ecl's p4 for p5

Change History (79)

comment:1 in reply to: ↑ description Changed 16 months ago by jdemeyer

Replying to Snark:

(2) I'm annoyed by the fact that SIGCHLD was disabled by directly patching the sources

I don't see any patch doing this, please clarify...

comment:2 in reply to: ↑ description Changed 16 months ago by leif

Replying to Snark:

(2) I'm annoyed by the fact that SIGCHLD was disabled by directly patching the sources -- wouldn't it be possible to change this by modifying an rc file or some such, whose path would be given to ecl at startup?

Which library does read start-up files? ;-)

comment:3 follow-up: Changed 16 months ago by Snark

@jdemeyer: disable_sigchdl_handler.patch is what you're looking for.

@leif: good catch! I had the impression that maxima was used as a library within ecl, but that ecl was used through its commandline. But indeed now that you ask, I see there is also a direct use of ecl-as-a-library. What saves the day though is that sage's ecl.pyx calls cl_boot itself, and hence it should be possible to modify the setting before that call. I should be able to do something about it.

comment:4 follow-up: Changed 16 months ago by nbruin

(1) unicode: I suppose there are no fundamental obstacles for that. However, you'll have to essentially rewrite the ecllib wrapper. With Py3 this might become worthwhile, since that has unicode strings internally anyway (although undoubtedly stored with an encoding different from ecl's). Also, our main use, Maxima, is solidly pre-unicode, so I don't think there will be any benefits for us and probably extra problems from Maxima possibly getting unexpected data.

(2) signals: ECL has very complex and ingenious infrastructure to deal with signals, and it expects to handle signals itself (which is a bit odd for a library). With threads enabled there will be a separate thread for asynchronous signals, and Boehm repurposes some exotic signals to sync threads on GC events. We cannot afford to submit to ECL's way of handling signals, so we do some pretty horrible stuff with signals when starting ECL anyway (and every time we call into ECL for longer times!) Disabling SIGCHLD is probably the least of your worries. Also, I don't think ECL does anything with SIGCHLD events anyway (other than possibly installing its own handler to provide a hook for ecl programs and which by default ignores the signal)

comment:5 in reply to: ↑ 3 Changed 16 months ago by jdemeyer

  • Description modified (diff)

Replying to Snark:

@jdemeyer: disable_sigchdl_handler.patch is what you're looking for.

Sorry, I was looking at an older version of the ECL spkg (this patch is a very recent addition).

comment:6 follow-up: Changed 16 months ago by Snark

@nbruin(1) where is the ticket about the python3 transition? As far as I know, a few sagenb deps (notably twisted and flask if I remember well) and some of sage's standard packages (for example pil) are a concern in that matter, but I can't find the relevant ticket.

@nbruin(2) I'll manage to deal with it : there's just an option to set in sage/libs/

comment:7 follow-ups: Changed 16 months ago by Snark

I just found that sage/libs/ecl.pxd has a copy of ecl's src/h/external.h's ecl_option enum... lacking the ECL_OPT_TRAP_SIGCHLD item! That means all subsequent items in the list are off-by-one... how is that code even supposed to run correctly!?

comment:8 in reply to: ↑ 7 Changed 16 months ago by nbruin

Replying to Snark:

I just found that sage/libs/ecl.pxd has a copy of ecl's src/h/external.h's ecl_option enum... lacking the ECL_OPT_TRAP_SIGCHLD item! That means all subsequent items in the list are off-by-one... how is that code even supposed to run correctly!?

I assume that's an "extern" definition. It just gets translated literally into the C-source which then uses the values that external.h provides. Just as cdef typedef extern struct can afford to only mention the fields that are of interest, or even only with approximate types.

It may well be that particular member wasn't in ecl when the wrapper was written. Add it if you need it.

comment:9 in reply to: ↑ 6 ; follow-up: Changed 16 months ago by jdemeyer

Replying to Snark:

@nbruin(1) where is the ticket about the python3 transition? As far as I know, a few sagenb deps (notably twisted and flask if I remember well) and some of sage's standard packages (for example pil) are a concern in that matter, but I can't find the relevant ticket.

I don't think there is a ticket yet, because it's obvious it's not going to happen anytime soon.

comment:10 in reply to: ↑ 9 ; follow-up: Changed 16 months ago by Snark

Replying to jdemeyer:

Replying to Snark:

@nbruin(1) where is the ticket about the python3 transition? As far as I know, a few sagenb deps (notably twisted and flask if I remember well) and some of sage's standard packages (for example pil) are a concern in that matter, but I can't find the relevant ticket.

I don't think there is a ticket yet, because it's obvious it's not going to happen anytime soon.

A ticket isn't just about something which will happen just now ; it's a central place where ideas get gathered about an issue. In this case, a ticket listing what is holding back sage for the switch to python3 would probably be worthy.

comment:11 in reply to: ↑ 7 ; follow-up: Changed 16 months ago by nbruin

Replying to Snark:

I just found that sage/libs/ecl.pxd has a copy of ecl's src/h/external.h's ecl_option enum... lacking the ECL_OPT_TRAP_SIGCHLD item!

Ah, indeed! You should just add that in ecl.pxd and do

    ecl_set_option(ECL_OPT_TRAP_SIGCHLD, 0)

before the boot call. Looked like Volker went for the quick-and-dirty solution there on #14055.

Note that even with that option, ECL still does install a SIGCHLD handler. However, we're not putting that back when we call ECL. Does SIGCHLD also need special treatment in eclsig.c? Jeroen is the expert on that file.

comment:12 in reply to: ↑ 11 ; follow-up: Changed 16 months ago by jdemeyer

Replying to nbruin:

Note that even with that option, ECL still does install a SIGCHLD handler.

Preferably, we don't have any SIGCHLD handler at all. Note that SIGCHLD is an unusual signal: it is the only signal which is ignored by default. Therefore, having a SIGCHLD handler which does nothing is still quite different from having no handler (and ignoring the signal).

Maybe it can be made to work with eclsig.c, but at least it requires some work.

comment:13 in reply to: ↑ 12 Changed 16 months ago by nbruin

Replying to jdemeyer:

Preferably, we don't have any SIGCHLD handler at all. Note that SIGCHLD is an unusual signal: it is the only signal which is ignored by default. Therefore, having a SIGCHLD handler which does nothing is still quite different from having no handler (and ignoring the signal).

I wondered about that. It's not clear to me why in our situation it even makes a difference what we do to ECL_OPT_TRAP_SIGCHLD(but given that Volker's fix had effect apparently it does).

The Sage SIGCHLD should be the default or ignore handler. Right after calling cl_boot we reset all handlers back to the sage handlers, so it shouldn't matter what ECL installs. We only change back some select handlers in eclsig.c and SIGCHLD is not one of them. Is there something that ecl changes that doesn't get reverted by sigaction?

Changed 16 months ago by Snark

ECL spkg without the SIGCHLD patch to upstream

Changed 16 months ago by Snark

Patch programmatically disabling SIGCHLD in sagelib's ECL code

comment:14 Changed 16 months ago by Snark

  • Description modified (diff)
  • Status changed from new to needs_review

comment:15 Changed 15 months ago by jdemeyer

  • Status changed from needs_review to needs_work
  • Work issues set to doctest

Please add the following doctest (sage/tests/interrupt.pyx is a good place for this test):

"""
Show that `SIGCHLD` is completely ignored by default. If the process
`p` finishes, there should be no `SIGCHLD` signal, so ``select()`` will
simply time out::

    sage: from select import select
    sage: import subprocess

    sage: p = subprocess.Popen(["sleep", "1"])  # long time
    sage: select([], [], [], 1.5)               # long time
    ([], [], [])
    sage: p.poll()                              # long time
    0

We now do the same but after installing a dummy `SIGCHLD`
handler::

    sage: import signal
    sage: def dummy_handler(a,b):
    ....:    pass
    sage: signal.signal(signal.SIGCHLD, dummy_handler)  # random
    sage: p = subprocess.Popen(["sleep", "1"])  # long time
    sage: select([], [], [], 1.5)               # long time
    Traceback (most recent call last):
    ...
    error: (4, 'Interrupted system call')
    sage: p.poll()                              # long time
    0

Reset the `SIGCHLD` handler::

    sage: signal.signal(signal.SIGCHLD, signal.SIG_IGN)  # random
"""

comment:16 Changed 15 months ago by jdemeyer

There is another complication with the test: the doctesting framework itself messes with SIGCHLD, so it needs slightly more work... let me think about it.

Last edited 15 months ago by jdemeyer (previous) (diff)

comment:17 in reply to: ↑ 4 Changed 15 months ago by nbruin

Unicode: See #12985. When I implemented ecl.pyx unicode support in ecl was not the default, so it was natural to skip it. I haven't kept up with its development, so I'm of little help for unicode-specific things. It looks like they got something close to working on #12985, though.

Given that all of calculus is designed to work with str, not with unicode, I think there is very little benefit in converting the ecl interface in being fully unicode aware (other than not having to turn off unicode support when building ecl), so the approach there (letting ecl work with unicode strings but convert them to ascii as soon as they leave ecl) is probably the quickest to get going.

comment:18 in reply to: ↑ 10 Changed 15 months ago by leif

Replying to Snark:

Replying to jdemeyer:

Replying to Snark:

@nbruin(1) where is the ticket about the python3 transition? As far as I know, a few sagenb deps (notably twisted and flask if I remember well) and some of sage's standard packages (for example pil) are a concern in that matter, but I can't find the relevant ticket.

I don't think there is a ticket yet, because it's obvious it's not going to happen anytime soon.

A ticket isn't just about something which will happen just now ; it's a central place where ideas get gathered about an issue. In this case, a ticket listing what is holding back sage for the switch to python3 would probably be worthy.

You have to dig deeper (on trac and sage-devel); there have been related tickets and threads years ago, as the Python devs keep claiming "There will be no further 2.x release after ...", and they do so since at least 2.4 IIRC.

(AFAIK the tickets mainly addressed removing [future] incompatibilities to Python 3.x from the Sage library, but also mention which upstream packages don't or won't [ever :-) ] work with Python 3.x, to that time of course.)


W.r.t. "holding back": There's no need to switch to Python 3.x ... ;-)

comment:19 Changed 15 months ago by Snark

  • Status changed from needs_work to needs_review
  • Work issues doctest deleted

Let's put this ticket back to need review : the patch which needs work is a patch about the handling of SIGCHLD in sage which is the matter of #14639.

What needs reviewing here is what is point (2) in the description : the move of the SIGCHLD code from a dirty patch within the ECL spkg to a correct ECL-library call in the sage library. The patch and the spkg I propose are a full solution to this issue ; I have already checked their correctness.

comment:20 Changed 15 months ago by fbissey

As to python 3.x Christopher started to track the status of the various package with regards to python 3: https://github.com/cschwan/sage-on-gentoo/issues/212

As to #12985 with Paulo's patch (Paulo used to package sage for Mandriva and now does sage for Fedora), if you build ecl with unicode you have to rebuild maxima and sage's ecl bits so it is all in sync. Had weird doctests issues but haven't checked lately. Look like Julien thinks it is all in order now.

comment:21 Changed 15 months ago by Snark

@fbissey:

  1. I think Christopher forgot PIL ;
  2. At #12985, I only checked patched-sage against current-ecl -- I'm now trying patched-sage against unicode-ecl, but since I don't have any fast computer, it takes almost a full day for a complete build+doctest...
  3. let's stop discussing py3 in this ticket as it's unrelated ;-)

comment:22 Changed 15 months ago by jpflori

  • Cc jpflori added

comment:23 Changed 15 months ago by Snark

  • Description modified (diff)
  • Status changed from needs_review to needs_work
  • Work issues set to rebase complete

Changed 15 months ago by Snark

Patch against ecl's p3 for p4

Changed 15 months ago by Snark

Patch for sagelib -- about (1)

Changed 15 months ago by Snark

Patch for sagelib -- about (2)

comment:24 Changed 15 months ago by Snark

  • Description modified (diff)
  • Status changed from needs_work to needs_review
  • Work issues changed from rebase complete to rebase

comment:25 Changed 15 months ago by jdemeyer

  • Authors set to Julien Puydt
  • Description modified (diff)

comment:26 Changed 15 months ago by jdemeyer

  • Dependencies set to #14662
  • Status changed from needs_review to needs_work
  • Work issues changed from rebase to rebase, SIGCHLD doctest

comment:27 Changed 15 months ago by jdemeyer

  • Dependencies changed from #14662 to #11359

comment:28 follow-up: Changed 15 months ago by Snark

What do you mean by "SIGCHLD doctest"? My modification doesn't change the situation -- it changes how one obtains it: the current way is by patching upstream sources, the patched way is by calling an api function.

comment:29 in reply to: ↑ 28 Changed 15 months ago by jdemeyer

Replying to Snark:

My modification doesn't change the situation

I am not convinced that this is true. I'm not at all saying that you're wrong, just saying that it's not obvious that you're right. A doctest can prove that you're right.

Last edited 15 months ago by jdemeyer (previous) (diff)

comment:30 follow-up: Changed 15 months ago by Snark

Just look at the current situation: there is a patch to add a zero in a structure. What does my patch do? It calls a function to add a zero in a structure. No doctest will be able to say whether the zero was obtained by patching or by calling a function -- but for distribution packagers, that makes all the difference, since there's no way they'll just patch upstream just for sage.

Even if I convince you, don't close or apply the changes: I'm working on a better set of modifications to also get rid of the disabled threading stuff.

comment:31 in reply to: ↑ 30 Changed 15 months ago by nbruin

Replying to Snark:

I'm working on a better set of modifications to also get rid of the disabled threading stuff.

It's great if you can get that to work.

I considered enabling threading in ECL as fundamentally incompatible with the way we use it in Sage. It will cause ECL to split off a dedicated thread to handle asynchronous events and it will cause Boehm to repurpose some exotic signals to synchronize thread on garbage collection, and those signals will confuse the sage signal handler if it happens to receive them.

We are switching signal handlers upon entry/exit of ECL. With multiple threads it is not clear anymore whether sage or ECL should be in control of asynch signals at any one time.

We won't get much benefit from the change either: our main use, Maxima, uses global data structures everywhere and wasn't built with multi-processing in mind at all. It will not be able to utilize multiple threads for a long time.

comment:32 follow-up: Changed 15 months ago by Snark

Ah, Nils, your explanations are really interesting: that would explain why I see signals (30=SIGPWR) without understanding exactly what happens.

Though there is something you miss when you say that there is not much to benefit from the change: debian's ecl is built with threads, so if sage is to be properly packaged, then it has to work with threads!

comment:33 in reply to: ↑ 32 Changed 15 months ago by nbruin

Replying to Snark:

Ah, Nils, your explanations are really interesting: that would explain why I see signals (30=SIGPWR) without understanding exactly what happens.

You might want to read a bit of source for this. It was enlightening to me at the time. If I remember correctly, Boehm decides at runtime whether to use those signals (IIRC it keeps track of a list of threads registered with it and if that list is longer than one, it issues those signals), so you may be able to avoid those quite easily as soon as you get ECL to not create threads.

See ECL_OPT_SIGNAL_HANDLING_THREAD for ECL (and probably the source!) If this means we get no signal handling at all in ECL, we have a bit of a problem, of course. We still want CTRL-C and perhaps even SIGALRM to work. What we really need is that ENABLE_THREADS is a boot-time option.

See also #11752, although I think that with the latest ECL upgrade it was found that threading had become even more default than before and hence had to be explicitly disabled at boottime.

Though there is something you miss when you say that there is not much to benefit from the change: debian's ecl is built with threads, so if sage is to be properly packaged, then it has to work with threads!

I seriously think that's going to be a no-go. While ECL's and sage's way of handling signals are both sensible on their own, I think they are quite incompatible. Without any threads, we can sort of manage by switching the handlers. But I'm afraid that when ECL is compiled with thread support, it insists on handling async events on a separate thread under its own control. I was hoping you had a brilliant insight.

Last edited 15 months ago by nbruin (previous) (diff)

comment:34 Changed 15 months ago by Snark

Well, I have seen the ECL_OPT_SIGNAL_HANDLING_THREAD option, because indeed choosing whether to enable threading at runtime vs compile-time is the way to go. I just need to find the time to do proper experiments.

comment:35 follow-up: Changed 15 months ago by vbraun

The patch to disable the ECL SIGCHLD handler is from #14055. We had a very subtle race between a SIGCHLD and ECL's handler. When you move this to ecl_set_option then you are booting up ECL with the SIGCHLD handler, right? This seems to open up a new window for race conditions. ECL should default to no SIGCHLD handler, possibly enabling it by an option.

comment:36 in reply to: ↑ 35 Changed 15 months ago by nbruin

Replying to vbraun:

The patch to disable the ECL SIGCHLD handler is from #14055. We had a very subtle race between a SIGCHLD and ECL's handler. When you move this to ecl_set_option then you are booting up ECL with the SIGCHLD handler, right?

Nope. ecl_set_option is called prior to cl_boot, which does all ecl initialization. The fix on #14055 patched ECL to change the default value of the boot option. The inclusion of an explicit ecl_set_option prior to cl_boot is the appropriate way of overriding the default value and should be preferred over patching ecl.

comment:37 follow-ups: Changed 15 months ago by jpflori

comment:38 Changed 15 months ago by Snark

I'll give it a try. I'm still going nowhere :-/

comment:39 in reply to: ↑ 37 Changed 15 months ago by fbissey

Replying to jpflori:

FYI ECL 13.5.1 has been released:

and it's terrible it switched to asdf 3 and in Sage-on-gentoo we haven't been able to build a working maxima_lib with it for the last 10 days.

comment:40 follow-up: Changed 15 months ago by jpflori

It says ASDF 2.32 in the changelog, doesn't it?

comment:41 Changed 15 months ago by Snark

I can confirm the new ECL doesn't fit in-place. :'-(

comment:42 in reply to: ↑ 40 Changed 15 months ago by fbissey

Replying to jpflori:

It says ASDF 2.32 in the changelog, doesn't it?

I am not sure that's correct. I'll have to check. From the git clone I have Juan hadn't committed asdf 3.0.1 yet. However I think it was not many commits away from 3.0.

One of the main point is that ecl use to have the asdf-bundle extension (né asdf-ecl as they say) and that extension has been merged in asdf (2.66?) and underwent some changes in the process.

We have a formula to build a maxima.fas with the new ecl but it leads to segfault when we load it (from sage or even from ecl itself).

In Gentoo the lisp team has decided to move things to asdf 3.0.1 as fast as they can, but the harm for maxima_lib has been somewhat before 3.0.1. See https://github.com/cschwan/sage-on-gentoo/issues/226 for our status.

This is our current formula to build maxima.fas

		cd src
		ecl \
			-eval '(require `asdf)' \
			-eval '(push "./" asdf:*central-registry*)' \
			-eval "(asdf:initialize-output-translations \
				'(:output-translations :disable-cache :inherit-configuration))" \
			-eval '(load "maxima-build.lisp")' \
			-eval '(asdf:make-build :maxima :type :fasl)' \
			-eval '(quit)'
		ECLLIB=`ecl -eval "(princ (SI:GET-LIBRARY-PATHNAME))" -eval "(quit)"`
		insinto "${ECLLIB#${EPREFIX}}"
		newins maxima.fasb maxima.fas

comment:43 Changed 15 months ago by nbruin

Two comments that might be useful:

  • When I figured out the original formula, I used trial and error and a bit of reading documentation. I found something that worked and didn't look like it was using any illegal hacks, I was happy. The new formula looks fine in that respect too, so if it works use it!
  • The .fasb files were used by ADSF to avoid overwriting files produced by ECL's native build routines. As far as I could see the format is the same as the .fas files. I did the rename to ensure that (require `maxima) would work without first doing (require `asdf) (which was necessary for recognising what to do with .fasb files). Since ASDF is getting more closely integrated into ECL, you may be able to modify or avoid this renaming step.

comment:44 Changed 15 months ago by fbissey

Thanks for the encouragement Nils. It is not impossible that we have in fact uncovered some kind of bug. If Martin is right we go through an initialisation twice and the second time we fall into an infinite loop.

comment:45 Changed 15 months ago by jdemeyer

  • Dependencies #11359 deleted

comment:46 Changed 15 months ago by fbissey

Just a head up about ecl 13.1.5 and asdf upgrade issues. We have a working maxima_lib in sage-on-gentoo. So we can upgrade ecl as we now have a procedure and patch for maxima (both 5.29.1 and 5.30.0 but issues with 5.30.0 are documented in another ticket).

comment:47 Changed 14 months ago by Snark

I finally found the time to have look ; the spkg-src script fails with "mv: cannot stat `gmp': No such file or directory"... this is with upstream's 12.12.1 tarball.

Where is the ticket with the ecl 13.1.5 discussion?

comment:48 Changed 14 months ago by fbissey

We had a long thread about it - or rather the new asdf - on github for sage-on-gentoo. No spkg at this stage. The short of it is that ecl should be fine without patches. maxima, any version, needs a patch to produce what we want. The current procedure just won't work. https://github.com/cschwan/sage-on-gentoo/issues/226

comment:49 follow-up: Changed 14 months ago by Snark

François, if you have a way to have a no-patch-ecl+lightly-patched-maxima combination to work, perhaps it would be best to push it into sage and be done with this ticket?

comment:50 Changed 14 months ago by fbissey

Now that I am starting to remember stuff, removing the "dirty workaround" discussed in this ticket will break one doctest at least. But then I haven't tested your patches either.

I have problems getting enough time to work on sage these days and it will probably become worse until September. I cannot give you expectation that I will make the two spkgs in question in a timely fashion.

comment:51 Changed 13 months ago by dimpase

by the way, patches/disable_sigchdl_handler.patch apparently breaks OSX PPC support.

comment:52 follow-up: Changed 13 months ago by Snark

Dima, then my first patch which moves the change into sagelib should there break too. That would probably mean there's an upstream issue on OSX PPC... Can you check?

comment:53 follow-up: Changed 13 months ago by vbraun

Can you be a bit more vague about what does not work on OSX PPC without the sigchld handler?

comment:54 in reply to: ↑ 53 Changed 13 months ago by dimpase

Replying to vbraun:

Can you be a bit more vague about what does not work on OSX PPC without the sigchld handler?

Let me try using less, as more is not installed :–)

Not very informative segfault with ecl-12.12.1.p4:

...
;*** Lisp core booted ****
ECL (Embeddable Common Lisp)

;;;
;;; Welcome to bare.lsp. Let's bring this instance up!
;;;
;;;
;;; About to load lsp/load.lsp
;;; 
;;; Loading src:lsp;export.lsp/bin/sh: line 1: 97036 Segmentation fault      ECLDIR=`pwd`/ ./ecl_min compile
make[4]: *** [bin/ecl] Error 139
make[3]: *** [all] Error 2
Error - Failed to build ECL ... exiting
...

comment:55 in reply to: ↑ 52 Changed 13 months ago by dimpase

Replying to Snark:

Dima, then my first patch which moves the change into sagelib should there break too. That would probably mean there's an upstream issue on OSX PPC... Can you check?

it turns out that reenabling Altivec back in p2 was the cause of trouble. If I reapply the patch from #11297

--- a/spkg-install	Wed Jun 05 19:56:22 2013 +0000
+++ b/spkg-install	Wed Aug 14 23:25:31 2013 +0800
@@ -48,6 +48,12 @@
     CXXFLAGS="-g -O2 $CXXFLAGS"
 fi
 
+if [ "`uname -sm`" = "Darwin Power Macintosh" ] ; then 
+# Disabling altivec instructions (trac 11297) 
+    CFLAGS="$CFLAGS -mno-altivec -mabi=no-altivec" 
+    export CFLAGS 
+fi 
+
 # These are all used by GNU to specify compilers.
 echo "Using CC=$CC"
 echo "Using CXX=$CXX"

then p4 works for me. Sorry for noise.

comment:56 Changed 12 months ago by Snark

  • Description modified (diff)
  • Status changed from needs_work to needs_review

comment:57 Changed 12 months ago by Snark

  • Work issues rebase, SIGCHLD doctest deleted

comment:58 follow-up: Changed 12 months ago by jdemeyer

  • Status changed from needs_review to needs_work
  • Work issues set to SIGCHLD doctest, spkg-src

1) I don't think the work issue "SIGCHLD doctest" has been addressed.

2) Why do you stop removing unneeded stuff from the upstream sources? It adds 4.5MB for absolutely no reason.

comment:59 Changed 12 months ago by jdemeyer

Also in SPKG.txt, there is something wrong with the sentence "don't path to disable SIGCHLD."

comment:60 in reply to: ↑ 58 ; follow-ups: Changed 12 months ago by Snark

Replying to jdemeyer:

1) I don't think the work issue "SIGCHLD doctest" has been addressed.

I don't have any failing doctest: what exactly do you want? Again, I'm just moving something from patching upstream to calling an api...

2) Why do you stop removing unneeded stuff from the upstream sources? It adds 4.5MB for absolutely no reason.

If unicode isn't disabled, it's not unneeded anymore.

comment:61 Changed 12 months ago by Snark

I made a new p5 spkg, available at the same place, and also updated the p4 to p5 patch here.

comment:62 Changed 12 months ago by Snark

  • Status changed from needs_work to needs_review

comment:63 in reply to: ↑ 60 Changed 12 months ago by nbruin

Replying to Snark:

If unicode isn't disabled, it's not unneeded anymore.

That may be true for the contrib/encodings and contrib/unicode subdirectories, but do you now need msvc, src/gc-unstable, src/libffi and all of src/gmp? Your attached patch suggests you're not removing those either anymore. The attached patch also doesn't reflect the edits to spkg-make that you probably made.

Last edited 12 months ago by nbruin (previous) (diff)

comment:64 Changed 12 months ago by Snark

  • Status changed from needs_review to needs_work
  • Work issues changed from SIGCHLD doctest, spkg-src to spkg-src

My attached patch wasn't reflecting edits to spkg-src because I didn't touch it. The next version will modify it, and only not to remove the unicode-related directories.

I'll push the new patch when I'll have checked it's ok. For now I just know it builds correctly.

Changed 12 months ago by Snark

Patch against ecl's p4 for p5

comment:65 Changed 12 months ago by Snark

  • Status changed from needs_work to needs_review
  • Work issues spkg-src deleted

No failing doctest ; now src/ is generated by a patched spkg-src.

comment:66 Changed 12 months ago by Snark

  • Description modified (diff)

It's still ok with 5.12.beta4.

comment:67 in reply to: ↑ 60 ; follow-up: Changed 12 months ago by jdemeyer

Replying to Snark:

Again, I'm just moving something from patching upstream to calling an api...

Again, that's only a claim. A doctest can prove you are right.

comment:68 in reply to: ↑ 67 Changed 12 months ago by Snark

  • Status changed from needs_review to needs_work
  • Work issues set to add doctest

Replying to jdemeyer:

Replying to Snark:

Again, I'm just moving something from patching upstream to calling an api...

Again, that's only a claim. A doctest can prove you are right.

OOOHHH!!!! You want me to ADD a doctest!

I'm not sure it makes much sense to follow a line "a=0" by a doctest "a==0", but if you want I'll add one.

comment:69 Changed 11 months ago by fbissey

I see that trac_14636_2.patch is the same (up to a slight edit in the commit) than the patch in #12985 so incorporating this ticket would make it a duplicate. I think you should go ahead and add the doctest.

comment:70 Changed 10 months ago by vbraun

In the spirit of having one ticket per issue I've broken off the part about using and doctesting ecl_set_option(ECL_OPT_TRAP_SIGCHLD, 0) into a new ticket at #15441

comment:71 Changed 5 months ago by vbraun

  • Authors changed from Julien Puydt to Volker Braun
  • Status changed from needs_work to needs_review

Duplicate of #12985, so close one of them. This one.

comment:72 in reply to: ↑ 49 Changed 5 months ago by gagern

Replying to Snark:

François, if you have a way to have a no-patch-ecl+lightly-patched-maxima combination to work, perhaps it would be best to push it into sage and be done with this ticket?

I've just pushed the build formula used on sage-on-gentoo into a branch associated with ticket:16178.

comment:73 in reply to: ↑ 37 Changed 3 months ago by gagern

Replying to jpflori:

FYI ECL 13.5.1 has been released:

With the new maxima build system included in sage 6.2, do you want to aim for an ECL update for 6.3?

Note: See TracTickets for help on using tickets.