[freetds] Building Sybperl against FreeTDS on Fedora

[Ed Avis]

Hi, I've looked through the list archives for experiences using Sybperl with
FreeTDS and it seems it is possible, but nobody has reported this particular
problem. (Sybperl is the older set of Perl libraries for connecting to Sybase,
providing Sybase::DBlib and Sybase::CTlib packages. I am using the newer
DBD::Sybase with FreeTDS successfully, connecting to an MSSQL server.)

I am using a Fedora 11 x86_64 box with the packaged freetds-0.82. When I try
to build Sybperl it generates a file DBlib.c from a source file DBlib.xs, and
then uses gcc to compile DBlib.c to an object file. The gcc command line is

gcc -c -I/usr/include -D_REENTRANT -D_GNU_SOURCE -DPERL_USE_SAFE_PUTENV
-DDEBUGGING -fno-strict-aliasing -pipe
-I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-I/usr/include/gdbm -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector --param=ssp-buffer-size=4 -m32 -march=i586 -mtune=generic
-fasynchronous-unwind-tables -DVERSION=\"2.18\"
-DXS_VERSION=\"2.18\" -fPIC
"-I/usr/lib/perl5/5.10.0/i386-linux-thread-multi/CORE" -DDBLIBVS=1000
-DSYBPLVER='"2.18"' -DDO_TIE DBlib.c

It fails with errors

DBlib.xs: In function ?XS_Sybase__DBlib__DateTime_crack?:
DBlib.xs:6068: error: ?DBDATEREC? has no member named ?dateyear?
DBlib.xs:6069: error: ?DBDATEREC? has no member named ?datemonth?
DBlib.xs:6070: error: ?DBDATEREC? has no member named ?datedmonth?

Looking at /usr/include/sybdb.h, I see that DBDATEREC is defined as:

typedef struct dbdaterec
{
#ifdef MSDBLIB
DBINT year;
DBINT month;
DBINT day;
DBINT dayofyear;
DBINT weekday;
DBINT hour;
DBINT minute;
DBINT second;
DBINT millisecond;
DBINT tzone;
#else
DBINT dateyear;
DBINT datemonth;
DBINT datedmonth;
DBINT datedyear;
DBINT datedweek;
DBINT datehour;
DBINT dateminute;
DBINT datesecond;
DBINT datemsecond;
DBINT datetzone;
#endif
} DBDATEREC;

So I suppose that MSDBLIB is defined? Although I plan to use the library
to connect to a Microsoft server, I have not done anything special to configure
FreeTDS for 'Microsoft mode'.

Does Sybperl need patching to use the different names for structure members,
or should I do something to unset the MSDBLIB preprocessor symbol, or
something else?

[James K. Lowden]

Post by Ed Avis
DBlib.xs:6068: error: ?DBDATEREC? has no member named ?dateyear?
DBlib.xs:6069: error: ?DBDATEREC? has no member named ?datemonth?
DBlib.xs:6070: error: ?DBDATEREC? has no member named ?datedmonth?
So I suppose that MSDBLIB is defined?

Yes, I suppose so. ;-)

Post by Ed Avis
Does Sybperl need patching to use the different names for structure
members, or should I do something to unset the MSDBLIB preprocessor
symbol, or something else?

That option is true when you configure --enable-msdblib. From the

Post by Ed Avis
if test "$enable_msdblib" = "yes" ; then
dblib_define="#define MSDBLIB 1"
else
dblib_define="#define SYBDBLIB 1"
fi

HTH.

--jkl

[Ed Avis]

Post by James K. Lowden

DBlib.xs:6068: error: ?DBDATEREC? has no member named 'dateyear'
So I suppose that MSDBLIB is defined?

That option is true when you configure --enable-msdblib.

Ah I see that Fedora builds FreeTDS with that:

%configure \
--disable-dependency-tracking \
--disable-rpath \
%{!?_with_static: --disable-static} \
--with-tdsver="4.2" \
--with-unixodbc="%{_prefix}" \
--enable-msdblib \
--enable-sybase-compat \
--with-gnutls

Now, I do want to use FreeTDS to connect to an MSSQL server, so do I need to
keep that flag in there?

If so, I guess Sybperl needs patching to build against a FreeTDS configured this
way. I might go through the Sybperl source and add various #ifdef MSDBLIB
sections. Does that sound a reasonable way to proceed?

[James K. Lowden]

Post by Ed Avis
%configure \
--disable-dependency-tracking \
--disable-rpath \
%{!?_with_static: --disable-static} \
--with-tdsver="4.2" \
--with-unixodbc="%{_prefix}" \
--enable-msdblib \
--enable-sybase-compat \
--with-gnutls
Now, I do want to use FreeTDS to connect to an MSSQL server, so do I
need to keep that flag in there?

http://www.freetds.org/userguide/config.htm#EVERYONE

As the UG says, these flags provide a small degree of compatibility. In
the case of msdblib, it adjusts the date structure; sybase-compat adds a
symbol.

So, no, you don't need --enable-msdblib to connect to a Microsoft server;
you need it only if you're working with code that expects Microsoft's
db-lib conventions. (That's why it's calls msdblib and not, say, ms-tds.)
Sybperl, on the contrary, expects Sybase db-lib conventions.

Post by Ed Avis
If so, I guess Sybperl needs patching to build against a FreeTDS
configured this way. I might go through the Sybperl source and add
various #ifdef MSDBLIB sections. Does that sound a reasonable way to
proceed?

Well, it *could* be. Easiest is to rebuild FreeTDS without those two
flags. Modifying Sybperl might possibly be of some service, in that it
would facilitate using Fedora as-is, or even potentially using Microsoft's
library.

HTH.

--jkl

[Ed Avis]

A few years later, I revisited the advice to build FreeTDS without the
--enable-msdblib flag, in order to build Sybperl using it. I took the
freetds-0.91-8.gitf3ae29d packaged with Fedora and rebuilt it without
this flag. Now most of Sybperl builds, but the dblib parts fail with
'undefined symbol: dbregparam'.

Is there something I need to set to make freetds provide this symbol?
My configure command line is

%configure \
--disable-dependency-tracking \
--disable-rpath \
%{!?_with_static: --disable-static} \
--with-tdsver="4.2" \
--with-unixodbc="%{_prefix}" \
--enable-sybase-compat \
--with-gnutls \
--enable-krb5

Looking at dblib.c, I see that dbregparam is unimplemented, but can I do
something to get the program to link, even if it fails at run time if
this is called?

[James K. Lowden]

On Fri, 19 Jul 2013 14:29:58 +0000 (UTC)

Post by Ed Avis
Looking at dblib.c, I see that dbregparam is unimplemented, but can I
do something to get the program to link, even if it fails at run time
if this is called?

Yes, define DBLIB_UNIMPLEMENTED when compiling FreeTDS.

And, yes, it should be documented. :-/

--jkl