clisp-devel — closed list for developers and testers

nightly build problems

[<don...@is...>]

This first occurred on Aug 20.
It's only on one of two builds on the old linux machine.
The new linux machine builds are both working.

Cron Daemon writes:
 > /etc/cron.daily/clisp-ap5:
 > 
 > + su -c /home/clisp-build/clisp-ap5 clisp-build
 > + cd /home/clisp-build/hg/clisp/
 > + date
 > Sat Aug 20 04:02:08 PDT 2011
 > + hg pull -u
 > + tail tran-cvs-up
 > pulling from http://clisp.hg.sourceforge.net:8000/hgroot/clisp/clisp
 > searching for changes
 > adding changesets
 > adding manifests
 > adding file changes
 > added 3 changesets with 21 changes to 17 files
 > 17 files updated, 0 files merged, 0 files removed, 0 files unresolved
 > + date
 > Sat Aug 20 04:02:18 PDT 2011
 > + ulimit -s 16384
 > + rm -rf build-dir
 > + date
 > Sat Aug 20 04:02:20 PDT 2011
 > + ./configure --with-debug --with-module=rawsock build-dir
 > + tail tran-configure-build-dir
 ... 
this is the non-mt build, which works
Now the mt build, which on this machine is a little non-standard:
 > + cd /home/clisp-build/hg/clisp/
 > + rm -rf /home/clisp-build/clisp/.hg/data/build-mt-no
 > + date
 > Sat Aug 20 04:10:20 PDT 2011
 > + ./configure --with-debug --with-threads=POSIX_THREADS --with-module=rawsock --with-dynamic-modules=no build-mt-no
 > + tail tran-configure-build-mt-no
The output of configure goes to that file, so this is the end of that output:

 >       TOS = "unix"
 > BUILD_AUX = config.guess config.rpath config.sub depcomp
 > make: `config.lisp' is up to date.
 > 
 > To continue building CLISP, the following commands are recommended
 >   (cf. unix/INSTALL step 4 ff):
 >     cd build-mt-no
 >     vi config.lisp
 >     make
 >     make check
 > + date
 > Sat Aug 20 04:10:33 PDT 2011
 > + cd build-mt-no
 > + make
 > + tail transcript
Similarly, the output of make goes to that file so below is the end
of output for make:

 > ;; Loaded file /home/clisp-build/hg/clisp/build-mt-no/gray.fas
 > ;; Loading file /home/clisp-build/hg/clisp/build-mt-no/fill-out.fas ...
 > ;; Loaded file /home/clisp-build/hg/clisp/build-mt-no/fill-out.fas
 > ;; Loading file /home/clisp-build/hg/clisp/build-mt-no/disassem.fas ...
 > ;; Loaded file /home/clisp-build/hg/clisp/build-mt-no/disassem.fas
 > ;; Loading file /home/clisp-build/hg/clisp/build-mt-no/condition.fas ...
 > *** - Internal error: statement in file "../src/error.d", line 588 has been reached!!
 > Please see <http://clisp.org/impnotes/faq.html#faq-bugs> for bug reporting instructions.
 > Bye.
 > make: *** [interpreted.mem] Error 1
 > + date
 > Sat Aug 20 04:11:26 PDT 2011

So that's the immediate problem.

While I'm at it, let me mention that I still do the same nightly build
without the --with-dynamic-modules=no
and it (as always) ends like this:
 > + cd build-mt
 > + make
 > + tail transcript
 > 958240 ;
 > 107624 ;
 > 1 ;
 > 145336 ;
 > 40002
 > base/lisp.run -B . -M base/lispinit.mem -norc -q -i i18n/i18n -i syscalls/posix -i regexp/regexp -i readline/readline -x (saveinitmem "base/lispinit.mem")
 > STACK size: 98206 [0xf24f00 0xec5088]
 > ./clisp-link: line 97: 26901 Segmentation fault      "$@"
 > ./clisp-link: failed in /home/clisp-build/hg/clisp/build-mt
 > make: *** [base] Error 1
 > + date
 > Sat Aug 20 04:20:19 PDT 2011

So if you have any ideas how to fix that, I'd still be interested.

i18n

[Sam S. <sd...@gn...>]

Bruno,
on a CentOS system I see
$ ./clisp -E utf-8 -q -norc -L french -x '(sys::text "Bye.")'
"� bient��t!"
on a Ubuntu system I see
$ ./clisp -E utf-8 -q -norc -L french -x '(sys::text "Bye.")'
"Bye."
How do I debug this?

-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 11.0.60900031
http://palestinefacts.org http://memri.org http://iris.org.il http://dhimmi.com
http://truepeace.org http://pmw.org.il http://jihadwatch.org
WHO ATE MY BREAKFAST PANTS?

clisp-cvs Digest, Vol 63, Issue 10

[<cli...@li...>]

Send clisp-cvs mailing list submissions to
	cli...@li...

To subscribe or unsubscribe via the World Wide Web, visit
	https://lists.sourceforge.net/lists/listinfo/clisp-cvs
or, via email, send a message with subject or body 'help' to
	cli...@li...

You can reach the person managing the list at
	cli...@li...

When replying, please edit your Subject line so it is more specific
than "Re: Contents of clisp-cvs digest..."


CLISP CVS commits for today

Today's Topics:

   1. clisp: (convert_error_code): add a cast for g++
      (cli...@li...)
   2. clisp: remove a spurious blank
      (cli...@li...)


----------------------------------------------------------------------

Message: 1
Date: Mon, 22 Aug 2011 04:44:58 +0000
From: cli...@li...
Subject: clisp: (convert_error_code): add a cast for g++
To: cli...@li...
Message-ID:
	<hg....@vz...>
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/b1637ee0ba56
changeset: 15525:b1637ee0ba56851dae5db03a7fd6d4ff24a3305e
user:      Sam Steingold <sd...@po...>
date:      2011-08-21 16:21:39 -0400
description:
(convert_error_code): add a cast for g++

diffstat:

 src/error.d |  2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)



------------------------------

Message: 2
Date: Mon, 22 Aug 2011 04:44:59 +0000
From: cli...@li...
Subject: clisp: remove a spurious blank
To: cli...@li...
Message-ID:
	<hg....@vz...>
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/49f0bdefe3f6
changeset: 15526:49f0bdefe3f666f775c39de977ae6913a45ba8ac
user:      Sam Steingold <sd...@po...>
date:      2011-08-21 16:35:51 -0400
description:
remove a spurious blank

diffstat:

 src/condition.lisp |  4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)



------------------------------

------------------------------------------------------------------------------
uberSVN's rich system and user administration capabilities and model 
configuration take the hassle out of deploying and managing Subversion and 
the tools developers use with it. Learn more about uberSVN and get a free 
download at:  http://p.sf.net/sfu/wandisco-dev2dev


------------------------------

_______________________________________________
clisp-cvs mailing list
cli...@li...
https://lists.sourceforge.net/lists/listinfo/clisp-cvs


End of clisp-cvs Digest, Vol 63, Issue 10
*****************************************

Re: MinGW: socket error

[Sam S. <sd...@gn...>]

> * Michael Kappert <zvp...@tz...> [2011-08-19 23:46:58 +0200]:
>
> On 08/19/2011 10:44 PM, Michael Kappert wrote:
>> (DEFPARAMETER *SOCKET-1* (SHOW (SOCKET-CONNECT (SOCKET-SERVER-PORT *SERVER*) "lo
>> calhost" :TIMEOUT 0)))
>> [OS-ERROR]: OS-ERROR(22) : Invalid argument
>
> In the debugger I see
>
> create_client_socket (hostname=0x277cb0 "localhost", port=49566,
>      timeout=0x277d38) at ../src/socket.d:886
> 886     }
> (gdb)
> C_socket_connect () at ../src/stream.d:14251
> 14251     if (handle == INVALID_SOCKET) { ANSIC_error(); }
> (gdb)
>
> *** - OS-ERROR(NIL) : No error

http://lists.gnu.org/archive/html/bug-gnulib/2011-08/msg00103.html


PS. Please tell you MUA to respect the "Mail-Copies-To: never" header.
IOW, please do not CC me the clisp messages; I read them on gmane. thanks.

-- 
Sam Steingold (http://sds.podval.org/) on Ubuntu 11.04 (natty) X 11.0.11001000
http://pmw.org.il http://mideasttruth.com http://honestreporting.com
http://truepeace.org http://ffii.org http://openvotingconsortium.org
.ACMD setaloiv siht gnidaeR

Re: MinGW: socket error

[Michael K. <mic...@gm...>]

On 08/19/2011 11:46 PM, Michael Kappert wrote:
> On 08/19/2011 10:44 PM, Michael Kappert wrote:
>> (DEFPARAMETER *SOCKET-1* (SHOW (SOCKET-CONNECT (SOCKET-SERVER-PORT *SERVER*) "lo
>> calhost" :TIMEOUT 0)))
>> [OS-ERROR]: OS-ERROR(22) : Invalid argument
>
> In the debugger I see
>
> create_client_socket (hostname=0x277cb0 "localhost", port=49566,
>       timeout=0x277d38) at ../src/socket.d:886
> 886     }
> (gdb)
> C_socket_connect () at ../src/stream.d:14251
> 14251     if (handle == INVALID_SOCKET) { ANSIC_error(); }
> (gdb)
>
> *** - OS-ERROR(NIL) : No error

I don't understand this.
The problem seems to be caused by ioctl() returning -1 in socket.d:831, 
but subsequently errcode being 0.

gdb won't step into ioctl() --why??
Looking at gllib/ioctl.c, execute_all_ioctl_hooks should be called, but 
the breakpoint in this function was not hit.
gdb tells me primary_ioctl() is not defined ?!

config.h:
/* Define to 1 when the gnulib module ioctl should be tested. */
#define GNULIB_TEST_IOCTL 1
/* Define to 1 if you have the `ioctl' function. */
/* #undef HAVE_IOCTL */
/* Define if WSAStartup is needed. */
#define WINDOWS_SOCKETS 1

Any suggestions?

Michael

clisp-cvs Digest, Vol 63, Issue 9

[<cli...@li...>]

Send clisp-cvs mailing list submissions to
	cli...@li...

To subscribe or unsubscribe via the World Wide Web, visit
	https://lists.sourceforge.net/lists/listinfo/clisp-cvs
or, via email, send a message with subject or body 'help' to
	cli...@li...

You can reach the person managing the list at
	cli...@li...

When replying, please edit your Subject line so it is more specific
than "Re: Contents of clisp-cvs digest..."


CLISP CVS commits for today

Today's Topics:

   1. clisp: Implement RFE#3384688: use OS facilities to print
      os-error (cli...@li...)
   2. clisp: * src/makemake.in (LIBS): prepend ${GLLIB_A} before
      -lws2... (cli...@li...)
   3. clisp: fixup 15522:eafb54143f18 for win32
      (cli...@li...)


----------------------------------------------------------------------

Message: 1
Date: Fri, 19 Aug 2011 16:51:34 +0000
From: cli...@li...
Subject: clisp: Implement RFE#3384688: use OS facilities to print
	os-error
To: cli...@li...
Message-ID:
	<hg....@vz...>
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/eafb54143f18
changeset: 15522:eafb54143f18a0da551927174a861c8fedda59ab
user:      Sam Steingold <sd...@po...>
date:      2011-08-19 12:46:12 -0400
description:
Implement RFE#3384688: use OS facilities to print os-error
* src/condition.lisp (try-coerce-to-condition): special handling of
NIL datum for the sake of OS-ERROR & its subclasses
(os-error): add $CODE slot and :REPORT option
(os-error-win32, os-stream-error, os-file-error): new conditions,
subclasses of OS-ERROR
(simple-os-error): remove
(%defclcs): remove OS-ERROR -> SIMPLE-OS-ERROR map
* src/lispbibl.d (cint_white_p): do not export
(condition_t): remove os_error
(OS_file_error): signal OS-FILE-ERROR, not SIMPLE-FILE-ERROR
* src/constsym.d (simple_os_error): remove
(os_error, os_file_error, os_stream_error, strerror): add
(os_error_win32, format_message) [WIN32|CYGWIN]: add
* src/subr.d (strerror): add
(format_message) [WIN32|CYGWIN]: add
* src/error.d (end_error): for os_stream_error, os_file_error,
os_error, os_error_win32: reset errstring (known as datum to
COERCE-TO-CONDITION, see above) to NIL; complete :CODE
(error_code_converter_t, convert_error_code): add
(OS_filestream_error): signal OS-ERRORs, not SIMPLE-ERRORs
* src/errunix.d (os_error_t, get_errormsg): remove
(STRERROR): preliminary implementation: required numeric argument
(OS_error, OS_error_arg): push errcode on STACK for the :CODE argument
(errno_out_low): use ANSIC_error_code_converter & strerror_r
* src/errwin32.d (get_OS_error_info): remove
(OS_error_internal_body): remove
(format_message): add
(OS_error_internal): use it
(FORMAT-MESSAGE): preliminary implementation: required numeric argument
(OS_error, OS_error_arg): push errcode on STACK for the :CODE argument
* src/spvw.d (libopen, find_name): define when WIN32_NATIVE|HAVE_DLOPEN
for the sake of finding converters in error.d:convert_error_code
* modules/syscalls/calls.c (RESOLVE-HOST-IPADDR): signal
error_condition, not os_error because there is no errno
(errno_to_symbol_w, errno_to_symbol_a): add error_code_converter_t
objects for error.d:convert_error_code
(ERRNO, LAST-ERROR): convert from symbolic to numeric too
(STRERROR, FORMAT-MESSAGE): use and override the preliminary
definitions in errunix.d and errwin32.d
* modules/syscalls/preload.lisp: unlock the SYSTEM package and
remove it from *SYSTEM-PACKAGE-LIST* to enable overriding STRERROR
& FORMAT-MESSAGE in calls.c
* modules/syscalls/posix.lisp: import and export SYS::STRERROR &
SYS::FORMAT-MESSAGE; re-add SYSTEM to *SYSTEM-PACKAGE-LIST*

diffstat:

 modules/syscalls/calls.c      |    88 +-
 modules/syscalls/posix.lisp   |     4 +-
 modules/syscalls/preload.lisp |     3 +
 modules/syscalls/syscalls.xml |    45 +-
 src/ChangeLog                 |    48 +
 src/NEWS                      |     8 +
 src/condition.lisp            |    24 +-
 src/constsym.d                |     9 +-
 src/error.d                   |    52 +-
 src/errunix.d                 |   692 +------
 src/errwin32.d                |  3909 +----------------------------------------
 src/lispbibl.d                |     8 +-
 src/spvw.d                    |     4 +-
 src/subr.d                    |     4 +
 tests/ChangeLog               |     4 +
 tests/socket.tst              |    17 +-
 16 files changed, 321 insertions(+), 4598 deletions(-)



------------------------------

Message: 2
Date: Fri, 19 Aug 2011 16:54:07 +0000
From: cli...@li...
Subject: clisp: * src/makemake.in (LIBS): prepend ${GLLIB_A} before
	-lws2...
To: cli...@li...
Message-ID:
	<hg....@vz...>
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/e64b406e68b2
changeset: 15523:e64b406e68b23f30aa7c71f9bd5c1a189a9eed1b
user:      Sam Steingold <sd...@po...>
date:      2011-08-18 17:50:01 -0400
description:
* src/makemake.in (LIBS): prepend ${GLLIB_A} before -lws2_32 & -lintl
<http://article.gmane.org/gmane.lisp.clisp.devel:22701>

diffstat:

 src/ChangeLog   |   5 +++++
 src/makemake.in |  10 +++++-----
 2 files changed, 10 insertions(+), 5 deletions(-)



------------------------------

Message: 3
Date: Fri, 19 Aug 2011 18:56:09 +0000
From: cli...@li...
Subject: clisp: fixup 15522:eafb54143f18 for win32
To: cli...@li...
Message-ID:
	<hg....@vz...>
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/aa741a45b817
changeset: 15524:aa741a45b817a1af1d081f0b150145b7e492d924
user:      Sam Steingold <sd...@po...>
date:      2011-08-19 14:31:48 -0400
description:
fixup 15522:eafb54143f18 for win32

diffstat:

 modules/syscalls/calls.c |   2 +-
 src/errwin32.d           |  18 ++++++++++++++----
 tests/socket.tst         |  14 ++++++++++----
 3 files changed, 25 insertions(+), 9 deletions(-)



------------------------------

------------------------------------------------------------------------------
Get a FREE DOWNLOAD! and learn more about uberSVN rich system, 
user administration capabilities and model configuration. Take 
the hassle out of deploying and managing Subversion and the 
tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2

------------------------------

_______________________________________________
clisp-cvs mailing list
cli...@li...
https://lists.sourceforge.net/lists/listinfo/clisp-cvs


End of clisp-cvs Digest, Vol 63, Issue 9
****************************************

MinGW: socket error

[Michael K. <mic...@gm...>]

On 08/19/2011 10:44 PM, Michael Kappert wrote:
> (DEFPARAMETER *SOCKET-1* (SHOW (SOCKET-CONNECT (SOCKET-SERVER-PORT *SERVER*) "lo
> calhost" :TIMEOUT 0)))
> [OS-ERROR]: OS-ERROR(22) : Invalid argument

In the debugger I see

create_client_socket (hostname=0x277cb0 "localhost", port=49566,
     timeout=0x277d38) at ../src/socket.d:886
886     }
(gdb)
C_socket_connect () at ../src/stream.d:14251
14251     if (handle == INVALID_SOCKET) { ANSIC_error(); }
(gdb)

*** - OS-ERROR(NIL) : No error


Michael

Re: attempt with mingw

[Michael K. <mic...@gm...>]

> Von: Sam Steingold 
> > * Michael Kappert 
> >
> >> Von: Sam Steingold <sd...@gn...>
> >> > * Michael Kappert <zvp...@tz...> [2011-08-19 00:21:14
> +0200]:
> >> > ddk/ntifs.h is the only place that defines FILE_ACCESS_INFORMATION on
> my
> >> > installation (current MinGW installed 5 days ago).
> >> > This version has
> >> > 	#include "ntddk.h"
> >> > which is correct. It does not include wdm.h.
> >> 
> >> where is ntddk? is it in include or include/ddk?
> >
> > All these header (ntifs, ntstatus, ntddk, winddk) belong to the the
> > Device Driver Kit and are in include/ddk. Same on my old cygwin and
> > cygwin-1.7.
> 
> so how does gcc find them if they are in include/ddk?

Because #include "..." searches in the directory containing the current file first. The cygwin ddk headers use #include <...>.

> btw, could you please try the current tip?

I have
$ hg tip
changeset:   15525:aa741a45b817
(make check crashed with socket errors before this. Unfortunately it also crashed my windows session, so I didn't make any progress debugging.)

> what does (socket-connect 0) print for you?
> I get 
> *** - OS-ERROR(10049) : Cannot assign requested address
> even though I should see EADDRNOTAVAIL instead of 10049.

Sorry, not reproduced. I get
[1]> (socket-connect 0)

*** - OS-ERROR(EADDRNOTAVAIL) : Cannot assign requested address
Mögliche Optionen:
ABORT          :R1      Abort main loop
Break 1 [2]>


I re-ran make check but it still hangs:

(MULTIPLE-VALUE-LIST (SOCKET-STATUS *SERVER* 0))
EQUAL-OK: (NIL 0)
(DEFPARAMETER *SOCKET-1* (SHOW (SOCKET-CONNECT (SOCKET-SERVER-PORT *SERVER*) "lo
calhost" :TIMEOUT 0)))
[OS-ERROR]: OS-ERROR(22) : Invalid argument
ERROR!! ERROR should be *SOCKET-1* !
(DEFPARAMETER *STATUS-ARG* (LIST (LIST *SERVER*) (LIST *SOCKET-1* :IO)))
[SIMPLE-UNBOUND-VARIABLE]: LET: variable *SOCKET-1* has no value

ERROR!! ERROR should be *STATUS-ARG* !
(EQ (SOCKET-STATUS *STATUS-ARG* 0) *STATUS-ARG*)
[SIMPLE-UNBOUND-VARIABLE]: EVAL: variable *STATUS-ARG* has no value

ERROR!! ERROR should be T !
(CDR (ASSOC *SERVER* *STATUS-ARG*))
[SIMPLE-UNBOUND-VARIABLE]: EVAL: variable *STATUS-ARG* has no value

ERROR!! ERROR should be T !
(CDDR (ASSOC *SOCKET-1* *STATUS-ARG*))
[SIMPLE-UNBOUND-VARIABLE]: EVAL: variable *SOCKET-1* has no value

ERROR!! ERROR should be :OUTPUT !
(DEFPARAMETER *SOCKET-2* (SHOW (SOCKET-ACCEPT *SERVER*)))
-> CLISP hangs. 

Michael



-- 
NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!		
Jetzt informieren: http://www.gmx.net/de/go/freephone

Re: attempt with mingw

[Sam S. <sd...@gn...>]

> * Michael Kappert <zvp...@tz...> [2011-08-19 14:00:51 +0200]:
>
>> Von: Sam Steingold <sd...@gn...>
>> > * Michael Kappert <zvp...@tz...> [2011-08-19 00:21:14 +0200]:
>> > ddk/ntifs.h is the only place that defines FILE_ACCESS_INFORMATION on my
>> > installation (current MinGW installed 5 days ago).
>> > This version has
>> > 	#include "ntddk.h"
>> > which is correct. It does not include wdm.h.
>> 
>> where is ntddk? is it in include or include/ddk?
>
> All these header (ntifs, ntstatus, ntddk, winddk) belong to the the
> Device Driver Kit and are in include/ddk. Same on my old cygwin and
> cygwin-1.7.

so how does gcc find them if they are in include/ddk?


>> I build native win32 executables using cygwin/mingw.
>> it includes win32, not unix (unlike pure cygwin which includes unix)
>
> Ok. Are you using cygwin with the MinGW-w64 GCC?

yes.

btw, could you please try the current tip?
what does (socket-connect 0) print for you?
I get 
*** - OS-ERROR(10049) : Cannot assign requested address
even though I should see EADDRNOTAVAIL instead of 10049.
this is because find_name(NULL,"errno_to_symbol_a") fails even though
$ nm base/lisp.exe |grep errno_to_symbol_
00413078 T _errno_to_symbol_a
00412d38 T _errno_to_symbol_w
$
any ideas why?

-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 11.0.60900031
http://camera.org http://www.memritv.org http://ffii.org
http://mideasttruth.com http://jihadwatch.org http://thereligionofpeace.com
Lisp is a language for doing what you've been told is impossible. - Kent Pitman

[ clisp-Patches-549049 ] unlock or create packages for modules

[SourceForge.net <no...@so...>]

Patches item #549049, was opened at 2002-04-26 08:33
Message generated for change (Settings changed) made by sds
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=301355&aid=549049&group_id=1355

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jörg Höhle (hoehle)
>Assigned to: Jörg Höhle (hoehle)
Summary: unlock or create packages for modules

Initial Comment:
LISPFUN() in external modules ought to be created in 
any package, esp. FFI, EXT or SYS, or even new 
packages, e.g. GDI.
This reduces the need for .mem and TO_PRELOAD files 
which only do (MAKE-PACKAGE "GDI")

Regards,
 JH.

----------------------------------------------------------------------

Comment By: Sam Steingold (sds)
Date: 2011-08-19 13:03

Message:
please see how I handle redefining srror.d:sys::strerror in module
syscalls
(patch 15522:eafb54143f18)

----------------------------------------------------------------------

Comment By: Sam Steingold (sds)
Date: 2005-12-22 16:49

Message:
Logged In: YES 
user_id=5735

you might consider making modprep generate the preload file.
I am not sure this actually buys you much though...

----------------------------------------------------------------------

Comment By: Sam Steingold (sds)
Date: 2005-12-22 15:53

Message:
Logged In: YES 
user_id=5735

of course, init1 is too late, you would have to add init0
which is real real real ugly.
in short, there are two alternatives to preload: 
1. auto-unlocking/auto-creation -- totally un-Lispy
2. init0 -- yuky & ugly.
in fact, init1 is yuky already.
it's bootstrap C code that we are forced to carry around in 
production executables!

----------------------------------------------------------------------

Comment By: Sam Steingold (sds)
Date: 2005-12-22 13:32

Message:
Logged In: YES 
user_id=5735

please do not modify DEFMODULE.
add another macro DEFPACKAGE instead.
the macro should translate into code in init1.

----------------------------------------------------------------------

Comment By: Sam Steingold (sds)
Date: 2005-12-22 13:15

Message:
Logged In: YES 
user_id=5735

>>building modules when READ does not auto-create
>>packages on (READ-FROM-STRING "FOO:BAR")
>Oops, did I miss something? Normally that would signal an
>error in CL. Auto-creation from READ?!?
what I am saying is that (READ-FROM-STRING "FOO:BAR")
will signal an error instead of creating a new package,
and interning and exporting a symbol from it.
I see no reason for modules to be any different.

if you insist on not using TO_PRELOAD, 
you might want to try the init1 function.

----------------------------------------------------------------------

Comment By: Jörg Höhle (hoehle)
Date: 2005-12-22 12:33

Message:
Logged In: YES 
user_id=377168

Actually, my recent experiment with dynload-modules
reinforced the impression that auto-creation is TRT.

Improvements might come along with adding an extra symbol to
module__xyz: the package name. This one would be filled by
DEFMODULE. It's my newest idea. It's different from the
patch in that it allows for one package only (& requires
incompatible changes to all module files).

Having this slot might then allow to relock the package
afterwards, possibly -- or to wait until the subsequent Lisp
file does it.

Concerning redefinitions, I think that a warning is
appropriate (instead of silent overide). I'll have to check
the current behaviour of CLISP. I think continuable errors
are problematic in the early initialisation phase of CLISP.

>building modules when READ does not auto-create
>packages on (READ-FROM-STRING "FOO:BAR")
Oops, did I miss something? Normally that would signal an
error in CL. Auto-creation from READ?!?

Additional complexity comes from modern/case-insensitive
packages (PARI is the only example in
modules/*/preload.lisp). That was not present in 2002.
Feature interaction :-(

----------------------------------------------------------------------

Comment By: Sam Steingold (sds)
Date: 2005-12-22 11:58

Message:
Logged In: YES 
user_id=5735

Joerg, I am marking this as "pending".
this means that you have 2 weeks to decide if
you still think that this patch is worth pursuing,
and, if you decide to pursue it, 
you will need to add a comment here
that would explain why you think we need to auto-create
packages when building modules when READ does not auto-create
packages on (READ-FROM-STRING "FOO:BAR").

----------------------------------------------------------------------

Comment By: Sam Steingold (sds)
Date: 2004-07-12 08:57

Message:
Logged In: YES 
user_id=5735

If it ain't broken, don't fix it.
TO_PRELOAD is not broken.

I will not handle this issue.


----------------------------------------------------------------------

Comment By: Sam Steingold (sds)
Date: 2003-07-23 15:57

Message:
Logged In: YES 
user_id=5735

TO_PRELOAD is here to stay.
<http://article.gmane.org/gmane.lisp.clisp.devel/10121>

----------------------------------------------------------------------

Comment By: Jörg Höhle (hoehle)
Date: 2003-01-31 10:49

Message:
Logged In: YES 
user_id=377168

I consider this issue still open, but low-priority.
I need to analyse why Kaz (was it him?) was able to build a 
Lisp without package problem. I believe it worked without 
patch due to the way the clisp-link script works, 
constructing temporary images in between or something like 
that.
When attempting to work with few images and initialize 
modules as needed, like I explain in my "extending CLISP" 
text, one is  still hit by this issue, I'm sure.
I've focussed my priorities right now on finishing easy 
things: ffi-malloc, with-foreign-string (RSN) and then 
finally the dlopen() stuff (whose high-level API I've still 
not completely fixed).

----------------------------------------------------------------------

Comment By: Sam Steingold (sds)
Date: 2003-01-31 09:57

Message:
Logged In: YES 
user_id=5735

Joerg, did you abandon this patch?
should we close it?

----------------------------------------------------------------------

Comment By: Sam Steingold (sds)
Date: 2002-04-30 21:03

Message:
Logged In: YES 
user_id=5735

let's step back.
why is the lock problem here at all?!
a module _should_ live in it's own package, and all new
packages are created unlocked (they _should_ be locked after
the module is created, indirectly, by being pushed on
*sustem-package-list* - I should mention this in the docs!).
SO: what is that package we are unlocking?!

Another issue is the automatic package creation.
I don't like it either (what if you misspell the package
name?  you will get an extra package, which you will notice
until much later, and some weird errors that will take
forever to debug).
What about supplying new packages in modules.h?


----------------------------------------------------------------------

Comment By: Jörg Höhle (hoehle)
Date: 2002-04-30 13:01

Message:
Logged In: YES 
user_id=377168

Ad 1. package lock must be restored by the programmer, 
either in module_initfunc1(), or in Lisp code loaded later.
It cannot be restored after installing the SUBR, since 
unlocking is also the door opener for the module_object_tab, 
where the package is unknown. Without that, the patch has 
little utility for module writers.
E.g. SUBR walked thtough first -> unlock e.g. GDI, then no 
problem creating symbols there, then module_initfunc1 locks 
again or gdi.lisp code locks package again.

Ad 2. Nice idea - but maybe somebody specifically *wants* 
that?
Anyway, this safe-guard protection is a new functionality 
(modules existed for 7 years without it), to be patched 
separately.
DEFUN doesn't complain when you overide something (except 
package-locks). Why should module's LISPFUN be different?

----------------------------------------------------------------------

Comment By: Sam Steingold (sds)
Date: 2002-04-26 12:46

Message:
Logged In: YES 
user_id=5735

1. package lock status must be restored
2. it must be checked that the symbol being interned is not
there yet, i.e., that we are not clobbering some system
functionality.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=301355&aid=549049&group_id=1355

[ clisp-Patches-549049 ] unlock or create packages for modules

[SourceForge.net <no...@so...>]

Patches item #549049, was opened at 2002-04-26 08:33
Message generated for change (Comment added) made by sds
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=301355&aid=549049&group_id=1355

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jörg Höhle (hoehle)
Assigned to: Nobody/Anonymous (nobody)
Summary: unlock or create packages for modules

Initial Comment:
LISPFUN() in external modules ought to be created in 
any package, esp. FFI, EXT or SYS, or even new 
packages, e.g. GDI.
This reduces the need for .mem and TO_PRELOAD files 
which only do (MAKE-PACKAGE "GDI")

Regards,
 JH.

----------------------------------------------------------------------

>Comment By: Sam Steingold (sds)
Date: 2011-08-19 13:03

Message:
please see how I handle redefining srror.d:sys::strerror in module
syscalls
(patch 15522:eafb54143f18)

----------------------------------------------------------------------

Comment By: Sam Steingold (sds)
Date: 2005-12-22 16:49

Message:
Logged In: YES 
user_id=5735

you might consider making modprep generate the preload file.
I am not sure this actually buys you much though...

----------------------------------------------------------------------

Comment By: Sam Steingold (sds)
Date: 2005-12-22 15:53

Message:
Logged In: YES 
user_id=5735

of course, init1 is too late, you would have to add init0
which is real real real ugly.
in short, there are two alternatives to preload: 
1. auto-unlocking/auto-creation -- totally un-Lispy
2. init0 -- yuky & ugly.
in fact, init1 is yuky already.
it's bootstrap C code that we are forced to carry around in 
production executables!

----------------------------------------------------------------------

Comment By: Sam Steingold (sds)
Date: 2005-12-22 13:32

Message:
Logged In: YES 
user_id=5735

please do not modify DEFMODULE.
add another macro DEFPACKAGE instead.
the macro should translate into code in init1.

----------------------------------------------------------------------

Comment By: Sam Steingold (sds)
Date: 2005-12-22 13:15

Message:
Logged In: YES 
user_id=5735

>>building modules when READ does not auto-create
>>packages on (READ-FROM-STRING "FOO:BAR")
>Oops, did I miss something? Normally that would signal an
>error in CL. Auto-creation from READ?!?
what I am saying is that (READ-FROM-STRING "FOO:BAR")
will signal an error instead of creating a new package,
and interning and exporting a symbol from it.
I see no reason for modules to be any different.

if you insist on not using TO_PRELOAD, 
you might want to try the init1 function.

----------------------------------------------------------------------

Comment By: Jörg Höhle (hoehle)
Date: 2005-12-22 12:33

Message:
Logged In: YES 
user_id=377168

Actually, my recent experiment with dynload-modules
reinforced the impression that auto-creation is TRT.

Improvements might come along with adding an extra symbol to
module__xyz: the package name. This one would be filled by
DEFMODULE. It's my newest idea. It's different from the
patch in that it allows for one package only (& requires
incompatible changes to all module files).

Having this slot might then allow to relock the package
afterwards, possibly -- or to wait until the subsequent Lisp
file does it.

Concerning redefinitions, I think that a warning is
appropriate (instead of silent overide). I'll have to check
the current behaviour of CLISP. I think continuable errors
are problematic in the early initialisation phase of CLISP.

>building modules when READ does not auto-create
>packages on (READ-FROM-STRING "FOO:BAR")
Oops, did I miss something? Normally that would signal an
error in CL. Auto-creation from READ?!?

Additional complexity comes from modern/case-insensitive
packages (PARI is the only example in
modules/*/preload.lisp). That was not present in 2002.
Feature interaction :-(

----------------------------------------------------------------------

Comment By: Sam Steingold (sds)
Date: 2005-12-22 11:58

Message:
Logged In: YES 
user_id=5735

Joerg, I am marking this as "pending".
this means that you have 2 weeks to decide if
you still think that this patch is worth pursuing,
and, if you decide to pursue it, 
you will need to add a comment here
that would explain why you think we need to auto-create
packages when building modules when READ does not auto-create
packages on (READ-FROM-STRING "FOO:BAR").

----------------------------------------------------------------------

Comment By: Sam Steingold (sds)
Date: 2004-07-12 08:57

Message:
Logged In: YES 
user_id=5735

If it ain't broken, don't fix it.
TO_PRELOAD is not broken.

I will not handle this issue.


----------------------------------------------------------------------

Comment By: Sam Steingold (sds)
Date: 2003-07-23 15:57

Message:
Logged In: YES 
user_id=5735

TO_PRELOAD is here to stay.
<http://article.gmane.org/gmane.lisp.clisp.devel/10121>

----------------------------------------------------------------------

Comment By: Jörg Höhle (hoehle)
Date: 2003-01-31 10:49

Message:
Logged In: YES 
user_id=377168

I consider this issue still open, but low-priority.
I need to analyse why Kaz (was it him?) was able to build a 
Lisp without package problem. I believe it worked without 
patch due to the way the clisp-link script works, 
constructing temporary images in between or something like 
that.
When attempting to work with few images and initialize 
modules as needed, like I explain in my "extending CLISP" 
text, one is  still hit by this issue, I'm sure.
I've focussed my priorities right now on finishing easy 
things: ffi-malloc, with-foreign-string (RSN) and then 
finally the dlopen() stuff (whose high-level API I've still 
not completely fixed).

----------------------------------------------------------------------

Comment By: Sam Steingold (sds)
Date: 2003-01-31 09:57

Message:
Logged In: YES 
user_id=5735

Joerg, did you abandon this patch?
should we close it?

----------------------------------------------------------------------

Comment By: Sam Steingold (sds)
Date: 2002-04-30 21:03

Message:
Logged In: YES 
user_id=5735

let's step back.
why is the lock problem here at all?!
a module _should_ live in it's own package, and all new
packages are created unlocked (they _should_ be locked after
the module is created, indirectly, by being pushed on
*sustem-package-list* - I should mention this in the docs!).
SO: what is that package we are unlocking?!

Another issue is the automatic package creation.
I don't like it either (what if you misspell the package
name?  you will get an extra package, which you will notice
until much later, and some weird errors that will take
forever to debug).
What about supplying new packages in modules.h?


----------------------------------------------------------------------

Comment By: Jörg Höhle (hoehle)
Date: 2002-04-30 13:01

Message:
Logged In: YES 
user_id=377168

Ad 1. package lock must be restored by the programmer, 
either in module_initfunc1(), or in Lisp code loaded later.
It cannot be restored after installing the SUBR, since 
unlocking is also the door opener for the module_object_tab, 
where the package is unknown. Without that, the patch has 
little utility for module writers.
E.g. SUBR walked thtough first -> unlock e.g. GDI, then no 
problem creating symbols there, then module_initfunc1 locks 
again or gdi.lisp code locks package again.

Ad 2. Nice idea - but maybe somebody specifically *wants* 
that?
Anyway, this safe-guard protection is a new functionality 
(modules existed for 7 years without it), to be patched 
separately.
DEFUN doesn't complain when you overide something (except 
package-locks). Why should module's LISPFUN be different?

----------------------------------------------------------------------

Comment By: Sam Steingold (sds)
Date: 2002-04-26 12:46

Message:
Logged In: YES 
user_id=5735

1. package lock status must be restored
2. it must be checked that the symbol being interned is not
there yet, i.e., that we are not clobbering some system
functionality.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=301355&aid=549049&group_id=1355

[ clisp-Feature Requests-3384688 ] use OS facilities to print os-error

[SourceForge.net <no...@so...>]

Feature Requests item #3384688, was opened at 2011-08-02 10:13
Message generated for change (Settings changed) made by sds
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=351355&aid=3384688&group_id=1355

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: UI
Group: None
Status: Open
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Sam Steingold (sds)
Assigned to: Sam Steingold (sds)
Summary: use OS facilities to print os-error

Initial Comment:
use strerror and FormatMessage instead of internal tables in errunix and errwin32

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=351355&aid=3384688&group_id=1355

clisp-cvs Digest, Vol 63, Issue 8

[<cli...@li...>]

Send clisp-cvs mailing list submissions to
	cli...@li...

To subscribe or unsubscribe via the World Wide Web, visit
	https://lists.sourceforge.net/lists/listinfo/clisp-cvs
or, via email, send a message with subject or body 'help' to
	cli...@li...

You can reach the person managing the list at
	cli...@li...

When replying, please edit your Subject line so it is more specific
than "Re: Contents of clisp-cvs digest..."


CLISP CVS commits for today

Today's Topics:

   1. clisp: * modules/syscalls/calls.c (check_last_error)
      [WIN32|CYGW... (cli...@li...)


----------------------------------------------------------------------

Message: 1
Date: Thu, 18 Aug 2011 20:40:47 +0000
From: cli...@li...
Subject: clisp: * modules/syscalls/calls.c (check_last_error)
	[WIN32|CYGW...
To: cli...@li...
Message-ID:
	<hg....@vz...>
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/9044a93ef830
changeset: 15521:9044a93ef8303782bfbabc89f0f7decb4874204a
user:      Sam Steingold <sd...@po...>
date:      2011-08-18 16:33:23 -0400
description:
* modules/syscalls/calls.c (check_last_error) [WIN32|CYGWIN]:
renamed from check_errno
(OS::LAST-ERROR) [WIN32|CYGWIN]: extracted from OS:ERRNO
(OS::FORMAT-MESSAGE) [WIN32|CYGWIN]: extracted from OS::STRERROR
(POSIX:ERRNO, POSIX:STRERROR): always define
* modules/syscalls/posix.lisp (last-error, format-message): export
* src/lispbibl.d (cint_white_p): export to clisp.h for FORMAT-MESSAGE
to strip terminating whitespace and periods to conform to strerror

diffstat:

 modules/syscalls/calls.c    |  103 +++++++++++++++++++++++++------------------
 modules/syscalls/posix.lisp |    1 +
 modules/syscalls/test.tst   |   11 +++-
 src/ChangeLog               |   13 +++++-
 src/lispbibl.d              |    1 +
 5 files changed, 83 insertions(+), 46 deletions(-)



------------------------------

------------------------------------------------------------------------------
Get a FREE DOWNLOAD! and learn more about uberSVN rich system, 
user administration capabilities and model configuration. Take 
the hassle out of deploying and managing Subversion and the 
tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2

------------------------------

_______________________________________________
clisp-cvs mailing list
cli...@li...
https://lists.sourceforge.net/lists/listinfo/clisp-cvs


End of clisp-cvs Digest, Vol 63, Issue 8
****************************************

Re: attempt with mingw

[Michael K. <mic...@gm...>]

> Von: Sam Steingold <sd...@gn...>
> > * Michael Kappert <zvp...@tz...> [2011-08-19 00:21:14 +0200]:
> > ddk/ntifs.h is the only place that defines FILE_ACCESS_INFORMATION on my
> > installation (current MinGW installed 5 days ago).
> > This version has
> > 	#include "ntddk.h"
> > which is correct. It does not include wdm.h.
> 
> where is ntddk? is it in include or include/ddk?

All these header (ntifs, ntstatus, ntddk, winddk) belong to the the Device Driver Kit and are in include/ddk. Same on my old cygwin and cygwin-1.7.

> I build native win32 executables using cygwin/mingw.
> it includes win32, not unix (unlike pure cygwin which includes unix)

Ok. Are you using cygwin with the MinGW-w64 GCC?

Michael
-- 
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

Re: attempt with mingw

[Sam S. <sd...@gn...>]

> * Michael Kappert <zvp...@tz...> [2011-08-19 00:21:14 +0200]:
>
> FTR, I don't use cygwin at all, I use MinGW+MSYS.
>
> ddk/ntifs.h is the only place that defines FILE_ACCESS_INFORMATION on my 
> installation (current MinGW installed 5 days ago).
> This version has
> 	#include "ntddk.h"
> which is correct. It does not include wdm.h.

where is ntddk? is it in include or include/ddk?

> Looks like you need to include different headers in unix.d (cygwin) and 
> win32.d (MinGW) ?

I build native win32 executables using cygwin/mingw.
it includes win32, not unix (unlike pure cygwin which includes unix)

-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 11.0.60900031
http://pmw.org.il http://mideasttruth.com http://jihadwatch.org
http://dhimmi.com http://memri.org http://openvotingconsortium.org
Lisp suffers from being twenty or thirty years ahead of time.

Re: attempt with mingw

[Michael K. <mic...@gm...>]

On 08/18/2011 11:52 PM, Sam Steingold wrote:
>> * Michael Kappert<zvp...@tz...>  [2011-08-17 22:10:51 +0200]:
>>
>> On 08/10/2011 03:13 PM, Sam Steingold wrote:
>>
>>> so, what should be included on your system?
>>
>> I have almost the same setup:
>> MINGW32_NT-6.0 MICHAEL-PC 1.0.17(0.48/3/2) 2011-04-24 23:39 i686 Msys
>> GCC 4.5.2
>>
>> I don't have winternl.h and ntstatus.h. I assume configure checks for
>> them because they are needed on cygwin.
>>
>> Only ddk/ntifs.h is needed for NtQueryInformationFile (instead of
>> ddk/winddk.h and/or ddk/ntddk.h).
>
> my cygwin system has ddk/ntifs.h too but I cannot use it, see
> <http://article.gmane.org/gmane.os.cygwin:128137>
>

FTR, I don't use cygwin at all, I use MinGW+MSYS.

ddk/ntifs.h is the only place that defines FILE_ACCESS_INFORMATION on my 
installation (current MinGW installed 5 days ago).
This version has
	#include "ntddk.h"
which is correct. It does not include wdm.h.

Looks like you need to include different headers in unix.d (cygwin) and 
win32.d (MinGW) ?

Michael

Re: attempt with mingw

[Sam S. <sd...@gn...>]

> * Michael Kappert <zvp...@tz...> [2011-08-17 22:10:51 +0200]:
>
> On 08/10/2011 03:13 PM, Sam Steingold wrote:
>
>> so, what should be included on your system?
>
> I have almost the same setup:
> MINGW32_NT-6.0 MICHAEL-PC 1.0.17(0.48/3/2) 2011-04-24 23:39 i686 Msys
> GCC 4.5.2
>
> I don't have winternl.h and ntstatus.h. I assume configure checks for
> them because they are needed on cygwin.
>
> Only ddk/ntifs.h is needed for NtQueryInformationFile (instead of
> ddk/winddk.h and/or ddk/ntddk.h).

my cygwin system has ddk/ntifs.h too but I cannot use it, see
<http://article.gmane.org/gmane.os.cygwin:128137>

-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 11.0.60900031
http://mideasttruth.com http://www.PetitionOnline.com/tap12009/
http://camera.org http://palestinefacts.org http://memri.org
I may be getting older, but I refuse to grow up!

Re: different results in different configures

[Vladimir T. <vtz...@gm...>]

On Fri, Aug 19, 2011 at 12:17 AM, Sam Steingold <sd...@gn...> wrote:
> OK, are you sure you have good sources?
> try a fresh "hg clone" from sf and compare what you currently have with
> the official sources.

oops, sorry for the noise!
My lispbibl.d (modified) was not merged correctly with hg tip (which
builds perfectly).

Re: attempt with mingw

[Michael K. <mic...@gm...>]

On 08/18/2011 09:29 PM, Sam Steingold wrote:
>> * Michael Kappert<zvp...@tz...>  [2011-08-18 19:10:47 +0200]:
>>
>> On 08/18/2011 05:55 PM, Sam Steingold wrote:
>>> you might find this patch helpful in this endeavor, but, if it does not,
>>
>> This didn't work, unless I did something wrong.
>
> my bad. please try instead this:

Yes, this works. CLISP built successfully on MinGW.

Michael

Re: different results in different configures

[Sam S. <sd...@gn...>]

> * Vladimir Tzankov <igm...@tz...> [2011-08-19 00:04:29 +0300]:
>
> On Thu, Aug 18, 2011 at 1:05 AM, Sam Steingold <sd...@gn...> wrote:
>> I don't remember what your platform is.
>> where is errno declared on your box?
> it is:
> Linux vtz 2.6.32-27-generic #49-Ubuntu SMP Wed Dec 1 23:52:12 UTC 2010
> i686 GNU/Linux
> and errno is declared as expected in: /usr/include/errno.h

thanks.

>> note that <errno.h> is included before unix.d which defines OS_errno
>> which expands to errno on unix when, apparently, triggers your error.
>> could you please investigate? (by starting with a fresh configure in a
>> separate directory)
>
> <errno.h> is not included at all (grep-ed for it).

OK, are you sure you have good sources?
try a fresh "hg clone" from sf and compare what you currently have with
the official sources.
e.g., my lispbibl.d:1031 has this:

#include <alloca.h>
%% include_file("alloca.h");
#include <stdlib.h>
%% puts("#include <stdlib.h>");
#include <sys/types.h>
%% puts("#include <sys/types.h>");
#include <unistd.h>
#include <sys/socket.h>         /* declares select, used in stream.d */
#include <sys/select.h>
#include <locale.h>
#include <errno.h>
#include <string.h> /* declares strlen() et al */

-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 11.0.60900031
http://jihadwatch.org http://www.memritv.org http://ffii.org http://pmw.org.il
http://memri.org http://www.PetitionOnline.com/tap12009/ http://truepeace.org
Modern man is the missing link between apes and human beings.

Re: different results in different configures

[Vladimir T. <vtz...@gm...>]

On Thu, Aug 18, 2011 at 1:05 AM, Sam Steingold <sd...@gn...> wrote:
> I don't remember what your platform is.
> where is errno declared on your box?
it is:
Linux vtz 2.6.32-27-generic #49-Ubuntu SMP Wed Dec 1 23:52:12 UTC 2010
i686 GNU/Linux
and errno is declared as expected in: /usr/include/errno.h

> note that <errno.h> is included before unix.d which defines OS_errno
> which expands to errno on unix when, apparently, triggers your error.
> could you please investigate? (by starting with a fresh configure in a
> separate directory)

<errno.h> is not included at all (grep-ed for it).
if I include it in lispbibl.d before "unix.c" the build proceeds until:

gcc -I/home/vtz/clisp/hg/src -I/home/vtz/clisp/hg/s/gllib
-I/home/vtz/clisp/hg/src/gllib -g -O2 -W -Wswitch -Wcomment
-Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations
-Wno-sign-compare -Wno-format-nonliteral -O2 -fexpensive-optimizations
-falign-functions=4 -DENABLE_UNICODE -DDYNAMIC_FFI -DDYNAMIC_MODULES
-c misc.c
../src/misc.d: In function ‘C_get_env’:
../src/misc.d:211: error: ‘environ’ undeclared (first use in this function)
../src/misc.d:211: error: (Each undeclared identifier is reported only once
../src/misc.d:211: error: for each function it appears in.)
../src/misc.d: In function ‘C_process_id’:
../src/misc.d:393: warning: implicit declaration of function ‘getpid’

looks like <unistd.h> is not included as well.
if I include it in lispbibl.d (together with <errno.h> before
"unix.c") build proceeds until:

gcc -I/home/vtz/clisp/hg/src -I/home/vtz/clisp/hg/s/gllib
-I/home/vtz/clisp/hg/src/gllib -g -O2 -W -Wswitch -Wcomment
-Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations
-Wno-sign-compare -Wno-format-nonliteral -O2 -fexpensive-optimizations
-falign-functions=4 -DENABLE_UNICODE -DDYNAMIC_FFI -DDYNAMIC_MODULES
-fPIC -DPIC -I/home/vtz/clisp/hg/s/linkkit -c modules.c
gcc -g -O2 -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit
-Wreturn-type -Wmissing-declarations -Wno-sign-compare
-Wno-format-nonliteral -O2 -fexpensive-optimizations
-falign-functions=4 -DENABLE_UNICODE -DDYNAMIC_FFI -DDYNAMIC_MODULES
-fPIC -DPIC -Wl,--export-dynamic modules.o readline.o -lreadline
-lncurses regexi.o calls.o bogomips.o -lm -lcrypt gettext.o lisp.a
-lreadline -lncurses -ldl -lavcall -lcallback -lsigsegv libgnu.a -o
lisp.run
calls.o: In function `C_subr_posix_stat_vfs':
/home/vtz/clisp/hg/modules/syscalls/calls.c:2427: undefined reference
to `ANSIC_error'
calls.o: In function `C_subr_posix_file_stat':
/home/vtz/clisp/hg/modules/syscalls/calls.c:2001: undefined reference
to `ANSIC_error'
calls.o: In function `C_subr_posix_mkdtemp':
/home/vtz/clisp/hg/modules/syscalls/calls.c:2312: undefined reference
to `ANSIC_error'
calls.o: In function `C_subr_posix_domainname':
/home/vtz/clisp/hg/modules/syscalls/calls.c:1936: undefined reference
to `ANSIC_error'
calls.o: In function `C_subr_posix_groups':
/home/vtz/clisp/hg/modules/syscalls/calls.c:1885: undefined reference
to `ANSIC_error'
calls.o:/home/vtz/clisp/hg/modules/syscalls/calls.c:1451: more
undefined references to `ANSIC_error' follow
collect2: ld returned 1 exit status
./clisp-link: failed in /home/vtz/clisp/hg/s/base

Re: attempt with mingw

[Sam S. <sd...@gn...>]

> * Michael Kappert <zvp...@tz...> [2011-08-18 19:10:47 +0200]:
>
> On 08/18/2011 05:55 PM, Sam Steingold wrote:
>> you might find this patch helpful in this endeavor, but, if it does not,
>
> This didn't work, unless I did something wrong.

my bad. please try instead this:

--- a/src/makemake.in	Wed Aug 17 17:33:28 2011 -0400
+++ b/src/makemake.in	Thu Aug 18 15:27:01 2011 -0400
@@ -1507,11 +1507,6 @@ test "${with_dynamic_ffi}" != no && XCFL
 
 test "${with_dynamic_modules}" != no && XCFLAGS="$XCFLAGS -DDYNAMIC_MODULES"
 
-GLLIB_A=libgnu.a
-# libgnu.a must come _before_ -lws2_32
-LIBS="${LIBS} ${GLLIB_A} ${LIBSOCKET}"
-FILES="${GLLIB_A} "${FILES}
-
 if [ "${with_readline}" = no ]; then
   # --without-readline was supplied
   XCFLAGS=$XCFLAGS' -DNO_READLINE'
@@ -1537,6 +1532,11 @@ else
   XCL_GETTEXTLIB=$XCL_GETTEXTLIB' locale'
 fi
 
+GLLIB_A=libgnu.a
+# libgnu.a must come _before_ -lws2_32 -lintl &c
+LIBS="${GLLIB_A} ${LIBS} ${LIBSOCKET}"
+FILES="${GLLIB_A} "${FILES}
+
 FILES='lisp.a '$FILES
 
 CPARTS='        spvw spvwtabf spvwtabs spvwtabo'



-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 11.0.60900031
http://palestinefacts.org http://camera.org http://www.memritv.org
http://pmw.org.il http://honestreporting.com http://thereligionofpeace.com
A number problem "solved" with floats turns into 1.9999999999999998 problems.

Re: attempt with mingw

[Michael K. <mic...@gm...>]

On 08/18/2011 05:55 PM, Sam Steingold wrote:
> you might find this patch helpful in this endeavor, but, if it does not,

This didn't work, unless I did something wrong.

My <build>/Makefile now has
LIBS = -lintl libgnu.a  -luser32 -lole32 -loleaut32 -luuid -liconv 
-L/usr/local/lib -lsigsegv -lws2_32
but the command line still failed (seemed to be unchanged).

Michael

> please keep trying to reorder the command line by hand.
> thanks.
>
> --- a/src/makemake.in	Wed Aug 17 17:33:28 2011 -0400
> +++ b/src/makemake.in	Thu Aug 18 11:52:33 2011 -0400
> @@ -1508,8 +1508,8 @@ test "${with_dynamic_ffi}" != no&&  XCFL
>   test "${with_dynamic_modules}" != no&&  XCFLAGS="$XCFLAGS -DDYNAMIC_MODULES"
>
>   GLLIB_A=libgnu.a
> -# libgnu.a must come _before_ -lws2_32
> -LIBS="${LIBS} ${GLLIB_A} ${LIBSOCKET}"
> +# libgnu.a must come _before_ -lws2_32 -lintl&c
> +LIBS="${GLLIB_A} ${LIBS} ${LIBSOCKET}"
>   FILES="${GLLIB_A} "${FILES}
>
>   if [ "${with_readline}" = no ]; then
>
>

Re: attempt with mingw

[Michael K. <mic...@gm...>]

On 08/18/2011 06:44 PM, Sam Steingold wrote:
>> * Michael Kappert<zvp...@tz...>  [2011-08-18 17:56:47 +0200]:
>>
>> On 08/18/2011 05:48 PM, Sam Steingold wrote:
>>> Michael, could you please try the command line above but with
>>> libgnu,a__before__ all the -l* arguments?
>>>
>> I already tried that, but invoked it in the wrong directory/wrong
>> environment - it complained about missing object files.
>> Where and how do I need to run the command? (This is why I asked how the
>> command is contructed - my idea was to change the corresponding Makefile
>> or script).
>
> it is called from clisp-link.
> you need to edit Makefile and remove "rm -rf base" on failure so that
> even when clisp-link fails, base/ is preserved.
> then you copy/paste the command from the screen and edit it.
>
>

Ok!
libgnu.a must come directly after lisp.a. This command works:

gcc -g -O2 -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit 
-Wreturn-type -Wmissing-declarations -Wno-sign-compare 
-Wno-format-nonliteral -O2 -fexpensive-optimizations -falign-functions=4 
-D_WIN32 -DENABLE_UNICODE -DNO_TERMCAP_NCURSES -DDYNAMIC_MODULES 
-DDLL_EXPORT -DPIC -Wl,--export-all-symbols modules.o regexi.o calls.o 
bogomips.o -luser32 -lole32 -loleaut32 -luuid gettext.o lisp.a libgnu.a 
lisp.def -lintl -luser32 -lole32 -loleaut32 -luuid -liconv 
-L/usr/local/lib -lsigsegv -lws2_32 -o lisp.exe

Michael

Re: attempt with mingw

[Sam S. <sd...@gn...>]

> * Michael Kappert <zvp...@tz...> [2011-08-18 17:56:47 +0200]:
>
> On 08/18/2011 05:48 PM, Sam Steingold wrote:
>> Michael, could you please try the command line above but with 
>> libgnu,a__before__ all the -l* arguments?
>>
> I already tried that, but invoked it in the wrong directory/wrong 
> environment - it complained about missing object files.
> Where and how do I need to run the command? (This is why I asked how the 
> command is contructed - my idea was to change the corresponding Makefile 
> or script).

it is called from clisp-link.
you need to edit Makefile and remove "rm -rf base" on failure so that
even when clisp-link fails, base/ is preserved.
then you copy/paste the command from the screen and edit it.


-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 11.0.60900031
http://ffii.org http://www.memritv.org http://jihadwatch.org
http://mideasttruth.com http://memri.org http://thereligionofpeace.com
There are 10 kinds of people: those who count in binary and those who do not.