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

From: "Hoehle, Joerg-Cyril" <[email-masked]>
Date: Mon Apr 15 02:58:17 2002

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:
#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?

> 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.

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:

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.

Regards,
	Jorg Hohle.

---

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

Hi,
> 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.

> 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.

> 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…

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.  

> 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