Opened 10 years ago

Closed 9 years ago

Last modified 9 years ago

#11119 closed defect (duplicate)

ECL 11.1.1 fails on Cygwin

Reported by: mhansen Owned by: tbd
Priority: major Milestone: sage-duplicate/invalid/wontfix
Component: porting: Cygwin Keywords:
Cc: leif Merged in:
Authors: Reviewers: Jeroen Demeyer
Report Upstream: Fixed upstream, but not in a stable release. Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Status badges

Description (last modified by jdemeyer)

ECL 11.1.1 fails on Cygwin with

gcc -DECLDIR="\"/home/mhansen/sage-4.7.alpha3/local/lib/ecl-11.1.1\"" -I. -I/home/mhansen/sage-4.7.alpha3/spkg/build/ecl-11.1.1/src/build -I/home/mhansen/sage-4.7.alpha3/spkg/build/ecl-11.1.1/src/src/c -I../ecl/gc -DECL_API -DECL_NO_LEGACY   -I/home/mhansen/sage-4.7.alpha3/local/include  -g -O2   -Dcygwin -c -o ffi/libraries.o tmp.c
/home/mhansen/sage-4.7.alpha3/spkg/build/ecl-11.1.1/src/src/c/ffi/libraries.d: In function ‘copy_object_file’:
/home/mhansen/sage-4.7.alpha3/spkg/build/ecl-11.1.1/src/src/c/ffi/libraries.d:108: error: ‘S_IRWXU’ undeclared (first use in this function)
/home/mhansen/sage-4.7.alpha3/spkg/build/ecl-11.1.1/src/src/c/ffi/libraries.d:108: error: (Each undeclared identifier is reported only once
/home/mhansen/sage-4.7.alpha3/spkg/build/ecl-11.1.1/src/src/c/ffi/libraries.d:108: error: for each function it appears in.)
make[4]: *** [ffi/libraries.o] Error 1

another problem is absence of double inclusion guard in /usr/include/fenv.h, which causes other troubles (see below). This is in fact a Cygwin bug uncovered here (cf. below), which should be fixed in the next Cygwin update. Meanwhile, you could edit your /usr/include/fenv.h.


Upstream patches fixing the issues here are in the spkg below. This is separate from Cygwin fixing their problems, of course, so hopefully once both have new stable releases we'll really be in good shape, but this package should be sufficient on both XP and Windows 7.


See instead #11884.

Attachments (2)

trac_11119-p2.diff (1.7 KB) - added by kcrisman 10 years ago.
For review purposes only
trac_11119-p3.diff (2.6 KB) - added by kcrisman 10 years ago.
For review purposes only

Download all attachments as: .zip

Change History (59)

comment:1 Changed 10 years ago by fbissey

Could you attach the full log? We should at least have a look at what happened during configure.

comment:2 follow-ups: Changed 10 years ago by mhansen

I believe fixing it is just a matter of including sys/stat.h in that file on Cygwin.

comment:3 in reply to: ↑ 2 Changed 10 years ago by fbissey

Replying to mhansen:

I believe fixing it is just a matter of including sys/stat.h in that file on Cygwin.

Would make sense. Is upstream aware of this? Also, was there any issue with ecl-10.4.1? I may have a look at making yet again another ecl-11.1.1 spkg when I have a bit of time.

comment:4 in reply to: ↑ 2 ; follow-up: Changed 10 years ago by dimpase

Replying to mhansen:

I believe fixing it is just a matter of including sys/stat.h in that file on Cygwin.

no, this redefines a bunch of stuff and does not compile as a result.

comment:5 in reply to: ↑ 4 ; follow-up: Changed 10 years ago by dimpase

Replying to dimpase:

Replying to mhansen:

I believe fixing it is just a matter of including sys/stat.h in that file on Cygwin.

no, this redefines a bunch of stuff and does not compile as a result.

oops, please ignore this. Adding the include to libraries.d fixes this particular problem.

The next one is in c/numbers/cos.d:

...
if test -f ../CROSS-DPP ; then ../CROSS-DPP /home/dima/sage-4.7.alpha5/spkg/buil
d/ecl-11.1.1.p0/src/src/c/numbers/cos.d tmp.c ; else ./dpp.exe /home/dima/sage-4
.7.alpha5/spkg/build/ecl-11.1.1.p0/src/src/c/numbers/cos.d tmp.c ; fi
dpp: /home/dima/sage-4.7.alpha5/spkg/build/ecl-11.1.1.p0/src/src/c/numbers/cos.d
 -> tmp.c
gcc -DECLDIR="\"/home/dima/sage-4.7.alpha5/local/lib/ecl-11.1.1\"" -I. -I/home/d
ima/sage-4.7.alpha5/spkg/build/ecl-11.1.1.p0/src/build -I/home/dima/sage-4.7.alp
ha5/spkg/build/ecl-11.1.1.p0/src/src/c -I../ecl/gc -DECL_API -DECL_NO_LEGACY   -
I/home/dima/sage-4.7.alpha5/local/include  -g -O2   -Dcygwin -c -o numbers/cos.o
 tmp.c
In file included from /home/dima/sage-4.7.alpha5/spkg/build/ecl-11.1.1.p0/src/bu
ild/ecl/impl/math_fenv.h:68,
                 from /home/dima/sage-4.7.alpha5/spkg/build/ecl-11.1.1.p0/src/bu
ild/ecl/impl/math_dispatch.h:20,
                 from /home/dima/sage-4.7.alpha5/spkg/build/ecl-11.1.1.p0/src/sr
c/c/numbers/cos.d:21:
/usr/include/fenv.h:52: error: redefinition of `struct _fenv_t'
/usr/include/fenv.h:53: error: redefinition of `struct _fpu_env_info'
/usr/include/fenv.h:63: error: conflicting types for `fenv_t'
/usr/include/fenv.h:63: error: previous declaration of `fenv_t' was here
/usr/include/fenv.h:75: error: redefinition of `struct _fexcept_t'
/usr/include/fenv.h:78: error: conflicting types for `fexcept_t'
/usr/include/fenv.h:78: error: previous declaration of `fexcept_t' was here
/usr/include/fenv.h:127: error: conflicting types for `_fe_dfl_env'
/usr/include/fenv.h:127: error: previous declaration of `_fe_dfl_env' was here
/usr/include/fenv.h:148: error: conflicting types for `fegetexceptflag'
/usr/include/fenv.h:148: error: previous declaration of `fegetexceptflag' was he
re
/usr/include/fenv.h:150: error: conflicting types for `fesetexceptflag'
/usr/include/fenv.h:150: error: previous declaration of `fesetexceptflag' was he
re
/usr/include/fenv.h:154: error: conflicting types for `fegetenv'
/usr/include/fenv.h:154: error: previous declaration of `fegetenv' was here
/usr/include/fenv.h:155: error: conflicting types for `feholdexcept'
/usr/include/fenv.h:155: error: previous declaration of `feholdexcept' was here
/usr/include/fenv.h:156: error: conflicting types for `fesetenv'
/usr/include/fenv.h:156: error: previous declaration of `fesetenv' was here
/usr/include/fenv.h:157: error: conflicting types for `feupdateenv'
/usr/include/fenv.h:157: error: previous declaration of `feupdateenv' was here
make[4]: *** [numbers/cos.o] Error 1
make[4]: Leaving directory `/home/dima/sage-4.7.alpha5/spkg/build/ecl-11.1.1.p0/
src/build/c'
make[3]: *** [libeclmin.a] Error 2
make[3]: Leaving directory `/home/dima/sage-4.7.alpha5/spkg/build/ecl-11.1.1.p0/
src/build'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/home/dima/sage-4.7.alpha5/spkg/build/ecl-11.1.1.p0/
src'
Error - Failed to build ECL ... exiting

comment:6 in reply to: ↑ 5 ; follow-up: Changed 10 years ago by dimpase

Replying to dimpase: apparently, all this is caused by a new Cygwin:

http://www.mail-archive.com/ecls-list@lists.sourceforge.net/msg00966.html

comment:7 in reply to: ↑ 6 ; follow-ups: Changed 10 years ago by dimpase

  • Report Upstream changed from N/A to Not yet reported upstream; Will do shortly.

Replying to dimpase:

Replying to dimpase: apparently, all this is caused by a new Cygwin:

http://www.mail-archive.com/ecls-list@lists.sourceforge.net/msg00966.html

indeed, it's just that /usr/include/fenv.h is not protected from double inclusion. Adding

#define _FENV_H_

into its first lines fixes the problem, and ecl builds! I'll notify upstream (cygwin) on this. If this is not fixed in cygwin itself, then it's of course trivial to fix in the ecl code.

comment:8 in reply to: ↑ 7 Changed 10 years ago by dimpase

Replying to dimpase: they were quick:

http://cygwin.com/ml/cygwin/2011-04/msg00336.html

so the fenv.h problem will be fixed in the coming release; meanwhile feel free to edit the system header :)

comment:9 Changed 10 years ago by dimpase

  • Description modified (diff)

comment:10 Changed 10 years ago by dimpase

  • Description modified (diff)

comment:11 Changed 10 years ago by kcrisman

Trying this on XP now.

comment:12 Changed 10 years ago by kcrisman

  • Authors set to Dima Pasechnik, Mike Hansen
  • Reviewers set to Karl-Dieter Crisman
  • Status changed from new to needs_review

This (adding the include in sys/stat.h) appears to work fine on XP!

Here's what's needed for positive review, I think.

  • Make an spkg with that change, that includes information to deprecate for newer Cygwin (or that has a switch for different versions with a patching in the old case).
  • Testing the spkg on XP.
  • Testing the spkg on 7.

comment:13 Changed 10 years ago by kcrisman

  • Status changed from needs_review to needs_work

comment:14 Changed 10 years ago by kcrisman

  • Report Upstream changed from Not yet reported upstream; Will do shortly. to Fixed upstream, but not in a stable release.

comment:15 Changed 10 years ago by kcrisman

  • Authors changed from Dima Pasechnik, Mike Hansen to Dima Pasechnik, Mike Hansen, Karl-Dieter Crisman
  • Status changed from needs_work to needs_review

Ok, spkg available at http://sage.math.washington.edu/home/kcrisman/ecl-11.1.1.p2.spkg.

Also, of course testing on non-Cygwin systems welcome! If this doesn't fix Dima's Windows 7 issue, I still think that we have to do something like this, because the latest available Cygwin for download is from before his email exchange, even. So it will take time for that fix to be available.

comment:16 in reply to: ↑ 7 ; follow-up: Changed 10 years ago by kcrisman

  • Status changed from needs_review to needs_work

On Windows 7, I get the same failure as Dima (it does get past the failure noted on Mike's patch).

indeed, it's just that /usr/include/fenv.h is not protected from double inclusion. Adding

#define _FENV_H_

into its first lines fixes the problem, and ecl builds! I'll notify upstream (cygwin) on this. If this is not fixed in cygwin itself, then it's of course trivial to fix in the ecl code.

What is the way to fix this in ECL itself, given that a new Cygwin is not currently available?

comment:17 in reply to: ↑ 16 Changed 10 years ago by dimpase

Replying to kcrisman:

What is the way to fix this in ECL itself, given that a new Cygwin is not currently available?

hunt down the corresponding #includes and remove them. (the problem is that there is a fair amount of C code generation going on, and you really don't want to know how exactly it happens)

comment:18 Changed 10 years ago by kcrisman

Good news - the double include that is the problem in the traceback above (cos.d) is fixed here. Literally "Avoid including fenv.h twice".

So this is fixed in an upstream unstable release as well. I'll try to make a new spkg with this once I test it, assuming there are no other problems. Obviously it's best to have both fixes, but at least one is good.

comment:19 Changed 10 years ago by kcrisman

Another similar error... but again good news, because at the same time Juanjo must have also fixed a very similar problem in c/unixint.d here. I'll include that in any spkg as well.

comment:20 Changed 10 years ago by kcrisman

And the original failure Mike reported, as well as the fix with including sys/stat.h, is fixed in CVS here.

comment:21 Changed 10 years ago by kcrisman

Okay, these three fixes combined allow ECL to build properly on Windows 7. Assuming there isn't a new ECL coming along immediately (and assuming we don't want to mess with trying to upgrade it immediately anyway, save the Maxima issue) I may make a new spkg just for this.

comment:22 Changed 10 years ago by fbissey

If you are going to make a new spkg we may as well address #11359 as well. I probably could push a maxima-5.24.0 spkg at the same time if I am not too lazy.

comment:23 Changed 10 years ago by kcrisman

  • Milestone set to sage-4.7.2
  • Status changed from needs_work to needs_review

Ummm... I really don't know anything about that ticket, and it seems much more intrusive. These three patches are all very small from upstream. I'm going to stick with just addressing this. You can always try to do a one on that ticket that takes these into account, of course! Hopefully someone can review this one soon.

Ready for review - spkg available at http://sage.math.washington.edu/home/kcrisman/ecl-11.1.1.p3.spkg.

comment:24 Changed 10 years ago by kcrisman

  • Description modified (diff)

comment:25 follow-up: Changed 10 years ago by kcrisman

User "RegB" was able to use this successfully for this - see this sage-windows thread.

So this just needs someone to look at the actual spkg.

comment:26 Changed 10 years ago by kcrisman

  • Reviewers changed from Karl-Dieter Crisman to Karl-Dieter Crisman, Reg Burgess

That is, this needs someone other than me to look at the actual spkg and its construction :) - should be very easy.

comment:27 in reply to: ↑ 25 Changed 10 years ago by kcrisman

Replying to kcrisman:

User "RegB" was able to use this successfully for this - see this sage-windows thread.

That was on Vista, just FYI, but that should be okay for this ticket.

comment:28 Changed 10 years ago by kcrisman

Just a comment FYI: I have gotten Sage to start on Cygwin, and anything using the ECL library (as opposed to just plain old ECL or Maxima as binaries) fails with

ImportError: No such process

That would be a separate ticket, of course, but just wanted to point it out.

comment:29 Changed 10 years ago by kcrisman

Sorry for the noise - that seems to be with the current p2 spkg, not the p3 spkg here. I'm not sure how it is that ECL and Maxima nonetheless work, but must be an XP thing...

comment:30 follow-up: Changed 10 years ago by kcrisman

And again noise... the p2 is also here, don't know how I didn't realize that. Anyway, there is an ecl.dll in both sage/local/bin/ and sage/local/lib/, but not all the .a files in libs/ecl/ are thus. Since I know nothing about .a files, I don't know whether that would be a problem, though.

comment:31 in reply to: ↑ 30 Changed 10 years ago by dimpase

Replying to kcrisman:

And again noise... the p2 is also here, don't know how I didn't realize that. Anyway, there is an ecl.dll in both sage/local/bin/ and sage/local/lib/, but not all the .a files in libs/ecl/ are thus. Since I know nothing about .a files, I don't know whether that would be a problem, though.

a .a file is typically a static object library, i.e. something one links against. It shouldn't be needed at the runtime, typically (unless you want to rebuild things on the fly). You can check the type of the file by using Cygwin's "file" command. (i.e. somethign like

     $ file output.pdf 
    output.pdf: PDF document, version 1.4

comment:32 Changed 10 years ago by kcrisman

It turns out that this (unrelated) failure is already know, from over a year ago - see #9167. Unfortunately, in the meantime the library is the default way to interact with ECL and Maxima, so this is much more serious now.

PS - feel free to unpack the spkg and check it's made correctly to finish positive review here :)

comment:33 Changed 10 years ago by kcrisman

  • Cc leif added

I just checked and there is no garbage.

I'm also attaching the diffs for the p2 and p3 spkgs. Should be a REALLY easy task to finish the review now :)

Changed 10 years ago by kcrisman

For review purposes only

Changed 10 years ago by kcrisman

For review purposes only

comment:34 Changed 10 years ago by kcrisman

I should also point out that these changes are all in ECL cvs, so applying the patches universally should not be a problem (don't need to only apply on Cygwin).

There is also a typo in a comment in the spkg-install ("is in" instead of "are in") but this should really not affect the review.

comment:35 Changed 9 years ago by fbissey

  • Status changed from needs_review to positive_review

I am giving this a positive review and I will base my own new ecl spkg for silius #11708 on this one.

comment:36 follow-up: Changed 9 years ago by fbissey

  • Status changed from positive_review to needs_work
  • Work issues set to Remove .DS_Store files

Ooopsie! There's a few .DS_Store files from OS X in the sources. I'll remove these in my .p4 but it would be good if they were gone from this one in case #11708 doesn't move in 4.7.2.

tar tf ecl-11.1.1.p3.tar  | grep Store
ecl-11.1.1.p3/src/._.DS_Store
ecl-11.1.1.p3/src/src/h/._.DS_Store
ecl-11.1.1.p3/src/src/h/.DS_Store
ecl-11.1.1.p3/src/src/c/ffi/._.DS_Store
ecl-11.1.1.p3/src/src/c/ffi/.DS_Store
ecl-11.1.1.p3/src/src/c/._.DS_Store
ecl-11.1.1.p3/src/src/c/.DS_Store
ecl-11.1.1.p3/src/src/._.DS_Store
ecl-11.1.1.p3/src/src/.DS_Store
ecl-11.1.1.p3/src/.DS_Store

comment:37 in reply to: ↑ 36 Changed 9 years ago by kcrisman

I am giving this one a positive review ...

Thank you so much, François.

Ooopsie! There's a few .DS_Store files from OS X in the sources. I'll remove these in my .p4 but it would be good if they were gone from this one in case #11708 doesn't move in 4.7.2.

Just shoot me now. It's as if I can't avoid this. I don't even know if I went into all these directories, much less changed anything.

comment:38 Changed 9 years ago by fbissey

Recipe:

  • make a spkg, foo.spkg
  • keep the foo/ folder
  • tar tjf foo.spkg | grep Store
  • if nothing shows up you are good to go
  • if something shows up
    tar tjf foo.spkg | grep Store | xargs rm
    
  • recreate foo.spkg

Hope that helps. It looks like I won't be making a new spkg unless we find a way to avoid a gcc problem in ecl source.

comment:39 follow-up: Changed 9 years ago by kcrisman

Maybe I should just make a new spkg that we can set back to positive review...

Also, see #11884 for yet another ECL upgrade ticket. To wit:

> I got this to build by pulling from their latest repository:
> git clone git://ecls.git.sourceforge.net/gitroot/ecls/ecl

which could be helpful in order to finally fix #11502/#11260, if the change in the use of forking is in there...

comment:40 in reply to: ↑ 39 ; follow-up: Changed 9 years ago by leif

  • Authors changed from Dima Pasechnik, Mike Hansen, Karl-Dieter Crisman to Dmitrii Pasechnik, Mike Hansen, Karl-Dieter Crisman

Replying to kcrisman:

Maybe I should just make a new spkg that we can set back to positive review...

I'd say go ahead, such that others can base new ECL spkgs on this one.

Perhaps also take into account this comment. :P


Also, see #11884 for yet another ECL upgrade ticket.

Well, there doesn't seem to be any progress on that ticket; at least Maxima is said to not work or build on MacOS X 10.7 yet, even with the ECL git snapshot (which version?).

comment:41 in reply to: ↑ 40 Changed 9 years ago by kcrisman

  • Status changed from needs_work to positive_review
  • Work issues Remove .DS_Store files deleted

Maybe I should just make a new spkg that we can set back to positive review...

I'd say go ahead, such that others can base new ECL spkgs on this one.

Okay, same location.

Perhaps also take into account this comment. :P

Umm, I think I'll pass. Then I would feel like I had to retest it on several platforms, and I simply don't have the time currently.

comment:42 Changed 9 years ago by kcrisman

Clean bill of health:

mycomputer:Downloads me$ tar tjf ecl-11.1.1.p3.spkg | grep Store
mycomputer:Downloads

Probably too much to ask for 4.7.2, but one can hope...

comment:43 Changed 9 years ago by jdemeyer

  • Milestone changed from sage-4.7.2 to sage-4.7.3

comment:44 Changed 9 years ago by jdemeyer

  • Description modified (diff)

comment:45 Changed 9 years ago by jdemeyer

  • Merged in set to sage-4.7.3.alpha0
  • Resolution set to fixed
  • Status changed from positive_review to closed

comment:46 Changed 9 years ago by leif

In case no follow-up spkg fixes this (and gets merged into the same release), the spkg needs work, because the exit codes of patch aren't checked at all. (Cf. #11884)

comment:47 Changed 9 years ago by kcrisman

  • Reviewers changed from Karl-Dieter Crisman, Reg Burgess to Karl-Dieter Crisman, Reg Burgess, François Bissey

Disagree. Sure, we should start adding this to spkgs, and yes it is good that #11884 should have it changed since no one noticed it otherwise, but it is just too onerous to keep adding requirements like this when even someone pretty savvy about builds like François didn't notice this - particularly because the ECL package, like many other packages, didn't have it before! It's not like people are intentionally trying to remove checking of exit codes.

Like a lot of other things, if we ever want Sage to actually improve, we have to strike a balance between these kinds of things. In this case, under what circumstances would the exit code make a difference? Only if someone updates the spkg... which is being dealt with at #11884, at least I hope so.

Unless you are suggesting that we should immediately make blocker tickets for every spkg which has patches without checking the exit code of patch :) but given our testing regimen, doing it as we notice it seems just fine, especially as not everyone has the expertise to do this quickly.

comment:48 Changed 9 years ago by jdemeyer

  • Milestone sage-4.7.3 deleted

Milestone sage-4.7.3 deleted

comment:49 Changed 9 years ago by jdemeyer

  • Merged in changed from sage-4.7.3.alpha0 to sage-4.8.alpha0
  • Milestone set to sage-4.8

comment:50 follow-up: Changed 9 years ago by jdemeyer

Karl-Dieter: which tar program did you use to create the spkg? There are two strange things:

  1. When extracting with GNU tar, I get
    tar: Ignoring unknown extended header keyword `SCHILY.dev'
    tar: Ignoring unknown extended header keyword `SCHILY.ino'
    tar: Ignoring unknown extended header keyword `SCHILY.nlink'
    tar: Ignoring unknown extended header keyword `SCHILY.dev'
    tar: Ignoring unknown extended header keyword `SCHILY.ino'
    tar: Ignoring unknown extended header keyword `SCHILY.nlink'
    tar: Ignoring unknown extended header keyword `SCHILY.dev'
    tar: Ignoring unknown extended header keyword `SCHILY.ino'
    tar: Ignoring unknown extended header keyword `SCHILY.nlink'
    tar: Ignoring unknown extended header keyword `SCHILY.dev'
    tar: Ignoring unknown extended header keyword `SCHILY.ino'
    tar: Ignoring unknown extended header keyword `SCHILY.nlink'
    tar: Ignoring unknown extended header keyword `SCHILY.dev'
    tar: Ignoring unknown extended header keyword `SCHILY.ino'
    tar: Ignoring unknown extended header keyword `SCHILY.nlink'
    tar: Ignoring unknown extended header keyword `SCHILY.dev'
    tar: Ignoring unknown extended header keyword `SCHILY.ino'
    tar: Ignoring unknown extended header keyword `SCHILY.nlink'
    tar: Ignoring unknown extended header keyword `SCHILY.dev'
    tar: Ignoring unknown extended header keyword `SCHILY.ino'
    tar: Ignoring unknown extended header keyword `SCHILY.nlink'
    
  1. The entries in the tar file are sorted in a weird way, for example the contents of src/examples/ comes way later than the directory src/examples/. This has consequences for the modification time of the extracted directories. Adding the option --delay-directory-restore when extracting solves the issue.

I am not at all saying the spkg needs to be changed, I am mainly curious. And it also made me aware of the option --delay-directory-restore of GNU tar.

comment:51 in reply to: ↑ 50 ; follow-up: Changed 9 years ago by dimpase

Replying to jdemeyer:

Karl-Dieter: which tar program did you use to create the spkg? There are two strange things:

  1. When extracting with GNU tar, I get
    tar: Ignoring unknown extended header keyword `SCHILY.dev'
    

Jeroen, are you 100% sure you used GNU tar? Such things are known to appear when you run an old BSD tar (like one you have on old MacOSX) e.g.: http://ocdevel.com/blog/snow-leopard-tarball-uploading-issues

comment:52 in reply to: ↑ 51 Changed 9 years ago by jdemeyer

Replying to dimpase:

Such things are known to appear when you run an old BSD tar (like one you have on old MacOSX) e.g.: http://ocdevel.com/blog/snow-leopard-tarball-uploading-issues

Thanks for the link and it is exactly the issue I was talking about. I think you misunderstood my question: I was talking about extracting with GNU tar. So, presumably, Karl-Dieter used BSD tar to create the archive. This is not a big issue, just something that I was unaware of.

comment:53 follow-up: Changed 9 years ago by kcrisman

Is this a problem I'll need to deal with? As far as I know, I created this on a modern Mac, but it's still BSD:

%man tar
BSDTAR(1)                 BSD General Commands Manual                BSDTAR(1)

NAME
     tar -- manipulate tape archives

SYNOPSIS
     tar [bundled-flags <args>] [<file> | <pattern> ...]
     tar {-c} [options] [files | directories]
     tar {-r | -u} -f archive-file [options] [files | directories]
     tar {-t | -x} [options] [patterns]

DESCRIPTION
     tar creates and manipulates streaming archive files.  This implementation
     can extract from tar, pax, cpio, zip, jar, ar, and ISO 9660 cdrom images
     and can create tar, pax, cpio, ar, and shar archives.

It's a lot more tedious for me to make tars on sage.math. Presumably I'm not the only person to make spkgs on Mac, though, and I do use sage -pkg to do them - I only use tar to unpack things, in general.

comment:54 in reply to: ↑ 53 Changed 9 years ago by jdemeyer

Replying to kcrisman:

Is this a problem I'll need to deal with?

No, it's a problem I have to deal with :-) In all seriousness, it's not really a problem, I just need to be aware of this and use the --delay-directory-restore option to extract spkgs.

comment:55 follow-up: Changed 9 years ago by jdemeyer

  • Authors Dmitrii Pasechnik, Mike Hansen, Karl-Dieter Crisman deleted
  • Description modified (diff)
  • Merged in sage-4.8.alpha0 deleted
  • Milestone changed from sage-4.8 to sage-duplicate/invalid/wontfix
  • Resolution changed from fixed to duplicate
  • Reviewers changed from Karl-Dieter Crisman, Reg Burgess, François Bissey to Jeroen Demeyer

Spkg is gone, so this can't be merged anymore...

I moved the Authors/Reviewers? to #11884.

comment:56 in reply to: ↑ 55 ; follow-up: Changed 9 years ago by kcrisman

Replying to jdemeyer:

Spkg is gone, so this can't be merged anymore...

Well, it presumably still lives on in alpha0. That's why I deleted it! So it already was merged in an existing alpha, I don't see how this changes things.

comment:57 in reply to: ↑ 56 Changed 9 years ago by kcrisman

Replying to kcrisman:

Replying to jdemeyer:

Spkg is gone, so this can't be merged anymore...

Well, it presumably still lives on in alpha0. That's why I deleted it! So it already was merged in an existing alpha, I don't see how this changes things.

Plus, the fixes are in the new upstream used at #11884.

Anyway, I hope these comments clarify it FWIW.

Note: See TracTickets for help on using tickets.