Re: Cygwin Subprocesses on XEmacs
Volker - On Fri, Jan 30, 2015 at 10:51 AM, Dr. Volker Zell wrote: I downloaded the latest version 21.4.23 and tried to build it, but I consistently get: gcc -c -ggdb -O2 -pipe -Wimplicit-function-declaration -fdebug-prefix-map=/cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/build=/usr/src/debug/xemacs-21.4.22-2 -fdebug-prefix-map=/cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22=/usr/src/debug/xemacs-21.4.22-2 -Demacs -I. -DHAVE_CONFIG_H -Wno-sign-compare -fno-caller-saves dump-id.c gcc -ggdb -O2 -pipe -Wimplicit-function-declaration -fdebug-prefix-map=/cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/build=/usr/src/debug/xemacs-21.4.22-2 -fdebug-prefix-map=/cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22=/usr/src/debug/xemacs-21.4.22-2 -o xemacs abbrev.o alloc.o blocktype.o buffer.o bytecode.o callint.o callproc.o casefiddle.o casetab.o chartab.o cmdloop.o cmds.o console.o console-stream.o data.o device.o dired.o doc.o doprnt.o dynarr.o editfns.o elhash.o emacs.o eval.o events.o filelock.o ntplay.o dumper.o scrollbar-msw.o menubar-msw.o toolbar-msw.o dialog-msw.o console-msw.o device-msw.o event-msw.o frame-msw.o objects-msw.o select-msw.o redisplay-msw.o glyphs-msw.o gui-msw.o balloon_help.o balloon-x.o dragdrop.o eldap.o postgresql.o dgif_lib.o gif_io.o menubar.o scrollbar.o dialog.o toolbar.o menubar-x.o scrollbar-x.o dialog-x.o toolbar-x.o gui-x.o mule.o mule-ccl.o mule-charset.o file-coding.o input-method-xlib.o realpath.o getloadavg.o inline.o nas.o console-tty.o device-tty.o event-tty.o frame-tty.o objects-tty.o redisplay-tty.o cm.o terminfo.o event-unixoid.o database.o process-unix.o event-stream.o extents.o faces.o fileio.o filemode.o floatfns.o fns.o font-lock.o frame.o general.o glyphs.o glyphs-eimage.o glyphs-widget.o gui.o gutter.o hash.o imgproc.o indent.o insdel.o intl.o keymap.o line-number.o lread.o lstream.o macros.o marker.o md5.o minibuf.o objects.o opaque.o print.o process.o profile.o rangetab.o redisplay.o redisplay-output.o regex.o search.o select.o signal.o sound.o specifier.o strftime.o symbols.o syntax.o sysdep.o undo.o console-x.o device-x.o event-Xt.o frame-x.o glyphs-x.o objects-x.o redisplay-x.o select-x.o xgccache.o widget.o window.o win32.o xemacs_res.o lastfile.o gmalloc.o vm-limit.o EmacsFrame.o EmacsShell.o TopLevelEmacsShell.o TransientEmacsShell.o EmacsManager.o offix.o dump-id.o ../lwlib/liblw.a -laudio -lXaw3d -lXaw3d -ltiff -lpng -ljpeg -lz -lcompface -lXpm -lXmu -lXt -lXext -lX11 -lSM -lICE -ldb -lncurses -lintl -lpq -lldap -llber -lwinmm -lshell32 -lgdi32 -luser32 -lcomdlg32 -lcomctl32 -lkernel32 -lwinspool collect2: error: ld terminated with signal 11 [Segmentation fault], core dumped GNUmakefile:159: recipe for target 'xemacs' failed make[1]: *** [xemacs] Error 1 make[1]: Leaving directory '/cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/build/src' GNUmakefile:123: recipe for target 'src' failed make: *** [src] Error 2 [1;31m*** ERROR: [0;0m make failed After the ld core dump, when I delete the corrupted xemacs.exe from /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/build/src manually and restart the build with make from the /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/build directory again, the build actually succeeds and ld doesn't core dump anymore. I don't see this segfault. I am running the default version of gcc, and I assume you are, too. Perhaps you need to rebaseall? Your build path is ...xemacs-21.4.22... are you sure you're using 21.4.23 sources? Additionally I had to use an older version of texinfo (namely version 4.13) otherwise the build breaks when generating the .info files (I got the information to use an older version from Vin Shelton). Yes, the texinfo incompatibilities is one reason I want to EOL 21.4. An alternative approach for Cygwin would be to patch the .texi sources to work with newer texinfos. I then installed everything and with my current setup xemacs crashed as soon as font-locking is involved. The current 32 bit xemacs-21.4.22 version works fine with this setup. After googling around I found a workaround by setting (setq progress-feedback-use-echo-area t) in my .emacs. This error should be fixed in 21.4.23, there's a new configure.in/configure designed to prevent this. Again - are you sure you're using 21.4.23? So, the good news finally after 6 years !!! it seems I have a working xemacs on 32 bit which runs on cygwin 1.7.x. Of course I will need to do more testing. The bad news, an automatic build via cygport is currently not possible because: 1. cygport's compile stage bails out after the ld core dump 2. the current xemacs version needs an older version of texinfo (4.13) than we have currently in the distribution (5.2-3) Question: How shall I proceed ? - Vin
Re: [HEADSUP] Dropping libopenssl098 from distro
On 1/30/2015 8:25 AM, Ken Brown wrote:
On 1/30/2015 4:41 AM, Corinna Vinschen wrote:
On Jan 29 15:25, Ken Brown wrote:
I'm attaching the patches that I applied (on top of Reini's patches) in
order to make the build succeed. I also had to use libdb4.5 instead of
libdb4.8.
Is that ok? I mean, shouldn't a package always try to use the latest
version? What's the problem you're observing ? Maybe Volker can help
here?
The clisp-2.48 code uses some macros and structures that are defined in the
db4.5 headers but have changed or disappeared in db4.8. I'll see if I can
figure out how to update the code for db4.8.
OK, that wasn't so hard. I'm attaching the patch that I applied, in case Reini
or Volker has a chance to look at it. All 76 tests for the berkeley-db module
passed.
Ken
--- origsrc/clisp-2.48/modules/berkeley-db/bdb.c2009-06-27
04:13:33.0 -0400
+++ src/clisp-2.48/modules/berkeley-db/bdb.c2015-01-30 10:12:11.415894600
-0500
@@ -1039,9 +1039,9 @@ static object dbe_get_lk_conflicts (DB_E
FLAG_EXTRACTOR(dbe_get_flags_num,DB_ENV*)
DEFUNR(BDB:DBE-GET-OPTIONS, dbe optional what) {
object what = STACK_0;
- /* dbe may be NULL only for DB_XIDDATASIZE */
+ /* dbe may be NULL only for DB_GID_SIZE */
DB_ENV *dbe = (DB_ENV*)bdb_handle(STACK_1,`BDB::DBE`,
-eq(what,`:DB-XIDDATASIZE`)
+eq(what,`:DB-GID-SIZE`)
? BH_NIL_IS_NULL : BH_VALID);
what = STACK_0; skipSTACK(2);
restart_DBE_GET_OPTIONS:
@@ -1210,8 +1210,8 @@ DEFUNR(BDB:DBE-GET-OPTIONS, dbe optiona
VALUES1(dbe_get_errfile(dbe));
} else if (eq(what,`:MSGFILE`)) {
VALUES1(dbe_get_msgfile(dbe));
- } else if (eq(what,`:DB-XIDDATASIZE`)) {
-VALUES1(fixnum(DB_XIDDATASIZE));
+ } else if (eq(what,`:DB-GID-SIZE`)) {
+VALUES1(fixnum(DB_GID_SIZE));
} else if (eq(what,`:HOME`)) {
VALUES1(dbe_get_home_dir(dbe,true));
} else if (eq(what,`:OPEN`)) {
@@ -1235,10 +1235,10 @@ DEFUNR(BDB:DBE-GET-OPTIONS, dbe optiona
DEFUN(BDB:DB-CREATE, dbe key XA)
{ /* create database */
- u_int32_t flags = missingp(STACK_0) ? 0 : DB_XA_CREATE;
+ /* u_int32_t flags = missingp(STACK_0) ? 0 : DB_XA_CREATE; */
DB_ENV *dbe = (DB_ENV*)bdb_handle(STACK_1,`BDB::DBE`,BH_NIL_IS_NULL);
DB *db;
- SYSCALL(db_create,(db,dbe,flags));
+ SYSCALL(db_create,(db,dbe,0));
if (!dbe) { /* set error callback */
begin_system_call();
db-set_errcall(db,error_callback);
@@ -2706,13 +2706,13 @@ DEFUN(BDB:TXN-CHECKPOINT, dbe key KBYTE
}
/* return the pointer into the obj (which must be
- a (vector (unsigned-byte 8) DB_XIDDATASIZE))
+ a (vector (unsigned-byte 8) DB_GID_SIZE))
can trigger GC, the return value is invalidated by GC */
static u_int8_t* check_gid (gcv_object_t *obj_) {
uintL idx = 0;
object data_vector;
- *obj_ = check_byte_vector_len(*obj_,DB_XIDDATASIZE);
- data_vector = array_displace_check(*obj_,DB_XIDDATASIZE,idx);
+ *obj_ = check_byte_vector_len(*obj_,DB_GID_SIZE);
+ data_vector = array_displace_check(*obj_,DB_GID_SIZE,idx);
return TheSbvector(data_vector)-data+idx;
}
@@ -2724,12 +2724,12 @@ DEFUN(BDB:TXN-PREPARE, txn gid)
VALUES0; skipSTACK(2);
}
-/* allocate a (vector (unsigned-byte 8) DB_XIDDATASIZE) for this gid
+/* allocate a (vector (unsigned-byte 8) DB_GID_SIZE) for this gid
can trigger GC */
-static object gid_to_vector (u_int8_t gid[DB_XIDDATASIZE]) {
- object vec = allocate_bit_vector(Atype_8Bit,DB_XIDDATASIZE);
+static object gid_to_vector (u_int8_t gid[DB_GID_SIZE]) {
+ object vec = allocate_bit_vector(Atype_8Bit,DB_GID_SIZE);
begin_system_call();
- memcpy(TheSbvector(vec)-data,gid,DB_XIDDATASIZE);
+ memcpy(TheSbvector(vec)-data,gid,DB_GID_SIZE);
end_system_call();
return vec;
}
@@ -2742,7 +2742,7 @@ DEFUN(BDB:TXN-RECOVER, dbe key FIRST :N
u_int32_t tx_max;
DB_PREPLIST *preplist;
int status, ii;
- long retnum;
+ u_int32_t retnum;
SYSCALL(dbe-get_tx_max,(dbe,tx_max));
preplist = (DB_PREPLIST*)clisp_malloc(tx_max * sizeof(DB_PREPLIST));
begin_blocking_system_call();
@@ -2801,8 +2801,8 @@ DEFUN(BDB:TXN-STAT, dbe key STAT-CLEAR)
pushSTACK(uint32_to_I(txn_active-txnid));
pushSTACK(uint32_to_I(txn_active-parentid));
pushSTACK(make_lsn((txn_active-lsn)));
- pushSTACK(uint32_to_I(txn_active-xa_status));
- pushSTACK(gid_to_vector(txn_active-xid));
+ pushSTACK(uint32_to_I(txn_active-status));
+ pushSTACK(gid_to_vector(txn_active-gid));
funcall(`BDB::MKTXNACTIVE`,5); pushSTACK(value1);
}
value1 = vectorof(size); pushSTACK(value1);
--- origsrc/clisp-2.48/modules/berkeley-db/dbi.lisp 2008-12-31
11:26:09.0 -0500
+++ src/clisp-2.48/modules/berkeley-db/dbi.lisp 2015-01-30 10:53:59.548351500
-0500
@@ -252,7 +252,7 @@
(region_nowait 0 :type (unsigned-byte 32) :read-only t))
(defstruct (db-txn-active (:constructor mktxnactive
-
Re: Cygwin Subprocesses on XEmacs
Vin Shelton writes: I don't see this segfault. I am running the default version of gcc, and I assume you are, too. Perhaps you need to rebaseall? I'm using the latest gcc-4.9.2 Your build path is ...xemacs-21.4.22... are you sure you're using 21.4.23 sources? Yes...I copied from the wrong log file (that was the latest build from the hg repository I did before you released 21.4.23). But in the latest version I get the exact error. I then installed everything and with my current setup xemacs crashed as soon as font-locking is involved. The current 32 bit xemacs-21.4.22 version works fine with this setup. After googling around I found a workaround by setting (setq progress-feedback-use-echo-area t) in my .emacs. This error should be fixed in 21.4.23, there's a new configure.in/configure designed to prevent this. Again - are you sure you're using 21.4.23? Yes...my current xemacs just spits out XEmacs 21.4 (patch 23) Moral Majoritywhen using M-X: emacs-version - Vin Ciao Volker
Re: Cygwin Subprocesses on XEmacs
Vin Shelton writes: On Thu, Jan 29, 2015 at 4:39 AM, Corinna Vinschen wrote: On Jan 28 22:32, Vin Shelton wrote: I think I have verified this behavior - I restored the old sysdep.c module and moved the disconnect_controlling_terminal() call [which calls setsid()] from right after the fork() to just before the exec() call and M-x shell works on Cygwin as it always has on linux. Good news! So the XEmacs code is in a state now that Volker can start creating a Cygwin package? Yes, the 21.4 code in the hg repository builds and runs on Cygwin. I downloaded the latest version 21.4.23 and tried to build it, but I consistently get: gcc -c -ggdb -O2 -pipe -Wimplicit-function-declaration -fdebug-prefix-map=/cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/build=/usr/src/debug/xemacs-21.4.22-2 -fdebug-prefix-map=/cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22=/usr/src/debug/xemacs-21.4.22-2 -Demacs -I. -DHAVE_CONFIG_H -Wno-sign-compare -fno-caller-saves dump-id.c gcc -ggdb -O2 -pipe -Wimplicit-function-declaration -fdebug-prefix-map=/cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/build=/usr/src/debug/xemacs-21.4.22-2 -fdebug-prefix-map=/cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22=/usr/src/debug/xemacs-21.4.22-2 -o xemacs abbrev.o alloc.o blocktype.o buffer.o bytecode.o callint.o callproc.o casefiddle.o casetab.o chartab.o cmdloop.o cmds.o console.o console-stream.o data.o device.o dired.o doc.o doprnt.o dynarr.o editfns.o elhash.o emacs.o eval.o events.o filelock.o ntplay.o dumper.o scrollbar-msw.o menubar-msw.o toolbar-msw.o dialog-msw.o console-msw.o device-msw.o event-msw.o frame-msw.o objects-msw.o select-msw.o redisplay-msw.o glyphs-msw.o gui-msw.o balloon_help.o balloon-x.o dragdrop.o eldap.o postgresql.o dgif_lib.o gif_io.o menubar.o scrollbar.o dialog.o toolbar.o menubar-x.o scrollbar-x.o dialog-x.o toolbar-x.o gui-x.o mule.o mule-ccl.o mule-charset.o file-coding.o input-method-xlib.o realpath.o getloadavg.o inline.o nas.o console-tty.o device-tty.o event-tty.o frame-tty.o objects-tty.o redisplay-tty.o cm.o terminfo.o event-unixoid.o database.o process-unix.o event-stream.o extents.o faces.o fileio.o filemode.o floatfns.o fns.o font-lock.o frame.o general.o glyphs.o glyphs-eimage.o glyphs-widget.o gui.o gutter.o hash.o imgproc.o indent.o insdel.o intl.o keymap.o line-number.o lread.o lstream.o macros.o marker.o md5.o minibuf.o objects.o opaque.o print.o process.o profile.o rangetab.o redisplay.o redisplay-output.o regex.o search.o select.o signal.o sound.o specifier.o strftime.o symbols.o syntax.o sysdep.o undo.o console-x.o device-x.o event-Xt.o frame-x.o glyphs-x.o objects-x.o redisplay-x.o select-x.o xgccache.o widget.o window.o win32.o xemacs_res.o lastfile.o gmalloc.o vm-limit.o EmacsFrame.o EmacsShell.o TopLevelEmacsShell.o TransientEmacsShell.o EmacsManager.o offix.o dump-id.o ../lwlib/liblw.a -laudio -lXaw3d -lXaw3d -ltiff -lpng -ljpeg -lz -lcompface -lXpm -lXmu -lXt -lXext -lX11 -lSM -lICE -ldb -lncurses -lintl -lpq -lldap -llber -lwinmm -lshell32 -lgdi32 -luser32 -lcomdlg32 -lcomctl32 -lkernel32 -lwinspool collect2: error: ld terminated with signal 11 [Segmentation fault], core dumped GNUmakefile:159: recipe for target 'xemacs' failed make[1]: *** [xemacs] Error 1 make[1]: Leaving directory '/cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/build/src' GNUmakefile:123: recipe for target 'src' failed make: *** [src] Error 2 [1;31m*** ERROR:[0;0m make failed After the ld core dump, when I delete the corrupted xemacs.exe from /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/build/src manually and restart the build with make from the /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/build directory again, the build actually succeeds and ld doesn't core dump anymore. Additionally I had to use an older version of texinfo (namely version 4.13) otherwise the build breaks when generating the .info files (I got the information to use an older version from Vin Shelton). I then installed everything and with my current setup xemacs crashed as soon as font-locking is involved. The current 32 bit xemacs-21.4.22 version works fine with this setup. After googling around I found a workaround by setting (setq progress-feedback-use-echo-area t) in my .emacs. So, the good news finally after 6 years !!! it seems I have a working xemacs on 32 bit which runs on cygwin 1.7.x. Of course I will need to do more testing. The bad news, an automatic build via cygport is currently not possible because: 1. cygport's compile stage bails out after the ld core dump 2. the current xemacs version needs an older version of texinfo (4.13) than we have currently in the distribution (5.2-3) Question: How shall I proceed ? By the way, I'm off for a week. Regards, Vin Ciao Volker
Re: Setup patch to keep test version if test version installed
On 1/30/2015 8:13 PM, Achim Gratz wrote: Corinna Vinschen writes: Btw., when, do you think, is showtime for _autorebase 2.0? Sometime during the next week would be good, if not then another window would be two weeks later. From the responses so far I gathered that Marco doesn#t think he needs to do something for Octave and R, I will take care of Perl myself. That leaves PHP, Ruby and Python... so Yaakov and Jason need to tell us when things are ready on their side I'd think. Octave no, but R yes. I will upload the R_autorebase-001001-1.tar.xz together with the new 3.1.2 build as soon ready Regards, Achim. Regards Marco
Re: [HEADSUP] Dropping libopenssl098 from distro
On 1/30/2015 2:02 PM, Yaakov Selkowitz wrote: On Fri, 2015-01-30 at 11:40 -0500, Ken Brown wrote: On 1/30/2015 8:25 AM, Ken Brown wrote: On 1/30/2015 4:41 AM, Corinna Vinschen wrote: On Jan 29 15:25, Ken Brown wrote: I'm attaching the patches that I applied (on top of Reini's patches) in order to make the build succeed. I also had to use libdb4.5 instead of libdb4.8. Is that ok? I mean, shouldn't a package always try to use the latest version? What's the problem you're observing ? Maybe Volker can help here? The clisp-2.48 code uses some macros and structures that are defined in the db4.5 headers but have changed or disappeared in db4.8. I'll see if I can figure out how to update the code for db4.8. OK, that wasn't so hard. I'm attaching the patch that I applied, in case Reini or Volker has a chance to look at it. All 76 tests for the berkeley-db module passed. FYI, this is the patch Fedora uses for this issue: http://pkgs.fedoraproject.org/cgit/clisp.git/plain/clisp-db.patch That patch doesn't deal with the differences between db4.5 and db4.8 (e.g., DB_XIDDATASIZE was changed to DB_GID_SIZE, among other things). It must be for a different issue. Ken
Re: [ITP] ssh-pageant 1.4
On Tue, Jan 27, 2015 at 6:53 PM, Andrew Schulman schulman.and...@epa.gov wrote: Dear all I would like to package ssh-pageant and propose it for inclusion in Cygwin. The small tool acts like an ssh-agent, but instead of storing its own keys, it is connecting to the PuTTY Pageant tool. This way the very useful Pageant tool can be used from Cygwin and no separate ssh-agent is required. +1 Since this package is not in any Linux distro, I need five GTG's, right? So keep 'em coming :-) Michael
Re: [HEADSUP] Dropping libopenssl098 from distro
On Fri, 2015-01-30 at 11:40 -0500, Ken Brown wrote: On 1/30/2015 8:25 AM, Ken Brown wrote: On 1/30/2015 4:41 AM, Corinna Vinschen wrote: On Jan 29 15:25, Ken Brown wrote: I'm attaching the patches that I applied (on top of Reini's patches) in order to make the build succeed. I also had to use libdb4.5 instead of libdb4.8. Is that ok? I mean, shouldn't a package always try to use the latest version? What's the problem you're observing ? Maybe Volker can help here? The clisp-2.48 code uses some macros and structures that are defined in the db4.5 headers but have changed or disappeared in db4.8. I'll see if I can figure out how to update the code for db4.8. OK, that wasn't so hard. I'm attaching the patch that I applied, in case Reini or Volker has a chance to look at it. All 76 tests for the berkeley-db module passed. FYI, this is the patch Fedora uses for this issue: http://pkgs.fedoraproject.org/cgit/clisp.git/plain/clisp-db.patch Without looking at the code, I don't know which is more appropriate. -- Yaakov
Re: Setup patch to keep test version if test version installed
Corinna Vinschen writes: Btw., when, do you think, is showtime for _autorebase 2.0? Sometime during the next week would be good, if not then another window would be two weeks later. From the responses so far I gathered that Marco doesn#t think he needs to do something for Octave and R, I will take care of Perl myself. That leaves PHP, Ruby and Python... so Yaakov and Jason need to tell us when things are ready on their side I'd think. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves
Re: Setup patch to keep test version if test version installed
On 1/30/2015 11:11 PM, Marco Atzeri wrote: On 1/30/2015 8:13 PM, Achim Gratz wrote: Corinna Vinschen writes: Btw., when, do you think, is showtime for _autorebase 2.0? Octave no, but R yes. I will upload the R_autorebase-001001-1.tar.xz together with the new 3.1.2 build as soon ready R_autorebase is up Marco
Re: [HEADSUP] Dropping libopenssl098 from distro
Hi Ken, On Jan 29 15:25, Ken Brown wrote: On 1/23/2015 8:48 AM, Ken Brown wrote: My guess is correct. lisp.exe uses bit 31 (counting from the LSB) as a marker during garbage collection, and this is incompatible with Cygwin's use of high memory for the heap. I think I know how to fix this (by defining LINUX_NOEXEC_HEAPCODES in the Cygwin build), but I haven't finished testing it yet. I've now built clisp-2.48 with this change (32-bit only), and I've tested it as well as I can, given that I'm not a clisp user. The build passes all but a handful of about 12,000 tests, so I think it's probably OK. (None of the test failures involved crashes.) Sounds great to me (not being a clisp user myself). I'm attaching the patches that I applied (on top of Reini's patches) in order to make the build succeed. I also had to use libdb4.5 instead of libdb4.8. Is that ok? I mean, shouldn't a package always try to use the latest version? What's the problem you're observing ? Maybe Volker can help here? I just had a look and it turned out that the 64 bit release only has a single db version, 5.3, while the 32 bit version comes with 4.5 and 4.8 only. Volker??? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp0sMOQQyOBR.pgp Description: PGP signature
Re: Setup patch to keep test version if test version installed
On Jan 29 18:27, Achim Gratz wrote: Corinna Vinschen writes: Thank you for this! Well, I added it for entirely selfish reasons, so I'm not sure I deserve getting thanks :) I thanked you for the selfish reason that I got this crossed off my TODO list without any effort on my part, so we're even. ;-) Heh :) Btw., when, do you think, is showtime for _autorebase 2.0? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpqFXL2dqHff.pgp Description: PGP signature
Re: [HEADSUP] Dropping libopenssl098 from distro
Corinna Vinschen writes: I just had a look and it turned out that the 64 bit release only has a single db version, 5.3, while the 32 bit version comes with 4.5 and 4.8 only. Volker??? 5.3 for 64 bit was compiled by Yaakov I think, when I was absent. xemacs and db are the packages where I still have to catchup to compile/recompile for the latest 32/64bit releases. Unfortunately I will be on a business trip for one more week. Corinna Ciao Volker
Re: [HEADSUP] Dropping libopenssl098 from distro
On 1/30/2015 4:41 AM, Corinna Vinschen wrote: Hi Ken, On Jan 29 15:25, Ken Brown wrote: On 1/23/2015 8:48 AM, Ken Brown wrote: My guess is correct. lisp.exe uses bit 31 (counting from the LSB) as a marker during garbage collection, and this is incompatible with Cygwin's use of high memory for the heap. I think I know how to fix this (by defining LINUX_NOEXEC_HEAPCODES in the Cygwin build), but I haven't finished testing it yet. I've now built clisp-2.48 with this change (32-bit only), and I've tested it as well as I can, given that I'm not a clisp user. The build passes all but a handful of about 12,000 tests, so I think it's probably OK. (None of the test failures involved crashes.) Sounds great to me (not being a clisp user myself). I'm attaching the patches that I applied (on top of Reini's patches) in order to make the build succeed. I also had to use libdb4.5 instead of libdb4.8. Is that ok? I mean, shouldn't a package always try to use the latest version? What's the problem you're observing ? Maybe Volker can help here? The clisp-2.48 code uses some macros and structures that are defined in the db4.5 headers but have changed or disappeared in db4.8. I'll see if I can figure out how to update the code for db4.8. Ken
