|
|
Subject: Re: field `_crypt_struct' has incomplete type - msg#00129
List: programming.swig
On Mon, 20 Jan 2003 15:04:11 -0800, Jeff Cours <swig-j@xxxxxxxxxxxx> wrote:
> Subject: [Swig] field `_crypt_struct' has incomplete type
>
> 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:
>
> gcc -c -I/usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE -DSWIG_GLOBAL
> -Dbool=char -Dexplicit= libperl.c -fPIC -DPIC -o .libs/libperl.lo
> In file included from
> /usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE/op.h:480,
> from
> /usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE/perl.h:2209,
> from libperl.c:217:
> /usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE/reentr.h:602: field
> `_crypt_struct' has incomplete type
> In file included from
> /usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE/perl.h:3368,
> from libperl.c:217:
> /usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE/proto.h:246: parse error
> before "off64_t"
> (etc...)
>
Same problem with Debian unstable:
gcc -c -I/usr/lib/perl/5.8.0/CORE -DSWIG_GLOBAL -Dbool=char
-Dexplicit= libperl.c -fPIC -DPIC -o .libs/libperl.lo
In file included from /usr/lib/perl/5.8.0/CORE/op.h:480,
from /usr/lib/perl/5.8.0/CORE/perl.h:2209,
from libperl.c:217:
/usr/lib/perl/5.8.0/CORE/reentr.h:602: field `_crypt_struct' has incomplete type
In file included from /usr/lib/perl/5.8.0/CORE/perl.h:3368, from libperl.c:217:
/usr/lib/perl/5.8.0/CORE/proto.h:246: parse error before "off64_t"
/usr/lib/perl/5.8.0/CORE/proto.h:248: parse error before "Perl_do_sysseek"
/usr/lib/perl/5.8.0/CORE/proto.h:248: parse error before "off64_t"
/usr/lib/perl/5.8.0/CORE/proto.h:248: warning: data definition has no type or
storage class
/usr/lib/perl/5.8.0/CORE/proto.h:249: parse error before "Perl_do_tell"
/usr/lib/perl/5.8.0/CORE/proto.h:249: warning: data definition has no type or
storage class
/usr/lib/perl/5.8.0/CORE/proto.h:1378: parse error before "Perl_PerlIO_tell"
/usr/lib/perl/5.8.0/CORE/proto.h:1378: warning: data definition has no type or
storage class
/usr/lib/perl/5.8.0/CORE/proto.h:1379: parse error before "off64_t"
make[1]: *** [libswigpl.la] Error 1
> I found one reference to this problem on the SWIG mailing list,
>
> <http://mailman.cs.uchicago.edu/pipermail/swig/2002-July/005299.html>
>
> that involved hacking perl.h and proto.h. Looking for something less
> intrusive, I found a pointer to a thread in debian-perl,
>
> <http://www.mail-archive.com/debian-perl@xxxxxxxxxxxxxxxx/msg00617.html>
>
> that suggested running "perl -V:cppflags" to see what flags are necessary.
> Among other things, it showed '-D_GNU_SOURCE', which agrees with this message:
>
> <http://archive.develooper.com/perl5-porters@xxxxxxxx/msg75535.html>
>
> Unfortunately, the compile fails in the Perl section of Runtime/Makefile,
> which doesn't seem to honor CPPFLAGS, CXXFLAGS, or CFLAGS. If I hack
> Runtime/Makefile manually to add -D_GNU_SOURCE:
>
> libswigpl$(RELEASESUFFIX).la: $(srcdir)/$(SWIG_TYPECHECK)
> $(srcdir)/$(PERL5_RUNTIME)
> @rm -f libperl.c
> # cat $(srcdir)/perlrun.h >> libperl.c
> cat $(srcdir)/$(SWIG_TYPECHECK) $(srcdir)/$(PERL5_RUNTIME) >>
> libperl.c
> $(LIBTOOL) $(CC) -c $(PERL5_INCLUDE) -DSWIG_GLOBAL -D_GNU_SOURCE
> -Dbool=char -Dexplicit= libperl.c
> $(LIBTOOL) $(CC) -o libswigpl$(RELEASESUFFIX).la libperl.lo -rpath
> $(LIB_DIR) -avoid-version
>
> the compile succeeds.
>
> Is there a more elegant way to solve this problem?
>
> thanks in advance,
> Jeff
>
Bob
--
QOTD:
"What do you mean, you had the dog fixed? Just what made you
think he was broken!"
pgpdU8YdnXKyr.pgp
Description: PGP signature
Was this page helpful?
Thread at a glance:
Previous Message by Date:
click to view message preview
Re: Autoconf support suggestion
On Saturday 25 January 2003 18:50, Brian Shire wrote:
> Hi,
>
> I'm trying to work out a swig.m4 file myself for my projects, because I'm
> needing to configure/make multiple language modules for a few of my
> projects. (yay swig!). I've attached my current working copy for this.
> Although some of this should probably be coordinated somehow with existing
> macros java for example (maybe others?). It would be good if we could get
> this in the swig project so multiple inputs can be provided for stability
> and broader support.
This is exactly what I have in mind. The SWIG system should provide the
Autoconf macros for the target languages. This shouldn't be a big problem
since the SWIG 'configure.in' contains a lot useful stuff. A typical
'configure.in' of a project which uses SWIG and Autoconf may look like (I
don't use the AC_ prefix since they are not from the Autoconf project):
...
SWIG_PROG([required-version])
...
SWIG_PYTHON()
SWIG_PERL()
...
The SWIG_PROG() macro should provide $(SWIG) which can be used to invoke the
swig program. Then a SWIG_ENABLE_CXX() macro can for example add the C++
option to $(SWIG) and you don't have to take care about it in your Makefiles,
similar SWIG_MULTI_MODULE_SUPPORT().
I set $(SWIG) to 'false' if the swig program is not found on the build system,
because if you include the swig generated files in your distribution, you
normally don't need swig to build your project.
The SWIG_TARGET_LANG() macros should provide:
$(SWIG_TARGET_LANG_OPT) # For swig invocations
$(SWIG_CPPFLAGS)
$(SWIG_TARGET_LANG_LIB) # For multi module support
Example Makefile.am:
EXTRA_DIST = Project.i
CLEANFILES = wrap_* Project.py
AM_CPPFLAGS = -I$(top_srcdir)/include $(SWIG_PYTHON_CPPFLAGS)
AM_CXXFLAGS = -Wall
pythondir = $(prefix)/python
python_PYTHON = Project.py
libdir = $(prefix)/python
lib_LTLIBRARIES = libPythonProject.la
libPythonProject_la_SOURCES = wrap_Project.cpp
libPythonProject_la_LDFLAGS = -avoid-version -module
install-exec-hook:
$(mkinstalldirs) "$(DESTDIR)$(pythondir)"
cd "$(DESTDIR)$(pythondir)" && rm -f _Project.so && $(LN_S)
libPythonProject.so _Project.so
uninstall-local:
rm -f "$(DESTDIR)$(pythondir)/_Project.so"
%.py: wrap_%.cpp
wrap_%.cpp: %.i $(top_srcdir)/include/%.h
$(SWIG) $(SWIG_PYTHON_OPT) -I$(top_srcdir)/include -o $@ $<
> -Brian Shire
> <shire@xxxxxxxxxx>
> http://www.tekrat.com
>
> On Sat, Jan 25, 2003 at 02:22:34PM +0100, Sebastian Huber wrote:
> > Hello,
> > is it possible to add a few files to the next SWIG release, which may
> > help to improve the usage of SWIG within projects based on Autoconf. In
> > my opinion only two files are needed.
> >
> > swig-config.in:
> > This file will be installed in the 'bin' directory and provides
> > information about the installed SWIG system, e.g. 'swig-config --version'
> > -> SWIG version.
> >
> > swig.m4:
> > Developers which use SWIG and Autoconf can use this in their projects.
> > [...]
_______________________________________________
Swig maillist - Swig@xxxxxxxxxxxxxxx
http://mailman.cs.uchicago.edu/mailman/listinfo/swig
Next Message by Date:
click to view message preview
Re: field `_crypt_struct' has incomplete type
John Lenz wrote:
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.
That seems like the best answer, though I really don't understand the
advanced features of GNU Make (or the portability issues), so my opinion
probably shouldn't carry a lot of weight. The other option might be the
quick fix of including some way to manually override the flags in
Runtime/Makefile.
- Jeff
_______________________________________________
Swig maillist - Swig@xxxxxxxxxxxxxxx
http://mailman.cs.uchicago.edu/mailman/listinfo/swig
Previous Message by Thread:
click to view message preview
Re: field `_crypt_struct' has incomplete type
John Lenz wrote:
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.
That seems like the best answer, though I really don't understand the
advanced features of GNU Make (or the portability issues), so my opinion
probably shouldn't carry a lot of weight. The other option might be the
quick fix of including some way to manually override the flags in
Runtime/Makefile.
- Jeff
_______________________________________________
Swig maillist - Swig@xxxxxxxxxxxxxxx
http://mailman.cs.uchicago.edu/mailman/listinfo/swig
Next Message by Thread:
click to view message preview
overloaded template functions
Hi there,
I have two overloaded template functions. How could I instantiat both of them?
For one, I have this line in the .i file:
%template(myFunction) myFunction<double>;
This seems to instantiat the first one. How about the other one?
Thanks for help.
Zhong
_____________________________________________________________
Get email for your site ---> http://www.everyone.net
_____________________________________________________________
Select your own custom email address for FREE! Get you@xxxxxxxxxxxxxx w/No Ads,
6MB, POP & more! http://www.everyone.net/selectmail?campaign=tag
_______________________________________________
Swig maillist - Swig@xxxxxxxxxxxxxxx
http://mailman.cs.uchicago.edu/mailman/listinfo/swig
|
|