dbdimp.c:sv_setbool not available before perl 5.36

[robert-scheck]

Building DBD::Firebird 1.36 against Firebird 4.0.0.2496, as shipped by EPEL 8 and 9 for CentOS/RHEL/Rocky Linux 8 and 9 (which contain both Perl 5.26.3), fails like this (while 1.34 built fine before):

gcc -c  -I"/usr/include" -I"/usr/lib64/perl5/vendor_perl/auto/DBI" -Wall -fno-strict-aliasing -D_REENTRANT -D_GNU_SOURCE -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fwrapv -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -Wno-incompatible-pointer-types   -DVERSION=\"1.36\" -DXS_VERSION=\"1.36\" -fPIC "-I/usr/lib64/perl5/CORE"   dbdimp.c
dbdimp.c: In function 'ib_st_fetch':
dbdimp.c:1379:21: error: a label can only be part of a statement and a declaration is not a statement
                     FB_BOOLEAN b = (*((FB_BOOLEAN *) (var->sqldata)));
                     ^~~~~~~~~~
dbdimp.c:1383:21: warning: implicit declaration of function 'sv_setbool'; did you mean 'sv_2bool'? [-Wimplicit-function-declaration]
                     sv_setbool(sv, b == FB_TRUE);
                     ^~~~~~~~~~
                     sv_2bool
dbdimp.c:1701:36: warning: pointer targets in passing argument 7 of 'isc_open_blob2' differ in signedness [-Wpointer-sign]
                                    (char *) NULL);  /* no Blob filter */
                                    ^
In file included from dbdimp.h:77,
                 from Firebird.h:12,
                 from dbdimp.c:15:
/usr/include/ibase.h:556:23: note: expected 'const ISC_UCHAR *' {aka 'const unsigned char *'} but argument is of type 'char *'
 ISC_STATUS ISC_EXPORT isc_open_blob2(ISC_STATUS*,
                       ^~~~~~~~~~~~~~

[robert-scheck]

Not sure if it helps, but CentOS/RHEL/Rocky Linux 8 has GCC 8.5 and CentOS/RHEL/Rocky Linux 9 has GCC 11.4. Switching to GCC 13.0 helps to avoid this build error, but leads afterwards to:

[…] DBD/Firebird/Firebird.so: undefined symbol: sv_setbool at /usr/lib64/perl5/DynaLoader.pm line 193.

According to perl5360delta, sv_setbool was quite recent introduced (Perl 5.36.0 in May 2022), which explains a lot. However from a downstream perspective, a slightly more backwards compatible solution would be appreciated.

[real-dam]

Not sure if it helps, but CentOS/RHEL/Rocky Linux 8 has GCC 8.5 and CentOS/RHEL/Rocky Linux 8 has GCC 11.4. Switching to GCC 13.0 helps to avoid this build error, but leads afterwards to:

[…] DBD/Firebird/Firebird.so: undefined symbol: sv_setbool at /usr/lib64/perl5/DynaLoader.pm line 193.

According to perl5360delta, sv_setbool was quite recent introduced (Perl 5.36.0 in May 2022), which explains a lot. However from a downstream perspective, a slightly more backwards compatible solution would be appreciated.

Yes. I was misled by the perlapi documentation, which mentions that sv_set_bool was introduced in 5.35.xx, but no such note is present about sv_setbool.

Fixed in version 1.37.

The "a label can only be part of a statement" compilation error with older GCC seems very strange to me. Please file another issue about it if you wish. A patch would be welcome.

[robert-scheck]

The "a label can only be part of a statement" compilation error with older GCC seems very strange to me.

I meanwhile assume this is some GCC quirks (bug?), because as per DBD::Firebird 1.37 with #59 applied, GCC 11.4 from CentOS/RHEL/Rocky Linux 9 doesn't yell anymore (GCC 8.5 from CentOS/RHEL/Rocky Linux 8 still yells, but doesn't when using a later GCC version, thus that's what I now used for EPEL 8), and based on the difference between 1.36 and 1.37 at least I can't see why GCC yells.