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

From: "Hoehle, Joerg-Cyril" <[email-masked]>
Date: Mon Apr 15 03:33:18 2002

Peter,

you pass the file twice through gcc's cpp.

> 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

.d -> .c -> .i.c -> .o is too much

> dynload.d:82: `#else' after `#else'
>  (matches line 78)
> dynload.d:117: warning: `#ifdef' with no argument
> dynload.d:120: #error "what dlsym now?"

The first cpp pass will have replaced the tokens. The second of course finds nothing left.

My current thoughts on HAVE_SHLIB WANT_SYSDLL Makefile etc.
sysdll.c says:
#else
/* Catchall if we don't know about this systems method of dynamic loading */
dll_handle
dll_open (const char *fname)
{ return NULL; }

I don't like this behaviour of sysdll.c at all. You compile, get no error. Only the user gets an error at run-time :-( :-(

Solution: one of:
1. Either modify sysdll.c to remove that test. But then, our sysdll.c is not a drop-in replacement any more. Or
2. Duplicate checks sysdll.c does in dynload.d (defined HAVE_DLOPEN || HAVE_SHL_LOAD || WIN32_NATIVE). If it's not, #error "do not let sysdll compile to empty stubs".
On UNIX, dynload.d will get HAVE_* through lispbibl.c through config.h so no extra switch would be needed.

I'm also considering *not* using sysdll.c for MS-Windows (doing GetProcA() etc. myself in dynload, like for AmigaOS). Sysdll.c would only be needed for systems with config.h (UNIX). Then, sysdll.c should not be used nor linked on MS-Windows, but required for UNIX. I'd get no problem with -UUNICODE and GetPRocAddressA vs GetProcAddressW().

Comments welcome.

Regards,
	Jorg Hohle.

---

From: Peter Wood <[email-masked]>
Date: Mon Apr 15 06:59:11 2002

> you pass the file twice through gcc's cpp.

It shouldn't result in errors.  If CPP finds no tokens, it does
nothing, doesn't it.
> .d -> .c -> .i.c -> .o is too much

I had also tried with just .c -> .o, and got similar errors.  
I just tried again, and got the same errors. (?)

Regards,
Peter