Subject: [clisp-list] dynload.d compilation problems

From: Peter Wood <[email-masked]>
Date: Sun Apr 14 02:51:03 2002

Hi,

Joerg has asked for feedback on his work on the new ffi, so I thought
I'd make a patch which would enable anyone to build with
dynload.d. However, there are problems with compilation which I have
solved temporarily, and which should be cleared up now.

I have these rules for dynload.d:

dynload.d : ../src/dynload.d
	-$(LN_S) ../src/dynload.d dynload.d

dynload.c : dynload.d comment5 ansidecl varbrace
	$(COMMENT5) dynload.d | $(ANSIDECL) | $(VARBRACE) > dynload.c

dynload.i.c : dynload.c lispbibl.c sysdll.h
	$(CPP) $(CFLAGS) dynload.c > dynload.i.c

dynload.o : dynload.i.c lispbibl.c sysdll.h
	$(CC) $(CFLAGS) -c dynload.i.c
	$(MV) dynload.i.o dynload.o

There are no problems for sysdll.{o,c,h}

I also have a rule for dynload.s, but that is only because the other
.d files have such a rule, and it does not appear to be used!!??!!
More cruft from the assembler hack days?

The other files do not need the explicit preprocessing stage.  There
are rules for .i but a comment says that is only for debugging.  So it
should not be necessary for dynload either.

When I compile the original dynload.d I get the following:

test -d bindings || mkdir bindings
./comment5 dynload.d | ./ansidecl | ./varbrace > dynload.c
gcc -E -g -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type  -Wno-sign-compare  -fexpensive-optimizations -DUNICODE -DDYNAMIC_FFI -DNO_READLINE dynload.c > dynload.i.c
dynload.d:86: warning: preprocessing directive not recognized within macro arg
dynload.d:86: warning: preprocessing directive not recognized within macro arg
dynload.d:86: warning: preprocessing directive not recognized within macro arg
dynload.d:86: warning: preprocessing directive not recognized within macro arg
dynload.d:86: warning: preprocessing directive not recognized within macro arg
dynload.d:123: warning: preprocessing directive not recognized within macro arg
dynload.d:123: warning: preprocessing directive not recognized within macro arg
dynload.d:123: warning: preprocessing directive not recognized within macro arg
dynload.d:123: warning: preprocessing directive not recognized within macro arg
gcc -g -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type  -Wno-sign-compare  -fexpensive-optimizations -DUNICODE -DDYNAMIC_FFI -DNO_READLINE -c dynload.i.c
dynload.d:82: `#else' after `#else'
 (matches line 78)
dynload.d:117: warning: `#ifdef' with no argument
dynload.d:120: #error "what dlsym now?"
make: *** [dynload.o] Error 1

Now I solved these problems by cruelly excising nearly all Joerg's
#ifdefs and #errors, and the changed dynload.d builds and works
without problems.  This is obviously not portable, however.  On the
other hand, the original dynload.d is not portable anyway.  It uses
preprocessor directives inside macros, which is not part of the C
standard:

http://gcc.gnu.org/fom_serv/cache/29.html

If anyone wants to try it with the my hacked version, its appended.

Regards,
Peter

---

From: Peter Burwood <[email-masked]>
Date: Tue Apr 16 13:04:24 2002

Peter Wood <[email-masked]> writes:

> ..d files have such a rule, and it does not appear to be used!!??!!

No, just more usefulness to help debug things when the compiler generates
bad code.

It is a makefile rule for developers. It does no harm if you don't need it.

> [snip dynload.d problem and patch]
>

Thanks.

On Cygwin there is a problem with CONST, so I added -DCONST=const to the
compile command as a hack. Did you not have a similar problem, 'cos I didn't
see it in your makefile rules. I see that Joerg had it in his compile
commands too.

Ok, a bit later and it all works.

gcc -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -fomit-frame-pointer -Wno-sign-compare -O2 -fexpensive-optimizations -DUNICODE -DEXPORT_SYSCALLS -DDYNAMIC_FFI -c dynload.c -DCONST=const

gcc -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -fomit-frame-pointer -Wno-sign-compare -O2 -fexpensive-optimizations -DUNICODE -DEXPORT_SYSCALLS -DDYNAMIC_FFI -DCONST=const -DHAVE_SHLIB -DHAVE_DLOPEN sysdll.c -c

cd full

# add MODULE(dynload) to modules.h

ln -s ../modules.c modules.c

gcc -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -fomit-frame-pointer -Wno-sign-compare -O2 -fexpensive-optimizations -DUNICODE -DEXPORT_SYSCALLS -DDYNAMIC_FFI -I/cygdrive/d/home/pjb/clisp/bld -c modules.c

gcc -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -fomit-frame-pointer -Wno-sign-compare -O2 -fexpensive-optimizations -DUNICODE -DEXPORT_SYSCALLS -DDYNAMIC_FFI -x none ../dynload.o ../sysdll.o modules.o wildcard.o fnmatch.o regexp.o regexi.o regex.o lisp.a libsigsegv.a libintl.a libiconv.a libreadline.a libavcall.a libcallback.a -lncurses -lm -o lisp.run

cd ../

full/lisp.run -B . -M base/lispinit.mem -norc -q -i regexp/regexp wildcard/wildcard -x "(saveinitmem \"full/lispinit.mem\")"

I have to use a different name for the zlib dll for Cygwin.

Maybe Clisp needs :cygwin added to *features* because it isn't quite unix?
Mind you, perhaps cygwin should have libz.so as part of its unix emulation.

bash-2.05a$ ./.clisp-full -q

[1]> (defvar *zlib-location* "cygz.dll")    ; Cygwin name for zlib dll

*ZLIB-LOCATION*
[2]> (load "dynex.lisp")

;; Loading file dynex.lisp ...

#<FOREIGN-POINTER #x01310000> is a foreign pointer

#<FOREIGN-ADDRESS #x01311144> is a foreign address

#<FOREIGN-FUNCTION "compress" #x01311144> is a foreign function of foreign 
type 
(FFI:C-FUNCTION
 (:ARGUMENTS
  ((:|arg1| (FFI:C-PTR (FFI:C-ARRAY FFI:UINT8 23)) :OUT :ALLOCA)
   (:|arg2| (FFI:C-PTR FFI:ULONG) :IN-OUT :ALLOCA)
   (:|arg3| (FFI:C-PTR (FFI:C-ARRAY FFI:UINT8 9)) :IN :ALLOCA)
   (:|arg4| FFI:ULONG :IN :NONE)))
 (:RETURN-TYPE FFI:INT :NONE) (:LANGUAGE :STDC)).
;; Loading of file dynex.lisp is finished.
T
[3]> (compress #(1 2 3 4 5 6 7 8 9))

#(120 156 99 100 98 102 97 101 99 231 0 0 0 128 0 37 0 0 0 0 0 0 0) ;
16 ;
FFI:UINT8
[4]> 

Well done Joerg, looks like dynamic loading works on Cygwin too.

> Peter

Snap

---

From: Peter Wood <[email-masked]>
Date: Wed Apr 17 06:50:06 2002

Hi,
> It is a makefile rule for developers. It does no harm if you don't need it.

Perhaps it should go in Makefile.devel, then?  When is the last time
anyone went through the assembler code for stream.d, or pathname.d?
:-) And if anyone ever did, is he out of hospital yet? poor guy :-)

> see it in your makefile rules. I see that Joerg had it in his compile

CONST isn't used in dynload.  It's used in sysdll, and I didn't
include my rules for sysdll.{c,h,o} since it compiled without problems
- but yes, CONST must be defined.

Regards,
Peter

---

From: Peter Burwood <[email-masked]>
Date: Wed Apr 17 15:09:12 2002

Hi,

> :-) And if anyone ever did, is he out of hospital yet? poor guy :-)

I've done it and I'm sure I'm not alone.

Aswell as debugging, They can also be used to port to another OS with the
same calling convention, but different object file format and where the
assembler isn't available on the host. I've done this trick too, with Clisp
and GNAT.

> - but yes, CONST must be defined.

dynload includes sysdll.h which has CONST.  But no problem as Joerg says the
newer sysdll.{c,h} files have removed CONST.

regards,
Peter