[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Net::SAML doesn't compile with perl 5.20 on FreeBSD 10.0



Mike Kuznetsov <mike.kuznetsov@xxxxxxxxxxxxx> said:
> Ok, that patch to SWIG-generated SAML_wrap.c works, everything built well
> 
> Idea from here https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752335
> 
> Do you think you can fix this in upstream somehow?

Have you tried adding

#include <stdbool.h>

to top of Net/SAML_wrap.c?

If that fix works, I can modify zxid.i appropriately.

Cheers,
--Sampo

> --- SAML_wrap.c.orig    2014-11-06 03:55:26.000000000 -0800
> +++ SAML_wrap.c 2014-11-06 03:57:38.000000000 -0800
> @@ -1442,7 +1442,10 @@
>    #undef eof
>  #endif
>  #ifdef bool
> -  #undef bool
> +  /* Leave if macro is from C99 stdbool.h */
> +  #ifndef __bool_true_false_are_defined
> +    #undef bool
> +  #endif
>  #endif
>  #ifdef close
>    #undef close
> 
> 
> On Thu, Nov 6, 2014 at 2:35 PM, Mike Kuznetsov <mike.kuznetsov@xxxxxxxxxxxxx
> > wrote:
> 
> > Is this piece of /usr/local/lib/perl5/5.20/mach/CORE/handy.h could be
> > somehow connected with the problem:
> >
> > #if defined(I_STDBOOL) && !defined(PERL_BOOL_AS_CHAR)
> > #  include <stdbool.h>
> > #  ifndef HAS_BOOL
> > #    define HAS_BOOL 1
> > #  endif
> > #endif
> >
> > /* bool is built-in for g++-2.6.3 and later, which might be used
> >    for extensions.  <_G_config.h> defines _G_HAVE_BOOL, but we can't
> >    be sure _G_config.h will be included before this file.  _G_config.h
> >    also defines _G_HAVE_BOOL for both gcc and g++, but only g++
> >    actually has bool.  Hence, _G_HAVE_BOOL is pretty useless for us.
> >    g++ can be identified by __GNUG__.
> >    Andy Dougherty^IFebruary 2000
> > */
> > #ifdef __GNUG__^I^I/* GNU g++ has bool built-in */
> >
> > # ifndef PERL_BOOL_AS_CHAR
> >
> > #  ifndef HAS_BOOL
> > #    define HAS_BOOL 1
> > #  endif
> > # endif
> > #endif
> >
> > /* The NeXT dynamic loader headers will not build with the bool macro
> >    So declare them now to clear confusion.
> > */
> > #if defined(NeXT) || defined(__NeXT__)
> > # undef FALSE
> > # undef TRUE
> >   typedef enum bool { FALSE = 0, TRUE = 1 } bool;
> > # define ENUM_BOOL 1
> > # ifndef HAS_BOOL
> > #  define HAS_BOOL 1
> > # endif /* !HAS_BOOL */
> > #endif /* NeXT || __NeXT__ */
> >
> > #ifndef HAS_BOOL
> > # ifdef bool
> > #  undef bool
> > # endif
> > # define bool char
> > # define HAS_BOOL 1
> > #endif
> >
> > /* cast-to-bool.  A simple (bool) cast may not do the right thing: if bool
> > is
> >  * defined as char for example, then the cast from int is
> >  * implementation-defined (bool)!!(cbool) in a ternary triggers a bug in
> > xlc on
> >  * AIX */
> > #define cBOOL(cbool) ((cbool) ? (bool)1 : (bool)0)
> >
> >
> >
> > On Thu, Nov 6, 2014 at 2:29 PM, Mike Kuznetsov <
> > mike.kuznetsov@xxxxxxxxxxxxx> wrote:
> >
> >>
> >>
> >> On Wed, Nov 5, 2014 at 7:50 PM, <sampo@xxxxxxxxx> wrote:
> >>
> >>>
> >>>
> >>> > I've been trying to build Net::SAML on FreeBSD 10.0 with perl 5.20, but
> >>> > compilation fails.
> >>
> >> The LIKELY() and cBOOL() macros are innovations of perl 5.20.
> >>> I checked the sources of perl 5.18.2 and there the macro
> >>> definition is much more straight forward and does not
> >>> reference bool. I can confirm that there is no compilation
> >>> problem with perl 5.18.2.
> >>>
> >>> In all likelyhood this bool macro or typedef can be found in
> >>> some header that comes with your new perl. Find that
> >>> header and make sure it gets included, e.g.
> >>>
> >>> grep -r '\#\s*define\s+bool' /usr/local/lib/perl5/5.20
> >>> grep -r 'typedef.*?bool;' /usr/local/lib/perl5/5.20
> >>>
> >>
> >> Those greps output is nothing
> >>
> >>
> >>>
> >>> In a pinch, you could try adding definition of bool yourself,
> >>> e.g. #define bool (int)
> >>>
> >>
> >> Where should i try to add it? I tried zxid.h, but nothing changed. I
> >> don't know coding quite well, maybe i didn't understand something
> >>
> >>
> >>
> >>>
> >>> SWIG tool that was used to generate SAML_wrap.c is
> >>> several years old so it may not be aware of backwards
> >>> incompatible changes in perl extension API and thus
> >>> does not understand that some additional file is supposed
> >>> to be included. It is also possible that the perl
> >>> developers screwed up and added a dependency on new
> >>> include file without realizing it themselves. Thus this
> >>> may also be a perl bug worth reporting.
> >>>
> >>
> >> Maybe, but i can't describe it clear enough to report, because i don't
> >> understand it. Besides, there are tons of p5-* ports and perl modules from
> >> CPAN built and installed with this version of perl without any error.
> >>
> >> Don't know what to try next