Skip to Content.
Sympa Menu

freetds - Re: Link error for C++ with FreeTDS - certain dblib calls missing in FreeTDS lib

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Castellano, Nicholas" <Nicholas_Castellano AT acml.com>
  • To: "'TDS Development Group'" <freetds AT franklin.metalab.unc.edu>
  • Subject: Re: Link error for C++ with FreeTDS - certain dblib calls missing in FreeTDS lib
  • Date: Mon, 26 Aug 2002 09:30:00 -0400


I'd prefer to avoid configure-time switches (either --enable-dbmfix or
--binary_compatible) to control this.

What I have in mind is this:

- libsybdb(dblib.o) will provide the currently exported tdsdbopen() entry
point.
- A new module, libsybdb(dbopen.o) will export a dbopen() entry point,
providing binary compatibility.

The idea here is that by linking libdbm first, you will get the DBM version
of dbopen(). But if you don't link with libdbm, then you'll get the
dbopen() entry point from our library, which will allow for binary
compatibility. The advantage is that you don't need to support two builds
of FreeTDS, one for coexisting with DBM, and one for binary compatibility
with Sybase.

The downside is that it relies on the link order specified by each
application to work properly. I understand that PHP is the most common case
that uses both libdbm and libsybdb. Could someone who uses PHP check the
order that the libraries are specified when it is built? (I don't use PHP,
and I'd prefer to avoid building it just to find out this one piece of
information, if I can.)

--nick


-----Original Message-----
From: bounce-freetds-145195 AT franklin.oit.unc.edu
[mailto:bounce-freetds-145195 AT franklin.oit.unc.edu]
Sent: Saturday, August 24, 2002 4:47 PM
To: TDS Development Group
Subject: [freetds] Re: Link error for C++ with FreeTDS - certain dblib calls
missing in FreeTDS lib


On Sat, 24 Aug 2002, James K. Lowden wrote:

> > > Just to remind, dbopen() became the exported name about a month
> > > ago; DBOPEN is in the .h. That's what Sybase does (of late).
> >
> > how are we working around the dbm conflict then?
>
> (mumble...) ISTR something I didn't do but thought I did. Can I be
> guilty of that? Turns out I was thinking of dbdead().

Ok, cool. I have no qualms about exporting dbopen() but want to make sure
we are not going back to square 1. Funny, if we would have left
--enable-dbmfix alone we would have been fine. Hind sight is 20/20 right?

> If you use ./configure --binary_compatible, nothing happens. But in a
> future version, that would export dbopen() and frustrate anyone trying
> to link in dbm.

Coolness. Can't wait to see this...take your sybase app and move it to MS
SQL with ease....urm, not exactly what I had in mind with FreeTDS, but
more power to ya.



The information contained in this transmission may contain privileged and
confidential information and is intended only for the use of the person(s)
named above. If you are not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient, any
review, dissemination, distribution or duplication of this communication is
strictly prohibited. If you are not the intended recipient, please contact
the sender immediately by reply e-mail and destroy all copies of the
original message. Please note that for certain accounts we do not accept
orders and/or instructions by e-mail, and for those accounts we will not be
responsible for carrying out such orders and/or instructions. Kindly refrain
from sending orders or instructions by e-mail unless you have confirmed that
we accept such communications for your account. Please also note that to
satisfy regulatory requirements we review the outgoing and incoming e-mail
correspondence of staff members serving certain functions.






Archive powered by MHonArc 2.6.24.

Top of Page