Re: field `_crypt_struct' has incomplete type

On 2003.01.20 17:04 Jeff Cours wrote:
> Hi, everyone -
>
> I'm trying to compile SWIG 1.3.17 on a RedHat 8.0 box using gcc 3.2. 
> I'm getting the "field `_crypt_struct' has incomplete type" error:

I mentioned this here...
http://mailman.cs.uchicago.edu/pipermail/swig/2002-October/005974.html

Yea I am still getting this error, and have not really looked to hard 
for a good solution (one that would be acceptable to add to swig).  One 
of the problems is as you say _GNU_SOURCE needs to be defined in the 
build and also test scripts if it is needed.  Runtime/Makefile and also 
Examples/test-suite/Makefile need to change.  That shouldn't be that 
hard (configure.in just has to check and get the correct paramaters) 
except in cvs swig has switched to using automake, so any changes to 
the build system really won't be seen until the next swig version.

The second issue (I don't think you mentioned it) is the defines in the 
perl headers.  this problem was first described here, and a bunch of 
the test suites also fail

http://mailman.cs.uchicago.edu/pipermail/swig/2002-October/005975.html

If you do something like this short file
#include "EXTERN.h"
#include "perl.h"
#include "XSUB.h"

#include <iostream>

int main() { return 42; }

you get a bunch of errors about macro do_open.  This is because in the 
perl headers, the macro do_open is defined, and in <iostream>, there is 
a private function on some class that is also called do_open.  It took 
me a while to find because here is a naming conflict with a private 
member of a class inside a namespace!  Usually you could just switch 
around the order of the include statements, but in swig that is very 
difficult, because #include <vector> (which also causes some conflicts) 
is included in a .i file which is parsed after the perlrun.swg file.  
Obviously, Perl is not being nice about naming conflicts and is 
polluting the global namespace (well, every namespace).  I am not aware 
of a general workaround, I just have to #undef a whole bunch of macros.

So.... If anyone wants to look at the first problem in the build 
system, configure.in has to get the correct cppflags for perl and then 
add them to the makefiles.  I am familiar with automake and will look 
at it if no one
else wants to.  For the second problem I think we should mail the 
general perl list and ask if there is a way to keep perl inside its own 
namespace.  If no one has any ideas, I will mail beginners@xxxxxxxx 
(any recomendations for which perl list? I am not that familiar with 
any of them)

John
_______________________________________________
Swig maillist  -  Swig@xxxxxxxxxxxxxxx
http://mailman.cs.uchicago.edu/mailman/listinfo/swig