From: William S F. <ws...@fu...> - 2007-09-11 21:31:23
|
Kjell Wooding wrote: >> We havn't had a tcl maintainer for ages and perl maintenance is a bit >> quiet. Let me know the patch numbers and I'll try and apply them. >> Ideally I need a test case demonstrating the problems or if it is a >> regression, the name of the testcase. > > For tcl, the patch is #1771313 > For a testcase, I believe bug #1650229 shows it off. If not, I'm sure > I could whip up an example. > The test-suite has examples which use the typemaps in the patch. I had to tweak the typemaps slightly to use limits.h to get the definitions of LONG_LONG_MAX / LLONG_MAX. However, even with the latest gcc, this does not compile using default compiler options. It seems that the compiler will accept the 'long long' by default, but not these macros. Both 'long long' and these macros are in the C99 standard and everything compiles if we pass the --std=c99. Personally I think that gcc should be using the C99 standard by default but as it is not, we need to think up a better solution. I'm not keen on changing the compiler options we test with unless we really have to. Is there anything in tcl.h that can help? Or does anybody know how to get (the non-standard) definitions of LONG_LONG_MAX? SWIG seems to assume that this will be defined if LLONG_MAX is not. We have this... #ifndef LLONG_MAX # define LLONG_MAX LONG_LONG_MAX #endif > In the perl case, the problem has to do with a change in perl5-current > (that made it into > the OpenBSD 4.2 release). On the perl side, the bug is fixed here: > > http://public.activestate.com/cgi-bin/perlbrowse/p/31697 > > I believe the relevant swig patch is #1771410 . I'm still chasing this > one down (perl5 regressions won't even compile properly under > OpenBSD-current and 1.3.31 at the moment) > > >> Perhaps this the problem perl >> testcase: >> Checking testcase li_std_string (with run test) under perl5 >> SWIG Perl test failed: >> >> TypeError in method 'Foo_testl', argument 2 of type 'unsigned long long' > > I don't think it is, but that one should be fairly straightforward to > track down, too. If I get a sec, I'll have a peek. > Your help here will be much appreciated as I'd like to fix this before releasing 1.3.32. William |