osdir.com
mailing list archive

Subject: Re: field `_crypt_struct' has incomplete type - msg#00129

List: programming.swig

Date: Prev Next Index Thread: Prev Next Index
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!"

Attachment: pgpdU8YdnXKyr.pgp
Description: PGP signature

Was this page helpful?
Yes No
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
Sign up for updates to this mailing list. email:
Loading Comments...
Home | News | Patents | Sitemap | FAQ | advertise

Advertising by