Re: [HEADSUP] Dropping libopenssl098 from distro
On Apr 27 12:47, Peter A. Castro wrote: On Fri, 24 Apr 2015, Peter A. Castro wrote: Date: Fri, 24 Apr 2015 07:40:46 -0700 (PDT) From: Peter A. Castro Subject: Re: [HEADSUP] Dropping libopenssl098 from distro Ugh...resending since I forgot to remove the email addresses from the quoted header and expect that email to be bounce, but if not, my apologies in advance for a repeat message. :) (gotta find a Reply filter that removes email addresses :) On Mon, 20 Apr 2015, Peter A. Castro wrote: Date: Mon, 20 Apr 2015 14:40:40 -0700 (PDT) From: Peter A. Castro Subject: Re: [HEADSUP] Dropping libopenssl098 from distro On Thu, 2 Apr 2015, Corinna Vinschen wrote: Date: Thu, 2 Apr 2015 13:35:23 +0200 From: Corinna Vinschen Subject: Re: [HEADSUP] Dropping libopenssl098 from distro Greetings, again, Corinna, Just to keep you up to date, I've built newer zsh 32 64 and am testing both. I've built newer suite3270 32-bit, including tcl3270 (with the new tcl packages; had to do a little re-porting due to code changes) and am building 64-bit now. I'll upload all of these this saturday after which you can then finally remove libopenssl098. Again, sorry for the delay. It's been a busy year. :) Last update. :) New packages have been pushed as of last friday and annoucements sent. I believe there are nolonger any dependencies on libopenssl098 (at least from me :), so you should be clear to finally remove it. Thank you! Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpQsQFFT4PT1.pgp Description: PGP signature
Re: [HEADSUP] Dropping libopenssl098 from distro
On Fri, 24 Apr 2015, Peter A. Castro wrote: Date: Fri, 24 Apr 2015 07:40:46 -0700 (PDT) From: Peter A. Castro doc...@fruitbat.org To: cygwin-apps@cygwin.com Subject: Re: [HEADSUP] Dropping libopenssl098 from distro On Mon, 20 Apr 2015, Peter A. Castro wrote: Date: Mon, 20 Apr 2015 14:40:40 -0700 (PDT) From: Peter A. Castro Subject: Re: [HEADSUP] Dropping libopenssl098 from distro On Thu, 2 Apr 2015, Corinna Vinschen wrote: Date: Thu, 2 Apr 2015 13:35:23 +0200 From: Corinna Vinschen Subject: Re: [HEADSUP] Dropping libopenssl098 from distro Greetings, again, Corinna, Just to keep you up to date, I've built newer zsh 32 64 and am testing both. I've built newer suite3270 32-bit, including tcl3270 (with the new tcl packages; had to do a little re-porting due to code changes) and am building 64-bit now. I'll upload all of these this saturday after which you can then finally remove libopenssl098. Again, sorry for the delay. It's been a busy year. :) Last update. :) New packages have been pushed as of last friday and annoucements sent. I believe there are nolonger any dependencies on libopenssl098 (at least from me :), so you should be clear to finally remove it. Peter? It's another two weeks :} Sorry. it's been a very busy 6 months. Also, the machine I had access to disappeared a month ago and I've been scrambling to get another one. But, I now have a newish Win 7 64bit machine available and am doing the porting work for both suite3270 and zsh. Give me until the end of the week and then blast me again if I haven't gotten it done. This time for sure! Nothing up my sleeve -- Bullwinkle J. Moose. :) On Mar 19 22:19, Corinna Vinschen wrote: On Mar 19 22:09, Corinna Vinschen wrote: On Mar 19 13:19, Peter A. Castro wrote: On Thu, 19 Mar 2015, Corinna Vinschen wrote: Date: Thu, 19 Mar 2015 18:12:21 +0100 From: Corinna Vinschen Subject: Re: [HEADSUP] Dropping libopenssl098 from distro Peter? Ping? Oh Carp! I forgot about this! Sorry!! It's been a very busy two months for me. I'll see if I can complete my port soon. Again, Sorry! No worries. I just don't want to remove the libopenssl098 package, finally. Erm... hang on. I *do* want to remove the libopenssl098 package. Thanks, Corinna -- --= Peter A. Castro Email: doctor at fruitbat dot org / Peter dot Castro at oracle dot com Cats are just autistic Dogs -- Dr. Tony Attwood
Re: [HEADSUP] Dropping libopenssl098 from distro
On Apr 24 07:40, Peter A. Castro wrote: On Mon, 20 Apr 2015, Peter A. Castro wrote: Date: Mon, 20 Apr 2015 14:40:40 -0700 (PDT) From: Peter A. Castro Subject: Re: [HEADSUP] Dropping libopenssl098 from distro On Thu, 2 Apr 2015, Corinna Vinschen wrote: Date: Thu, 2 Apr 2015 13:35:23 +0200 From: Corinna Vinschen Subject: Re: [HEADSUP] Dropping libopenssl098 from distro Greetings, again, Corinna, Just to keep you up to date, I've built newer zsh 32 64 and am testing both. I've built newer suite3270 32-bit, including tcl3270 (with the new tcl packages; had to do a little re-porting due to code changes) and am building 64-bit now. I'll upload all of these this saturday after which you can then finally remove libopenssl098. Again, sorry for the delay. It's been a busy year. :) No worries. Thank you. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpajAfixpnI6.pgp Description: PGP signature
Re: [HEADSUP] Dropping libopenssl098 from distro
On Mon, 20 Apr 2015, Peter A. Castro wrote: Date: Mon, 20 Apr 2015 14:40:40 -0700 (PDT) From: Peter A. Castro Subject: Re: [HEADSUP] Dropping libopenssl098 from distro On Thu, 2 Apr 2015, Corinna Vinschen wrote: Date: Thu, 2 Apr 2015 13:35:23 +0200 From: Corinna Vinschen Subject: Re: [HEADSUP] Dropping libopenssl098 from distro Greetings, again, Corinna, Just to keep you up to date, I've built newer zsh 32 64 and am testing both. I've built newer suite3270 32-bit, including tcl3270 (with the new tcl packages; had to do a little re-porting due to code changes) and am building 64-bit now. I'll upload all of these this saturday after which you can then finally remove libopenssl098. Again, sorry for the delay. It's been a busy year. :) Peter? It's another two weeks :} Sorry. it's been a very busy 6 months. Also, the machine I had access to disappeared a month ago and I've been scrambling to get another one. But, I now have a newish Win 7 64bit machine available and am doing the porting work for both suite3270 and zsh. Give me until the end of the week and then blast me again if I haven't gotten it done. This time for sure! Nothing up my sleeve -- Bullwinkle J. Moose. :) On Mar 19 22:19, Corinna Vinschen wrote: On Mar 19 22:09, Corinna Vinschen wrote: On Mar 19 13:19, Peter A. Castro wrote: On Thu, 19 Mar 2015, Corinna Vinschen wrote: Date: Thu, 19 Mar 2015 18:12:21 +0100 From: Corinna Vinschen Subject: Re: [HEADSUP] Dropping libopenssl098 from distro Peter? Ping? Oh Carp! I forgot about this! Sorry!! It's been a very busy two months for me. I'll see if I can complete my port soon. Again, Sorry! No worries. I just don't want to remove the libopenssl098 package, finally. Erm... hang on. I *do* want to remove the libopenssl098 package. Thanks, Corinna -- --= Peter A. Castro Email: doctor at fruitbat dot org / Peter dot Castro at oracle dot com Cats are just autistic Dogs -- Dr. Tony Attwood
Re: [HEADSUP] Dropping libopenssl098 from distro
On Apr 20, 2015, at 3:40 PM, Peter A. Castro doc...@fruitbat.org wrote: the machine I had access to disappeared a month ago and I've been scrambling to get another one. VirtualBox and the Windows 10 Technical Preview are free, and they run Cygwin just fine. :)
Re: [HEADSUP] Dropping libopenssl098 from distro
On Thu, 2 Apr 2015, Corinna Vinschen wrote: Date: Thu, 2 Apr 2015 13:35:23 +0200 From: Corinna Vinschen Subject: Re: [HEADSUP] Dropping libopenssl098 from distro Peter? It's another two weeks :} Sorry. it's been a very busy 6 months. Also, the machine I had access to disappeared a month ago and I've been scrambling to get another one. But, I now have a newish Win 7 64bit machine available and am doing the porting work for both suite3270 and zsh. Give me until the end of the week and then blast me again if I haven't gotten it done. This time for sure! Nothing up my sleeve -- Bullwinkle J. Moose. :) On Mar 19 22:19, Corinna Vinschen wrote: On Mar 19 22:09, Corinna Vinschen wrote: On Mar 19 13:19, Peter A. Castro wrote: On Thu, 19 Mar 2015, Corinna Vinschen wrote: Date: Thu, 19 Mar 2015 18:12:21 +0100 From: Corinna Vinschen Subject: Re: [HEADSUP] Dropping libopenssl098 from distro Peter? Ping? Oh Carp! I forgot about this! Sorry!! It's been a very busy two months for me. I'll see if I can complete my port soon. Again, Sorry! No worries. I just don't want to remove the libopenssl098 package, finally. Erm... hang on. I *do* want to remove the libopenssl098 package. Thanks, Corinna -- --= Peter A. Castro Email: doctor at fruitbat dot org / Peter dot Castro at oracle dot com Cats are just autistic Dogs -- Dr. Tony Attwood
Re: [HEADSUP] Dropping libopenssl098 from distro
Peter? It's another two weeks :} On Mar 19 22:19, Corinna Vinschen wrote: On Mar 19 22:09, Corinna Vinschen wrote: On Mar 19 13:19, Peter A. Castro wrote: On Thu, 19 Mar 2015, Corinna Vinschen wrote: Date: Thu, 19 Mar 2015 18:12:21 +0100 From: Corinna Vinschen Subject: Re: [HEADSUP] Dropping libopenssl098 from distro Peter? Ping? Oh Carp! I forgot about this! Sorry!! It's been a very busy two months for me. I'll see if I can complete my port soon. Again, Sorry! No worries. I just don't want to remove the libopenssl098 package, finally. Erm... hang on. I *do* want to remove the libopenssl098 package. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp1iGxDSGeid.pgp Description: PGP signature
Re: [HEADSUP] Dropping libopenssl098 from distro
Peter? Ping? On Feb 2 10:16, Corinna Vinschen wrote: On Jan 31 13:32, Peter A. Castro wrote: On Mon, 26 Jan 2015, Corinna Vinschen wrote: Date: Mon, 26 Jan 2015 21:43:44 +0100 From: Corinna Vinschen Subject: Re: [HEADSUP] Dropping libopenssl098 from distro Just a quick update on the libopenssl098 frontier: On Jan 14 15:13, Corinna Vinschen wrote: it's really *really* overdue to remove the OpenSSL 0.98 DLLs from the 32 bit distro. Fortunately they were never in the 64 bit distro. The problem is that we still have packages requiring libopenssl098. These need rebuilding or removing. The following packages need simple rebuilding: suite3270 Peter A. Castro Peter, any progress? Still working on it. I'm hitting some porting issues while upgrading the package suite. Feel free to discuss them here. I'll have to update libopenssl098 to 0.9.8zf just for this one package. Any chance you could update soon? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgperRHwasNNl.pgp Description: PGP signature
Re: [HEADSUP] Dropping libopenssl098 from distro
On Thu, 19 Mar 2015, Corinna Vinschen wrote: Date: Thu, 19 Mar 2015 18:12:21 +0100 From: Corinna Vinschen Subject: Re: [HEADSUP] Dropping libopenssl098 from distro Peter? Ping? Oh Carp! I forgot about this! Sorry!! It's been a very busy two months for me. I'll see if I can complete my port soon. Again, Sorry! On Feb 2 10:16, Corinna Vinschen wrote: On Jan 31 13:32, Peter A. Castro wrote: On Mon, 26 Jan 2015, Corinna Vinschen wrote: Date: Mon, 26 Jan 2015 21:43:44 +0100 From: Corinna Vinschen Subject: Re: [HEADSUP] Dropping libopenssl098 from distro Just a quick update on the libopenssl098 frontier: On Jan 14 15:13, Corinna Vinschen wrote: it's really *really* overdue to remove the OpenSSL 0.98 DLLs from the 32 bit distro. Fortunately they were never in the 64 bit distro. The problem is that we still have packages requiring libopenssl098. These need rebuilding or removing. The following packages need simple rebuilding: suite3270 Peter A. Castro Peter, any progress? Still working on it. I'm hitting some porting issues while upgrading the package suite. Feel free to discuss them here. I'll have to update libopenssl098 to 0.9.8zf just for this one package. Any chance you could update soon? Thanks, Corinna -- --= Peter A. Castro Email: doctor at fruitbat dot org / Peter dot Castro at oracle dot com Cats are just autistic Dogs -- Dr. Tony Attwood
Re: [HEADSUP] Dropping libopenssl098 from distro
On Mar 19 22:09, Corinna Vinschen wrote: On Mar 19 13:19, Peter A. Castro wrote: On Thu, 19 Mar 2015, Corinna Vinschen wrote: Date: Thu, 19 Mar 2015 18:12:21 +0100 From: Corinna Vinschen Subject: Re: [HEADSUP] Dropping libopenssl098 from distro Peter? Ping? Oh Carp! I forgot about this! Sorry!! It's been a very busy two months for me. I'll see if I can complete my port soon. Again, Sorry! No worries. I just don't want to remove the libopenssl098 package, finally. Erm... hang on. I *do* want to remove the libopenssl098 package. :) Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgppzh9QT7_nX.pgp Description: PGP signature
Re: [HEADSUP] Dropping libopenssl098 from distro
On Mar 19 13:19, Peter A. Castro wrote: On Thu, 19 Mar 2015, Corinna Vinschen wrote: Date: Thu, 19 Mar 2015 18:12:21 +0100 From: Corinna Vinschen Subject: Re: [HEADSUP] Dropping libopenssl098 from distro Peter? Ping? Oh Carp! I forgot about this! Sorry!! It's been a very busy two months for me. I'll see if I can complete my port soon. Again, Sorry! No worries. I just don't want to remove the libopenssl098 package, finally. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgprnQANRgB0e.pgp Description: PGP signature
Re: [HEADSUP] Dropping libopenssl098 from distro [gcc bug]
On 2/3/2015 4:17 AM, Corinna Vinschen wrote: On Feb 2 10:46, Ken Brown wrote: I've now begun working on the 64-bit build. I found a few minor things I had to change, and the build was pretty far along, when I apparently hit a gcc bug: [...] Oh, that's too bad. I hope somebody from the gcc folks take a look. I've submitted the report: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64939 Ken
Re: [HEADSUP] Dropping libopenssl098 from distro [gcc bug]
On Feb 2 10:46, Ken Brown wrote: On 1/30/2015 11:40 AM, 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. I've now begun working on the 64-bit build. I found a few minor things I had to change, and the build was pretty far along, when I apparently hit a gcc bug: gcc -I/home/kbrown/src/cygclisp/clisp-2.48-5.x86_64/build/gllib -ggdb -O2 -pipe -Wimplicit-function-declaration -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -Wno-format-nonliteral -O -falign-functions=4 -DUNICODE -I. -I$(/home/kbrown/src/cygclisp/clisp-2.48-5.x86_64/build/clisp -K boot -B /home/kbrown/src/cygclisp/clisp-2.48-5.x86_64/build -N /home/kbrown/src/cygclisp/clisp-2.48-5.x86_64/build/locale -E UTF-8 -Epathname 1:1 -Emisc 1:1 -norc -q -b)/linkkit -c regexi.m.c -o regexi.o regexi.c: In function ‘C_subr_regexp_regexp_compile’: regexi.c:56:1: error: unrecognizable insn: } ^ (insn 348 347 349 41 (set (reg/f:DI 259) (plus:DI (symbol_ref:DI (module__regexp__subr_tab) [flags 0x2] var_decl 0x6fffbfad360 module__regexp__subr_tab) (reg:DI 260))) regexi.c:54 -1 (expr_list:REG_EQUAL (const:DI (plus:DI (symbol_ref:DI (module__regexp__subr_tab) [flags 0x2] var_decl 0x6fffbfad360 module__regexp__subr_tab) (const_int 281474976710768 [0x10070]))) (nil))) regexi.c:56:1: internal compiler error: in extract_insn, at recog.c:2154 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Oh, that's too bad. I hope somebody from the gcc folks take a look. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp1XFEaAhZUv.pgp Description: PGP signature
Re: [HEADSUP] Dropping libopenssl098 from distro [gcc bug]
On 1/30/2015 11:40 AM, 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. I've now begun working on the 64-bit build. I found a few minor things I had to change, and the build was pretty far along, when I apparently hit a gcc bug: gcc -I/home/kbrown/src/cygclisp/clisp-2.48-5.x86_64/build/gllib -ggdb -O2 -pipe -Wimplicit-function-declaration -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -Wno-format-nonliteral -O -falign-functions=4 -DUNICODE -I. -I$(/home/kbrown/src/cygclisp/clisp-2.48-5.x86_64/build/clisp -K boot -B /home/kbrown/src/cygclisp/clisp-2.48-5.x86_64/build -N /home/kbrown/src/cygclisp/clisp-2.48-5.x86_64/build/locale -E UTF-8 -Epathname 1:1 -Emisc 1:1 -norc -q -b)/linkkit -c regexi.m.c -o regexi.o regexi.c: In function ‘C_subr_regexp_regexp_compile’: regexi.c:56:1: error: unrecognizable insn: } ^ (insn 348 347 349 41 (set (reg/f:DI 259) (plus:DI (symbol_ref:DI (module__regexp__subr_tab) [flags 0x2] var_decl 0x6fffbfad360 module__regexp__subr_tab) (reg:DI 260))) regexi.c:54 -1 (expr_list:REG_EQUAL (const:DI (plus:DI (symbol_ref:DI (module__regexp__subr_tab) [flags 0x2] var_decl 0x6fffbfad360 module__regexp__subr_tab) (const_int 281474976710768 [0x10070]))) (nil))) regexi.c:56:1: internal compiler error: in extract_insn, at recog.c:2154 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. This was initially with gcc-4.9.2-1, but the same thing happens with gcc-4.9.2-2 and gcc-4.8.3-2. I'll poke around a little and see if I can find a problem in the source file, but I may have to just report the gcc bug and put this aside until it's resolved. Ken
Re: [HEADSUP] Dropping libopenssl098 from distro
On Jan 31 13:32, Peter A. Castro wrote: On Mon, 26 Jan 2015, Corinna Vinschen wrote: Date: Mon, 26 Jan 2015 21:43:44 +0100 From: Corinna Vinschen Subject: Re: [HEADSUP] Dropping libopenssl098 from distro Just a quick update on the libopenssl098 frontier: On Jan 14 15:13, Corinna Vinschen wrote: it's really *really* overdue to remove the OpenSSL 0.98 DLLs from the 32 bit distro. Fortunately they were never in the 64 bit distro. The problem is that we still have packages requiring libopenssl098. These need rebuilding or removing. The following packages need simple rebuilding: suite3270 Peter A. Castro Peter, any progress? Still working on it. I'm hitting some porting issues while upgrading the package suite. Feel free to discuss them here. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpzpsL6rVhQY.pgp Description: PGP signature
Re: [HEADSUP] Dropping libopenssl098 from distro
On Mon, 26 Jan 2015, Corinna Vinschen wrote: Date: Mon, 26 Jan 2015 21:43:44 +0100 From: Corinna Vinschen Subject: Re: [HEADSUP] Dropping libopenssl098 from distro Just a quick update on the libopenssl098 frontier: On Jan 14 15:13, Corinna Vinschen wrote: it's really *really* overdue to remove the OpenSSL 0.98 DLLs from the 32 bit distro. Fortunately they were never in the 64 bit distro. The problem is that we still have packages requiring libopenssl098. These need rebuilding or removing. The following packages need simple rebuilding: suite3270 Peter A. Castro Peter, any progress? Still working on it. I'm hitting some porting issues while upgrading the package suite. The following packages have dependecies of their own, so they can't go away until the dependent packages have been rebuilt: libarchive2 Yaakov Selkowitz required by: gvfsYaakov Selkowitz libgxps2Yaakov Selkowitz gvfs and libgxps2 should be rebuilt to link against libarchive13. This needs the GNOME 3.14 update which will take some time. libpq Marco Atzeri required by: clisp Ken Brown xemacs Dr. Volker Zell These are in the works. libsasl2David Rothenberger required by: libopenldap2_3_0 Both of these packages can be removed automatically when clisp and xemacs are rebuilt. So the situation is grave, but not hopeless. Corinna -- --= Peter A. Castro Email: doctor at fruitbat dot org / Peter dot Castro at oracle dot com Cats are just autistic Dogs -- Dr. Tony Attwood
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: [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: [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: [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: [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
Re: [HEADSUP] Dropping libopenssl098 from distro
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.)
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.
Reini, if you're still lurking, maybe you could take a look at the patches.
Ken
--- origsrc/clisp-2.48/src/unix.d 2009-06-17 10:26:40.0 -0400
+++ src/clisp-2.48/src/unix.d 2015-01-26 12:11:27.111212000 -0500
@@ -716,7 +716,10 @@ extern int wait2 (PID_T pid); /* see uni
/* Interpretation of FILETIME structure: */
#ifdef UNIX_CYGWIN32
#define WIN32_LEAN_AND_MEAN
+ #pragma push_macro (Handle)
+ #undef Handle
#include windows.h
+ #pragma pop_macro (Handle)
#undef WIN32
extern long time_t_from_filetime (const FILETIME * ptr);
extern void time_t_to_filetime (time_t time_in, FILETIME * out);
--- origsrc/clisp-2.48/src/lispbibl.d 2009-07-28 09:58:03.0 -0400
+++ src/clisp-2.48/src/lispbibl.d 2015-01-26 12:14:01.822061000 -0500
@@ -2603,7 +2603,7 @@ Long-Float, Ratio and Complex (only if S
malloc results (and hence also of shared libraries) are randomized;
only the code address is fixed around 0x1C00 and the stack address
is around 0xCF00. In this case, we also use LINUX_NOEXEC_HEAPCODES. */
-#if (defined(I80386) defined(UNIX_LINUX)) || (defined(I80386)
defined(UNIX_OPENBSD) defined(ADDRESS_RANGE_RANDOMIZED))
+#if (defined(I80386) defined(UNIX_LINUX)) || (defined(I80386)
defined(UNIX_OPENBSD) defined(ADDRESS_RANGE_RANDOMIZED)) || (defined(I80386)
defined(UNIX_CYGWIN32))
#define LINUX_NOEXEC_HEAPCODES
#else
#define STANDARD_HEAPCODES
--- origsrc/clisp-2.48/modules/syscalls/calls.c 2009-07-22 21:12:31.0
-0400
+++ src/clisp-2.48/modules/syscalls/calls.c 2015-01-26 12:28:34.091951900
-0500
@@ -3302,6 +3302,7 @@ DEFUN(POSIX::DUPLICATE-HANDLE, old opti
#if defined(WIN32_NATIVE) || defined(UNIX_CYGWIN32)
#include shlobj.h
+#include shlguid.h
DEFCHECKER(check_file_attributes, type=DWORD, reverse=uint32_to_I, \
default=, prefix=FILE_ATTRIBUTE, bitmasks=both, \
ARCHIVE COMPRESSED :DEVICE :DIRECTORY ENCRYPTED HIDDEN :NORMAL \
--- origsrc/clisp-2.48/modules/syscalls/configure 2009-07-28
12:33:13.0 -0400
+++ src/clisp-2.48/modules/syscalls/configure 2015-01-26 12:09:16.528743100
-0500
@@ -4085,7 +4085,7 @@ fi
done
if test $ac_cv_header_shlobj_h = yes ; then
- LIBS=${LIBS}' -luser32 -lole32 -loleaut32 -luuid';
+ LIBS=${LIBS}' -luser32 -lole32 -loleaut32 -L/usr/lib/w32api -luuid';
fi
# The cast to long int works around a bug in the HP C Compiler
# version HP92453-01 B.11.11.23709.GP, which incorrectly rejects
Re: [HEADSUP] Dropping libopenssl098 from distro
Just a quick update on the libopenssl098 frontier: On Jan 14 15:13, Corinna Vinschen wrote: it's really *really* overdue to remove the OpenSSL 0.98 DLLs from the 32 bit distro. Fortunately they were never in the 64 bit distro. The problem is that we still have packages requiring libopenssl098. These need rebuilding or removing. The following packages need simple rebuilding: suite3270 Peter A. Castro Peter, any progress? The following packages have dependecies of their own, so they can't go away until the dependent packages have been rebuilt: libarchive2 Yaakov Selkowitz required by: gvfsYaakov Selkowitz libgxps2Yaakov Selkowitz gvfs and libgxps2 should be rebuilt to link against libarchive13. This needs the GNOME 3.14 update which will take some time. libpq Marco Atzeri required by: clisp Ken Brown xemacs Dr. Volker Zell These are in the works. libsasl2David Rothenberger required by: libopenldap2_3_0 Both of these packages can be removed automatically when clisp and xemacs are rebuilt. So the situation is grave, but not hopeless. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpp9KipVZmwA.pgp Description: PGP signature
Re: [HEADSUP] Dropping libopenssl098 from distro
On 01/14/2015 03:19 PM, Ken Brown wrote: On 1/14/2015 12:46 PM, Achim Gratz wrote: Corinna Vinschen writes: Clisp is not yet ported to 64bit and it has problems under 32bit as well (temporary file generation) that also affect Maxima from ports. If it's a problem with the Cygwin DLL, it would be nice to get a bug report and, preferredly, an STC, so we have a chance to fix this. AFAIK it's the same problem that produced the same symptoms in sqlite: using a non-Cygwin API. So no, I don't think the Cygwin DLL is to blame. Apart from that, I was only talking about the 32 bitr version anyway. It requires the wrong libopenssl and needs a simple rebuild for now. One of the things holding a port off is libsigsegv, IIRC. This is a bit annoying. Libsigsegv should be optional, not required. I have no idea whether that's possible for clisp. It is. There's a configure option --ignore-absence-of-libsigsegv. But there are more serious problems, affecting both the 32-bit and 64-bit versions. (So even just rebuilding clisp for 32-bit Cygwin will take some work.) The problem is that lisp.exe, which is built and used in the course of trying to build clisp.exe, crashes with a SEGV shortly after it's started. My reason for looking at this was that clisp is needed for building xindy, an optional component of TeX Live. I did successfully build clisp in the 32-bit case four years ago, but I can't any more. My guess (untested) is that this is because the location of the heap has changed since then, and maybe the source code makes unwarranted assumptions about memory layout. It's a shame that Reini isn't available to help with this. 64bit is not yet possible, yes. on 32bit, just use 2.48, which should work ok. but the build system is tricky. 2.49 never really worked. I've tried a few times to fix modules support. Most of my fixes are upstream, but the last released version was not fixable anymore. A gnulib problem.
Re: [HEADSUP] Dropping libopenssl098 from distro
On Jan 23 15:45, Andrew Schulman wrote: I, for one, welcome our new clisp overlord! ALL HAIL THE CLISP OVERLORD YMMD, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp9Zl8MXnfxf.pgp Description: PGP signature
Re: [HEADSUP] Dropping libopenssl098 from distro
On Jan 23 17:43, Ken Brown wrote: On 1/23/2015 3:09 PM, Corinna Vinschen wrote: Hi Ken, On Jan 23 08:48, 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. Given that by default *all* addresses used for 64 bit Cygwin processes are beyond the 2GB border, it's kind of tricky to use bit 31 for anything. But even then, the same code would fail on 32 bit Windows as well, if it's running under WOW64 or a 32 bit kernel started with the /3GB flag (or it's successor). In both cases Cygwin would happily use the addresses beyond 0x8000 for the heap. So, from that I conclude that using bit 31 for any dubious reason is inherently broken. I hope that the LINUX_NOEXEC_HEAPCODES stuff works, and if so, it should be used for the 32 bit build as well. Sorry, I should have been more clear. I was only talking about the 32-bit build. I haven't yet seriously tried the 64-bit build. Oh, ok. I'd like to know Reini's intentions before investing any more time in this. BTW, I am *not* qualified to take over as clisp maintainer. I've never used clisp, and I know nothing about it other than the tiny bit I've learned from debugging the crash I mentioned above. Well, it seems you're now stuck with it. slashdot I, for one, welcome our new clisp overlord! /slashdot Thanks a lot. I'll see if I can at least get version 3.48 or 3.49 built on both platforms. But in view of what Reini said about it being broken upstream, I don't think I'll try to go further. Whoopee! You know, I was just making fun, but that's really good news. If you need help to analyze problems on 64 bit, or if you have fun to look why the newer versions won't work, feel free to discuss the problems here. Maybe it's something we can solve together. Thanks a million, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpNjoacFPdsG.pgp Description: PGP signature
Re: [HEADSUP] Dropping libopenssl098 from distro
Dear Volker, Ken and Corinna, On Fri, Jan 23, 2015 at 10:43 AM, Dr. Volker Zell wrote: Ken Brown writes: On 1/23/2015 5:57 AM, Dr. Volker Zell wrote: 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 /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/emacs.c In file included from /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/emacs.c:184:0: /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/syswindows.h:74:16: error: expected ';', ',' or ')' before 'int' #define Status int ^ In file included from /usr/include/w32api/rpc.h:74:0, from /usr/include/w32api/objbase.h:7, from /usr/include/w32api/ole2.h:17, from /usr/include/w32api/shlobj.h:85, from /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/syswindows.h:77, from /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/emacs.c:184: /usr/include/w32api/rpcdce.h:210:51: error: unknown type name 'RPC_OBJECT_INQ_FN' RPCRTAPI RPC_STATUS RPC_ENTRY RpcObjectSetInqFn(RPC_OBJECT_INQ_FN *InquiryFn); I think the problem is that Status is used in /usr/include/w32api/rpcdce.h, and this conflicts with #define Status int. I ran into a similar problem when trying to build clisp. Any simple fix/workaround for this ? Thanks for pointing this out. It dawned on me yesterday that the reason I didn't see these problems is because I don't build with X support on Cygwin. Once I configured in X support, I saw these errors and a few others. It took me awhile to work out the right changes to make, but I have checked changes into the XEmacs 21.4 mercurial repository that enable XEmacs 21.4 to build under Cygwin with X support. One problem remains - Xaw3d support does not work, so I removed that from the configure line. The problem I found was that XEmacs seemed to be expecting version 8 of Xaw3d, but Cygwin supplies version 7. I still plan to release 21.4.23 in the near future, but I would recommend making an updated XEmacs 21.4 kit before that point. Regards, Vin Shelton
Re: [HEADSUP] Dropping libopenssl098 from distro
Hi Ken, On Jan 23 08:48, Ken Brown wrote: On 1/14/2015 4:19 PM, Ken Brown wrote: It is. There's a configure option --ignore-absence-of-libsigsegv. But there are more serious problems, affecting both the 32-bit and 64-bit versions. (So even just rebuilding clisp for 32-bit Cygwin will take some work.) The problem is that lisp.exe, which is built and used in the course of trying to build clisp.exe, crashes with a SEGV shortly after it's started. My reason for looking at this was that clisp is needed for building xindy, an optional component of TeX Live. I did successfully build clisp in the 32-bit case four years ago, but I can't any more. My guess (untested) is that this is because the location of the heap has changed since then, and maybe the source code makes unwarranted assumptions about memory layout. 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. Given that by default *all* addresses used for 64 bit Cygwin processes are beyond the 2GB border, it's kind of tricky to use bit 31 for anything. But even then, the same code would fail on 32 bit Windows as well, if it's running under WOW64 or a 32 bit kernel started with the /3GB flag (or it's successor). In both cases Cygwin would happily use the addresses beyond 0x8000 for the heap. So, from that I conclude that using bit 31 for any dubious reason is inherently broken. I hope that the LINUX_NOEXEC_HEAPCODES stuff works, and if so, it should be used for the 32 bit build as well. I'd like to know Reini's intentions before investing any more time in this. BTW, I am *not* qualified to take over as clisp maintainer. I've never used clisp, and I know nothing about it other than the tiny bit I've learned from debugging the crash I mentioned above. Well, it seems you're now stuck with it. slashdot I, for one, welcome our new clisp overlord! /slashdot *Duck* Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpJ780dfNWjr.pgp Description: PGP signature
Re: [HEADSUP] Dropping libopenssl098 from distro
I, for one, welcome our new clisp overlord! ALL HAIL THE CLISP OVERLORD
Re: [HEADSUP] Dropping libopenssl098 from distro
On 1/23/2015 3:09 PM, Corinna Vinschen wrote: Hi Ken, On Jan 23 08:48, Ken Brown wrote: On 1/14/2015 4:19 PM, Ken Brown wrote: It is. There's a configure option --ignore-absence-of-libsigsegv. But there are more serious problems, affecting both the 32-bit and 64-bit versions. (So even just rebuilding clisp for 32-bit Cygwin will take some work.) The problem is that lisp.exe, which is built and used in the course of trying to build clisp.exe, crashes with a SEGV shortly after it's started. My reason for looking at this was that clisp is needed for building xindy, an optional component of TeX Live. I did successfully build clisp in the 32-bit case four years ago, but I can't any more. My guess (untested) is that this is because the location of the heap has changed since then, and maybe the source code makes unwarranted assumptions about memory layout. 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. Given that by default *all* addresses used for 64 bit Cygwin processes are beyond the 2GB border, it's kind of tricky to use bit 31 for anything. But even then, the same code would fail on 32 bit Windows as well, if it's running under WOW64 or a 32 bit kernel started with the /3GB flag (or it's successor). In both cases Cygwin would happily use the addresses beyond 0x8000 for the heap. So, from that I conclude that using bit 31 for any dubious reason is inherently broken. I hope that the LINUX_NOEXEC_HEAPCODES stuff works, and if so, it should be used for the 32 bit build as well. Sorry, I should have been more clear. I was only talking about the 32-bit build. I haven't yet seriously tried the 64-bit build. I'd like to know Reini's intentions before investing any more time in this. BTW, I am *not* qualified to take over as clisp maintainer. I've never used clisp, and I know nothing about it other than the tiny bit I've learned from debugging the crash I mentioned above. Well, it seems you're now stuck with it. slashdot I, for one, welcome our new clisp overlord! /slashdot Thanks a lot. I'll see if I can at least get version 3.48 or 3.49 built on both platforms. But in view of what Reini said about it being broken upstream, I don't think I'll try to go further. Ken
Re: [HEADSUP] Dropping libopenssl098 from distro
On 1/23/2015 5:57 AM, Dr. Volker Zell wrote: 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 /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/emacs.c In file included from /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/emacs.c:184:0: /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/syswindows.h:74:16: error: expected ';', ',' or ')' before 'int' #define Status int ^ In file included from /usr/include/w32api/rpc.h:74:0, from /usr/include/w32api/objbase.h:7, from /usr/include/w32api/ole2.h:17, from /usr/include/w32api/shlobj.h:85, from /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/syswindows.h:77, from /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/emacs.c:184: /usr/include/w32api/rpcdce.h:210:51: error: unknown type name 'RPC_OBJECT_INQ_FN' RPCRTAPI RPC_STATUS RPC_ENTRY RpcObjectSetInqFn(RPC_OBJECT_INQ_FN *InquiryFn); I think the problem is that Status is used in /usr/include/w32api/rpcdce.h, and this conflicts with #define Status int. I ran into a similar problem when trying to build clisp. Ken
Re: [HEADSUP] Dropping libopenssl098 from distro
On 1/14/2015 4:19 PM, Ken Brown wrote: On 1/14/2015 12:46 PM, Achim Gratz wrote: Corinna Vinschen writes: Clisp is not yet ported to 64bit and it has problems under 32bit as well (temporary file generation) that also affect Maxima from ports. If it's a problem with the Cygwin DLL, it would be nice to get a bug report and, preferredly, an STC, so we have a chance to fix this. AFAIK it's the same problem that produced the same symptoms in sqlite: using a non-Cygwin API. So no, I don't think the Cygwin DLL is to blame. Apart from that, I was only talking about the 32 bitr version anyway. It requires the wrong libopenssl and needs a simple rebuild for now. One of the things holding a port off is libsigsegv, IIRC. This is a bit annoying. Libsigsegv should be optional, not required. I have no idea whether that's possible for clisp. It is. There's a configure option --ignore-absence-of-libsigsegv. But there are more serious problems, affecting both the 32-bit and 64-bit versions. (So even just rebuilding clisp for 32-bit Cygwin will take some work.) The problem is that lisp.exe, which is built and used in the course of trying to build clisp.exe, crashes with a SEGV shortly after it's started. My reason for looking at this was that clisp is needed for building xindy, an optional component of TeX Live. I did successfully build clisp in the 32-bit case four years ago, but I can't any more. My guess (untested) is that this is because the location of the heap has changed since then, and maybe the source code makes unwarranted assumptions about memory layout. 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'd like to know Reini's intentions before investing any more time in this. BTW, I am *not* qualified to take over as clisp maintainer. I've never used clisp, and I know nothing about it other than the tiny bit I've learned from debugging the crash I mentioned above. Ken
Re: [HEADSUP] Dropping libopenssl098 from distro
Volker Zell writes: Hi I'm on business, no access to the logs...I will come back to this on friday. Here we are Ciao Volker Vin Shelton writes: Volker - I can build XEmacs on 32-bit Cygwin. What doesn't work for you? 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 /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/emacs.c In file included from /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/emacs.c:184:0: /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/syswindows.h:74:16: error: expected ';', ',' or ')' before 'int' #define Status int ^ In file included from /usr/include/w32api/rpc.h:74:0, from /usr/include/w32api/objbase.h:7, from /usr/include/w32api/ole2.h:17, from /usr/include/w32api/shlobj.h:85, from /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/syswindows.h:77, from /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/emacs.c:184: /usr/include/w32api/rpcdce.h:210:51: error: unknown type name 'RPC_OBJECT_INQ_FN' RPCRTAPI RPC_STATUS RPC_ENTRY RpcObjectSetInqFn(RPC_OBJECT_INQ_FN *InquiryFn); ^ In file included from /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/emacs.c:184:0: /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/syswindows.h:74:16: error: expected ';', ',' or ')' before 'int' #define Status int ^ In file included from /usr/include/w32api/rpc.h:74:0, from /usr/include/w32api/objbase.h:7, from /usr/include/w32api/ole2.h:17, from /usr/include/w32api/shlobj.h:85, from /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/syswindows.h:77, from /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/emacs.c:184: /usr/include/w32api/rpcdce.h:473:112: error: unknown type name 'RPC_AUTH_KEY_RETRIEVAL_FN' RPCRTAPI RPC_STATUS RPC_ENTRY RpcServerRegisterAuthInfoA(RPC_CSTR ServerPrincName,unsigned __LONG32 AuthnSvc,RPC_AUTH_KEY_RETRIEVAL_FN GetKeyFn,void *Arg); ^ /usr/include/w32api/rpcdce.h:474:112: error: unknown type name 'RPC_AUTH_KEY_RETRIEVAL_FN' RPCRTAPI RPC_STATUS RPC_ENTRY RpcServerRegisterAuthInfoW(RPC_WSTR ServerPrincName,unsigned __LONG32 AuthnSvc,RPC_AUTH_KEY_RETRIEVAL_FN GetKeyFn,void *Arg); ^ In file included from /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/emacs.c:184:0: /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/syswindows.h:74:16: error: expected ';', ',' or ')' before 'int' #define Status int ^ /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/syswindows.h:74:16: error: expected ';', ',' or ')' before 'int' #define Status int ^ /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/syswindows.h:74:16: error: expected ';', ',' or ')' before 'int' #define Status int ^ /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/syswindows.h:74:16: error: expected ';', ',' or ')' before 'int' #define Status int ^ /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/syswindows.h:74:16: error: expected ';', ',' or ')' before 'int' #define Status int ^ In file included from /usr/include/w32api/rpc.h:74:0, from /usr/include/w32api/objbase.h:7, from /usr/include/w32api/ole2.h:17, from /usr/include/w32api/shlobj.h:85, from /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/syswindows.h:77, from /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/emacs.c:184: /usr/include/w32api/rpcdce.h:555:59: error: unknown type name 'RPC_MGMT_AUTHORIZATION_FN' RPCRTAPI RPC_STATUS RPC_ENTRY RpcMgmtSetAuthorizationFn(RPC_MGMT_AUTHORIZATION_FN AuthorizationFn); ^ In file included from /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/emacs.c:184:0:
Re: [HEADSUP] Dropping libopenssl098 from distro
Hi, Volker - Vin wrote: I can build XEmacs on 32-bit Cygwin. What doesn't work for you? Volker wrote: Here we are A few thoughts: 1. You need to use the most recent XEmacs sources from mercurial. 2. You must have an old version of libpng installed, because 21.4.22 won't compile with the newer libpng (some structure members are hidden). 3. You will also need to add: #define stricmp strcasecmp to src/s/cygwin32.h 4. I will review the contents of xemacs-21.4.22-1.src.patch and promote at least your developer info and the above stricmp hack to the mercurial repo. 5. I have promised to release 21.4.23, so I will do that shortly after #4 above. - Vin
Re: [HEADSUP] Dropping libopenssl098 from distro
Vin Shelton writes: Hi, Volker - Vin wrote: I can build XEmacs on 32-bit Cygwin. What doesn't work for you? Volker wrote: Here we are A few thoughts: 1. You need to use the most recent XEmacs sources from mercurial. OK 2. You must have an old version of libpng installed, because 21.4.22 won't compile with the newer libpng (some structure members are hidden). I had a patch for this..see the xemacs.cygport file. 3. You will also need to add: #define stricmp strcasecmp to src/s/cygwin32.h In the current source we have ? 4. I will review the contents of xemacs-21.4.22-1.src.patch and promote at least your developer info and the above stricmp hack to the mercurial repo. Ah...ok 5. I have promised to release 21.4.23, so I will do that shortly after #4 above. Cool...thanks. I'll wait for that before going on. - Vin Ciao Volker
Re: [HEADSUP] Dropping libopenssl098 from distro
On Jan 23 16:43, Dr. Volker Zell wrote: Ken Brown writes: On 1/23/2015 5:57 AM, Dr. Volker Zell wrote: 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 /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/emacs.c In file included from /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/emacs.c:184:0: /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/syswindows.h:74:16: error: expected ';', ',' or ')' before 'int' #define Status int ^ In file included from /usr/include/w32api/rpc.h:74:0, from /usr/include/w32api/objbase.h:7, from /usr/include/w32api/ole2.h:17, from /usr/include/w32api/shlobj.h:85, from /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/syswindows.h:77, from /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22/src/emacs.c:184: /usr/include/w32api/rpcdce.h:210:51: error: unknown type name 'RPC_OBJECT_INQ_FN' RPCRTAPI RPC_STATUS RPC_ENTRY RpcObjectSetInqFn(RPC_OBJECT_INQ_FN *InquiryFn); I think the problem is that Status is used in /usr/include/w32api/rpcdce.h, and this conflicts with #define Status int. I ran into a similar problem when trying to build clisp. Any simple fix/workaround for this ? It's a bug in the header, because it's polluting the namespace with unnecessary usage of Status as parameter names in prototypes. The header should use __status__ or drop them entirely. What you could try is either one of - Change the order of the header files, so that the windows headers are included before the private header defining Status. - Or, prior to including the Windows headers, push the macro and undefine it, after including the windows headers, pop the macro: #pragma push_macro (Status) #undef Status #include windows.h #pragma pop_macro (Status) - Or, you could not include windce.h at all if you don't need any of it: #define __RPCDCE_H__ #include windows.h ... Apart from that, the header should be fixed in Mingw-w64. HTH, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp3KvBQGHGzV.pgp Description: PGP signature
Re: [HEADSUP] Dropping libopenssl098 from distro
Hi I'm on business, no access to the logs...I will come back to this on friday. Ciao Volker Vin Shelton writes: Volker - I can build XEmacs on 32-bit Cygwin. What doesn't work for you? Thanks, Vin Shelton On Thu, Jan 15, 2015 at 6:27 AM, Dr. Volker Zell dr.volker.z...@oracle.com wrote: David Stacey writes: On 14/01/15 14:13, Corinna Vinschen wrote: The following packages have dependecies of their own, so they can't go away until the dependent packages have been rebuilt: libpqMarco Atzeri required by: xemacs Dr. Volker Zell Some time ago, there was a problem rebuilding xemacs [1]. Is this still an issue? It used to compile but was not usable because of broken subprocess support. Now it doesn't even compile :-( Dave. Ciao Volker -- DR. VOLKER ZELL | Principal Training Consultant | +49 211 74839 414 Oracle University Oracle Deutschland GmbH | Hamborner Str. 51 | 40472 Düsseldorf ORACLE Deutschland GmbH, Hauptverwaltung: Riesstraße 25, D-80992 München Geschäftsführer: Jürgen Kunz, Registergericht: Amtsgericht München, HRB 82775
Re: [GOLDSTAR] Re: [HEADSUP] Dropping libopenssl098 from distro [pure-ftpd done]
On Jan 16 09:08, Marco Atzeri wrote: On 1/15/2015 2:03 PM, Marco Atzeri wrote: On 1/14/2015 3:13 PM, Corinna Vinschen wrote: Hi folks, it's really *really* overdue to remove the OpenSSL 0.98 DLLs from the 32 bit distro. Fortunately they were never in the 64 bit distro. pure-ftpdKostya Altukhov I will look on it Regards Marco rebuilt and uploaded as 1.0.29-2 the 32 bit version. I will look later to upgrade it and the 64 bit version. It will take some time as Kostya made substantial patches to handle quota and root. Thanks, I think this is worth a goldstar. Andrew, do your worst. Awarded! http://cygwin.com/goldstars/#MA
Re: [HEADSUP] Dropping libopenssl098 from distro [pure-ftpd done]
On 1/15/2015 2:03 PM, Marco Atzeri wrote: On 1/14/2015 3:13 PM, Corinna Vinschen wrote: Hi folks, it's really *really* overdue to remove the OpenSSL 0.98 DLLs from the 32 bit distro. Fortunately they were never in the 64 bit distro. pure-ftpdKostya Altukhov I will look on it Regards Marco rebuilt and uploaded as 1.0.29-2 the 32 bit version. I will look later to upgrade it and the 64 bit version. It will take some time as Kostya made substantial patches to handle quota and root. Regards Marco
[GOLDSTAR] Re: [HEADSUP] Dropping libopenssl098 from distro [pure-ftpd done]
On Jan 16 09:08, Marco Atzeri wrote: On 1/15/2015 2:03 PM, Marco Atzeri wrote: On 1/14/2015 3:13 PM, Corinna Vinschen wrote: Hi folks, it's really *really* overdue to remove the OpenSSL 0.98 DLLs from the 32 bit distro. Fortunately they were never in the 64 bit distro. pure-ftpdKostya Altukhov I will look on it Regards Marco rebuilt and uploaded as 1.0.29-2 the 32 bit version. I will look later to upgrade it and the 64 bit version. It will take some time as Kostya made substantial patches to handle quota and root. Thanks, I think this is worth a goldstar. Andrew, do your worst. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpAX_QLKzVyh.pgp Description: PGP signature
Re: [HEADSUP] Dropping libopenssl098 from distro
On Wed, 14 Jan 2015, Corinna Vinschen wrote: Date: Wed, 14 Jan 2015 15:13:44 +0100 From: Corinna Vinschen corinna-cyg...@cygwin.com Reply-To: cygwin-apps@cygwin.com To: cygwin-apps@cygwin.com Cc: Jari Aalto jari.aa...@cante.net, Kostya Altukhov kacygwinl...@gmail.com, Peter A. Castro doc...@fruitbat.org, Yaakov Selkowitz yselkow...@cygwin.com, Marco Atzeri marco.atz...@gmail.com, Dr. Volker Zell dr.volker.z...@oracle.com, David Rothenberger daver...@acm.org, Reini Urban rur...@x-ray.at Subject: [HEADSUP] Dropping libopenssl098 from distro Hi folks, it's really *really* overdue to remove the OpenSSL 0.98 DLLs from the 32 bit distro. Fortunately they were never in the 64 bit distro. The problem is that we still have packages requiring libopenssl098. These need rebuilding or removing. The following packages need simple rebuilding: suite3270 Peter A. Castro I'm looking into this. Actually, I need to upgrade the packages to newer versions so will get that done too. Thanks, Corinna -- --= Peter A. Castro Email: doctor at fruitbat dot org / Peter dot Castro at oracle dot com Cats are just autistic Dogs -- Dr. Tony Attwood
Re: [HEADSUP] Dropping libopenssl098 from distro
On Wed, 14 Jan 2015, Corinna Vinschen wrote: Hi folks, it's really *really* overdue to remove the OpenSSL 0.98 DLLs from the 32 bit distro. Fortunately they were never in the 64 bit distro. The problem is that we still have packages requiring libopenssl098. These need rebuilding or removing. The following packages need simple rebuilding: [snip] suite3270 Peter A. Castro I'm looking into this. Actually, I need to upgrade the packages to newer versions so will get that done too. Thanks, Corinna -- --= Peter A. Castro Email: doctor at fruitbat dot org / Peter dot Castro at oracle dot com Cats are just autistic Dogs -- Dr. Tony Attwood
Re: [HEADSUP] Dropping libopenssl098 from distro
David Stacey writes: On 14/01/15 14:13, Corinna Vinschen wrote: The following packages have dependecies of their own, so they can't go away until the dependent packages have been rebuilt: libpqMarco Atzeri required by: xemacs Dr. Volker Zell Some time ago, there was a problem rebuilding xemacs [1]. Is this still an issue? It used to compile but was not usable because of broken subprocess support. Now it doesn't even compile :-( Dave. Ciao Volker
Re: [HEADSUP] Dropping libopenssl098 from distro
Volker - I can build XEmacs on 32-bit Cygwin. What doesn't work for you? Thanks, Vin Shelton On Thu, Jan 15, 2015 at 6:27 AM, Dr. Volker Zell dr.volker.z...@oracle.com wrote: David Stacey writes: On 14/01/15 14:13, Corinna Vinschen wrote: The following packages have dependecies of their own, so they can't go away until the dependent packages have been rebuilt: libpqMarco Atzeri required by: xemacs Dr. Volker Zell Some time ago, there was a problem rebuilding xemacs [1]. Is this still an issue? It used to compile but was not usable because of broken subprocess support. Now it doesn't even compile :-( Dave. Ciao Volker
Re: [HEADSUP] Dropping libopenssl098 from distro
On 1/15/2015 1:31 PM, Vin Shelton wrote: It used to compile but was not usable because of broken subprocess support. Now it doesn't even compile :-( Ciao Volker Volker - I can build XEmacs on 32-bit Cygwin. What doesn't work for you? Thanks, Vin Shelton Question: 0) does it work ? 1) configure parameters ? 2) have you tried a 64 build also ?
Re: [HEADSUP] Dropping libopenssl098 from distro
On Jan 15 13:50, Marco Atzeri wrote: On 1/15/2015 1:31 PM, Vin Shelton wrote: It used to compile but was not usable because of broken subprocess support. Now it doesn't even compile :-( Ciao Volker Volker - I can build XEmacs on 32-bit Cygwin. What doesn't work for you? Thanks, Vin Shelton Question: 0) does it work ? 1) configure parameters ? 2) have you tried a 64 build also ? It's nice to get more packages into the 64 bit distro, but the issue here is to get rid of libopenssl098 in the first place. If xemacs can be built (and runs) on 32 bit while linked against libopenssl100 would be a good deal already :) Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpWH1IwfWn1e.pgp Description: PGP signature
Re: [HEADSUP] Dropping libopenssl098 from distro
On 1/14/2015 3:13 PM, Corinna Vinschen wrote: Hi folks, it's really *really* overdue to remove the OpenSSL 0.98 DLLs from the 32 bit distro. Fortunately they were never in the 64 bit distro. pure-ftpdKostya Altukhov I will look on it Regards Marco
Re: [HEADSUP] Dropping libopenssl098 from distro
On 1/15/2015 1:57 PM, Corinna Vinschen wrote: On Jan 15 13:50, Marco Atzeri wrote: On 1/15/2015 1:31 PM, Vin Shelton wrote: It used to compile but was not usable because of broken subprocess support. Now it doesn't even compile :-( Ciao Volker Volker - I can build XEmacs on 32-bit Cygwin. What doesn't work for you? Thanks, Vin Shelton Question: 0) does it work ? 1) configure parameters ? 2) have you tried a 64 build also ? It's nice to get more packages into the 64 bit distro, but the issue here is to get rid of libopenssl098 in the first place. If xemacs can be built (and runs) on 32 bit while linked against libopenssl100 would be a good deal already :) Thanks, Corinna of course. 0 and 1 are for that. 2 is a potential plus ;-)
Re: [HEADSUP] Dropping libopenssl098 from distro
On Jan 15 14:03, Marco Atzeri wrote: On 1/14/2015 3:13 PM, Corinna Vinschen wrote: Hi folks, it's really *really* overdue to remove the OpenSSL 0.98 DLLs from the 32 bit distro. Fortunately they were never in the 64 bit distro. pure-ftpd Kostya Altukhov I will look on it Thanks a lot! Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpE6iMwqt7HS.pgp Description: PGP signature
Re: [HEADSUP] Dropping libopenssl098 from distro
Marco/Volker et al -
On Thu, Jan 15, 2015 at 7:50 AM, Marco Atzeri marco.atz...@gmail.com wrote:
On 1/15/2015 1:31 PM, Vin Shelton wrote:
It used to compile but was not usable because of broken subprocess
support. Now it doesn't even compile :-(
Ciao
Volker
Volker -
I can build XEmacs on 32-bit Cygwin. What doesn't work for you?
Thanks,
Vin Shelton
Question:
0) does it work ?
Yes. I am the XEmacs stable (21.4) build maintainer and make the
native Windows setup kits (both 21.4 and 21.5) for XEmacs, but I don't
use Windows very much these days.
1) configure parameters ?
Well, that's why I asked Volker what problems he had - it's easier to
solve problems when you have a description of them.
Here is the Installation file from my most recent cygwin build of XEmacs 21.5:
uname -a: CYGWIN_NT-5.1 legolas-xp3 1.7.33-2(0.280/5/3) 2014-11-13
15:45 i686 Cygwin
../../src/xemacs-21.5-2015-01-10-mule/configure
'--prefix=/usr/local/xemacs-21.5-2015-01-10-mule' '--enable-mule'
'--without-xim' '--enable-bignum=gmp' '--with-dialogs'
'--enable-pdump' '--with-sound=native' '--with-widgets' '--without-x'
'--with-dragndrop' '--with-cflags= -Os -malign-double -pipe
-ffast-math' '--with-default-eol-detection'
'--with-infopath=/usr/local/info'
'--with-package-path=/XEmacs/site-packages::/XEmacs/xemacs-packages'
'--with-site-prefix=' '--without-tls' 'CC=gcc' 'CFLAGS=-Os
-malign-double -pipe -ffast-math'
XEmacs 21.5-b34 kale configured for `i686-pc-cygwin'.
Compilation Environment and Installation Defaults:
Source code location: /usr/local/src/xemacs-21.5-2015-01-10-mule
Installation prefix: /usr/local/xemacs-21.5-2015-01-10-mule
Operating system description file: `s/cygwin32.h'
Machine description file: `m/intel386.h'
Compiler version: gcc (GCC) 4.9.2
- GCC specs file:specs.
- Compiler command: gcc -I/usr/include/noX
-I/usr/include/noX -Wall -Wno-switch -Wundef -Wsign-compare
-Wno-char-subscripts -Wpacked -Wpointer-arith -Wshadow
-Wmissing-declarations -Wmissing-prototypes -Wstrict-prototypes
-Wdeclaration-after-statement -Wunused-parameter -g -Os
-malign-double -pipe -ffast-math
libc version:
Relocating allocator for buffers: no
GNU version of malloc: yes
Package Search (a 'root' contains '{xemacs,mule,site}-packages'):
User package roots:~/.xemacs
System package roots: /usr/local/xemacs-21.5-2015-01-10-mule/share/xemacs
WARNING: /usr/local/xemacs-21.5-2015-01-10-mule/share/xemacs was
specified, but doesn't exist.
WARNING: XEmacs functionality will be noticably limited until
WARNING: some packages are installed.
Window System:
Compiling in support for the Microsoft window system.
Using MS-Windows menubars.
Using MS-Windows scrollbars.
Using MS-Windows dialog boxes.
Using MS-Windows native widgets.
Compiling in support for Drag'n'Drop (EXPERIMENTAL).
- Drag'n'Drop prototype: msw.
TTY:
Images:
Compiling in support for XPM images.
Compiling in support for PNG images.
Compiling in support for JPEG images.
Sound:
Compiling in support for sound (native).
Databases:
Internationalization:
Compiling in support for Mule (multi-lingual Emacs).
Mail:
Compiling in support for POP mail retrieval.
Network:
Inhibiting IPv6 canonicalization at startup.
Other Features:
Compiling in support for dynamic shared object modules.
Compiling in support for more number types using the GNU MP library.
Using the new GC mark algorithms (KKCC).
WARNING: -
WARNING: The new algorithms are experimental. They are enabled by
WARNING: default for this release. Use `--disable-kkcc' to
WARNING: turn it off.
WARNING: -
Using the new portable dumper.
Dumping into executable.
Compiling in support for extra debugging code.
Compiling in support for runtime error checking.
WARNING: -
WARNING: XEmacs will run noticeably more slowly as a result.
WARNING: Error checking is on by default for XEmacs beta releases.
WARNING: -
2) have you tried a 64 build also ?
No, but based on feedback from the xemacs-beta mailing list, I do not
believe that 64-bit mode currently builds.
Regards,
Vin
Re: [HEADSUP] Dropping libopenssl098 from distro
Hi Vin, Hi Volker, On Jan 15 09:12, Vin Shelton wrote: Marco/Volker et al - [...] On Thu, Jan 15, 2015 at 7:50 AM, Marco Atzeri ... wrote: Question: 0) does it work ? [...] 2) have you tried a 64 build also ? No, but based on feedback from the xemacs-beta mailing list, I do not believe that 64-bit mode currently builds. Do you have any idea what the problem might be? It would be very interesting to know if the problems from your feedback was pre Cygwin-1.7.33 or with Cygwin 1.7.33, especially due to the changes in internal exception handling in Cygwin. This might be a likely culprit for problems. Another culprit could be the difference in the Windows (LLP64) vs. the Cygwin (LP64) data model, as outlined in https://cygwin.com/faq/faq.html#faq.programming.64bitporting and subsequent FAQ entries, especially given the native Win32 GUI mode of xemacs. If you're interested in getting xemacs running on 64 bit Cygwin, feel free to use the cygwin-apps mailing list for communication and don't hesitate to ping me if you think the Cygwin DLL itself has a problem. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp1a5TaNkPy9.pgp Description: PGP signature
Re: [HEADSUP] Dropping libopenssl098 from distro (DONE: ctorrent suck)
2015-01-14 16:13 Corinna Vinschen corinna-cygwin-rDBXBDvO6BXQT0dZR+AlfA(at)public.gmane.org: | | | it's really *really* overdue to remove the OpenSSL 0.98 DLLs from | the 32 bit distro. | | ctorrentJari Aalto | suckJari Aalto Done. Rebuilt and uploaded. Jari pgpNWtFsFUQDW.pgp Description: PGP signature
Re: [HEADSUP] Dropping libopenssl098 from distro
On 1/14/2015 12:46 PM, Achim Gratz wrote: Corinna Vinschen writes: Clisp is not yet ported to 64bit and it has problems under 32bit as well (temporary file generation) that also affect Maxima from ports. If it's a problem with the Cygwin DLL, it would be nice to get a bug report and, preferredly, an STC, so we have a chance to fix this. AFAIK it's the same problem that produced the same symptoms in sqlite: using a non-Cygwin API. So no, I don't think the Cygwin DLL is to blame. Apart from that, I was only talking about the 32 bitr version anyway. It requires the wrong libopenssl and needs a simple rebuild for now. One of the things holding a port off is libsigsegv, IIRC. This is a bit annoying. Libsigsegv should be optional, not required. I have no idea whether that's possible for clisp. It is. There's a configure option --ignore-absence-of-libsigsegv. But there are more serious problems, affecting both the 32-bit and 64-bit versions. (So even just rebuilding clisp for 32-bit Cygwin will take some work.) The problem is that lisp.exe, which is built and used in the course of trying to build clisp.exe, crashes with a SEGV shortly after it's started. My reason for looking at this was that clisp is needed for building xindy, an optional component of TeX Live. I did successfully build clisp in the 32-bit case four years ago, but I can't any more. My guess (untested) is that this is because the location of the heap has changed since then, and maybe the source code makes unwarranted assumptions about memory layout. It's a shame that Reini isn't available to help with this. Ken
Re: [HEADSUP] Dropping libopenssl098 from distro
On 14/01/15 14:13, Corinna Vinschen wrote: The following packages have dependecies of their own, so they can't go away until the dependent packages have been rebuilt: libpqMarco Atzeri required by: xemacs Dr. Volker Zell Some time ago, there was a problem rebuilding xemacs [1]. Is this still an issue? Dave. [1] - https://cygwin.com/ml/cygwin-apps/2013-08/msg00248.html
[HEADSUP] Dropping libopenssl098 from distro
Hi folks, it's really *really* overdue to remove the OpenSSL 0.98 DLLs from the 32 bit distro. Fortunately they were never in the 64 bit distro. The problem is that we still have packages requiring libopenssl098. These need rebuilding or removing. The following packages need simple rebuilding: ctorrent Jari Aalto suck Jari Aalto pure-ftpd Kostya Altukhov suite3270 Peter A. Castro The following packages are unused and should just go away: libcurl3 Yaakov Selkowitz libneon25 Dr. Volker Zell libneon26 Dr. Volker Zell libpq3Marco Atzeri The following packages have dependecies of their own, so they can't go away until the dependent packages have been rebuilt: libarchive2 Yaakov Selkowitz required by: gvfsYaakov Selkowitz libgxps2Yaakov Selkowitz gvfs and libgxps2 should be rebuilt to link against libarchive13. libpq Marco Atzeri required by: clisp Reini Urban libsasl2-sqlDavid Rothenberger xemacs Dr. Volker Zell clisp and xemacs need rebuilding against libpq5. libsasl2-sql is old and unused and can go away. Given that Kostya Altukhov and Reini Urban seem to be AWOL, how shall we manage their packages ideally? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpgAImpFiZDD.pgp Description: PGP signature
Re: [HEADSUP] Dropping libopenssl098 from distro
On Jan 14 18:15, Achim Gratz wrote: Corinna Vinschen writes: clisp and xemacs need rebuilding against libpq5. libsasl2-sql is old and unused and can go away. Clisp is not yet ported to 64bit and it has problems under 32bit as well (temporary file generation) that also affect Maxima from ports. If it's a problem with the Cygwin DLL, it would be nice to get a bug report and, preferredly, an STC, so we have a chance to fix this. Apart from that, I was only talking about the 32 bitr version anyway. It requires the wrong libopenssl and needs a simple rebuild for now. ONe of the things holding a port off is libsigsegv, IIRC. This is a bit annoying. Libsigsegv should be optional, not required. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpImwylonXZ5.pgp Description: PGP signature
Re: [HEADSUP] Dropping libopenssl098 from distro
Corinna Vinschen writes: Clisp is not yet ported to 64bit and it has problems under 32bit as well (temporary file generation) that also affect Maxima from ports. If it's a problem with the Cygwin DLL, it would be nice to get a bug report and, preferredly, an STC, so we have a chance to fix this. AFAIK it's the same problem that produced the same symptoms in sqlite: using a non-Cygwin API. So no, I don't think the Cygwin DLL is to blame. Apart from that, I was only talking about the 32 bitr version anyway. It requires the wrong libopenssl and needs a simple rebuild for now. One of the things holding a port off is libsigsegv, IIRC. This is a bit annoying. Libsigsegv should be optional, not required. I have no idea whether that's possible for clisp. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra
Re: [HEADSUP] Dropping libopenssl098 from distro
Corinna Vinschen writes: clisp and xemacs need rebuilding against libpq5. libsasl2-sql is old and unused and can go away. Clisp is not yet ported to 64bit and it has problems under 32bit as well (temporary file generation) that also affect Maxima from ports. ONe of the things holding a port off is libsigsegv, IIRC. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada
Re: [HEADSUP] Dropping libopenssl098 from distro
On Wed, 2015-01-14 at 15:13 +0100, Corinna Vinschen wrote: it's really *really* overdue to remove the OpenSSL 0.98 DLLs from the 32 bit distro. Fortunately they were never in the 64 bit distro. The problem is that we still have packages requiring libopenssl098. These need rebuilding or removing. [snip] The following packages are unused and should just go away: libcurl3Yaakov Selkowitz libneon25 Dr. Volker Zell libneon26 Dr. Volker Zell libpq3 Marco Atzeri Ack. The following packages have dependecies of their own, so they can't go away until the dependent packages have been rebuilt: libarchive2 Yaakov Selkowitz required by: gvfsYaakov Selkowitz libgxps2Yaakov Selkowitz gvfs and libgxps2 should be rebuilt to link against libarchive13. These will be fixed with the GNOME 3.14 upgrade, currently being built. -- Yaakov
