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

[Peter W. <pet...@wo...>]

Hi,
On Mon, Apr 15, 2002 at 11:30:58AM +0200, Hoehle, Joerg-Cyril wrote:
> Hi,
> 
> Peter Wood wrote:
> 
> > dynload.d:86: warning: preprocessing directive not recognized 
> > within macro arg
> 
> > 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
> 
> Weird. Perhaps too many preprocessing stages??!?
> 
> > other hand, the original dynload.d is not portable anyway.  It uses
> > preprocessor directives inside macros, which is not part of the C
> > standard:
> That's not intended. My code says:
> #ifdef WANT_SYSDLL
>         addr = dll_function(libhandle,symname);
> #else
> #error "what dlsym now?"
> #endif
> 
> I fail to see what's wrong with the above code.
> 
> CLISP has similar places:

I know, but I think the reason is that Clisp doesn't put these
#defines _inside_ the brackets just after a macro.  A problem arises
in dynload.d, I *think*, because in:

 with_string_0(name,O(pathname_encoding),libname, {
        begin_system_call();
        #if defined(AMIGAOS)
          libaddr = OpenLibrary(libname,0);
        #elif defined(WANT_SYSDLL)
          libaddr = dll_open(libname);
        #else
          #error "what dlopen implementation to use now?"
        #endif
        end_system_call();
      });

nothing from '(name .. to })' can be a preprocessor directive.

so 'with_string_0(...'is the offender.

> #if !(defined(AMIGA) || defined(ACORN) || defined(OS2) || defined(WIN32))
>   #if defined(unix)
>     #define GENERIC_UNIX
>   #else
>     #error "Unknown machine type -- set machine again!"
>   #endif
> #endif
> #if !defined(ANSI)
>   #error "An ANSI C or C++ compiler is required to compile CLISP!"
> #endif
> 
> How's my code any different?

I can't guarantee it, since I haven't looked at all the instances of
'#' (and you know the code much better than me), but I think you'll
find that Clisp doesn't put such directives in macro args, or it would
not compile with gcc.  I have no experience with other compilers, but
from what I have read in the gcc faq, I understand some other
compilers do allow this.

> 
> 
> > Now I solved these problems by cruelly excising nearly all Joerg's
> > #ifdefs and #errors,
> 
> That's fine. Anyway, it is a remnant from the time where I wanted to provide a single module compilable with either one of sysdll.d, dynaload.c or whatever else. That's what WANT_SYSDLL is for. It should be completely eliminated.
> 

OK.  

> 
> BTW, don't spend much time writing Makefile entries by hand. It's
generated. The format should be exactly the same as for other .d files
of CLISP. WANT_SYSDLL probably be replaced by something
else. E.g. configure --with-dynload. However, CLISP may need some flag
for modules.h:

Yes.  I was only doing it by hand to get things right before making a
patch for makemake.in.  

> 
> modules.h could say in future, instead of being empty:
> #if defined(WANT_SYSDLL) -- or defined(HAVE_SHLIB) ??
>   MODULE(dynload)
> #endif
> MODULE(regexp)
> #if defined(WIN32)
>   MODULE(dirkey)
> #endif
> 
> OTOH, modules.h could be generated as well and not contain #ifdef. Strictly speaking, there's no need for a flag to the C compiler.
> 
> That's something which needs to be decided (naming etc.) -- Sam?
> 
> But there are bootstrap issues to solve prior to that.
> 
> config.h needs to define HAVE_CONFIG_H, HAVE_SHLIB and HAVE_DLOPEN/SH_LOAD/DLERROR/_DLERROR (what sysdll.c uses) via autoconf macros on UNIX.
> 
> Many thanks for your feedback. Please try to investigate the preprocessor inside preprocessor thing.
> 

Thank you for doing this work on the ffi.  I think Clisp is going to
be better for it, and I have enjoyed experimenting with the dynload module.

I have just retried with (and without) my mistaken extra CPP stage,
and I don't think that makes any difference.  I also tried with (and
without) the preprocessor directives in the with_string_0(...) macro,
and I think that it is the culprit.

Regards,
Peter