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 10:24:35 -0400


A weak alias is pretty much what I want. But it I believe it requires
inline assembly, so it's not extremely portable. Also, my primary platform
of interest for FreeTDS is COFF, not ELF, so I don't even know is this is an
option for me.

In an offline thread, jkl suggested using the --binary_compatible flag to
enable the dbopen() entry point, keeping that entry point in a separate
module as I suggested (at least for now). I think that's the best
compromise at this point.

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


On Mon, Aug 26, 2002 at 09:30:00AM -0400, Castellano, Nicholas wrote:
> 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?

Not controllable at build time. Many people (and some distributions) build
separate DSO modules for each PHP extension to be loaded, so the library
load order is governed by the order in which the individual extensions are
listed in the PHP config.

I think on most platforms Apache has dbm support *built in*, which means the
dbm dbopen will be resolved before libsybdb is ever loaded. This would seem
to be a good thing, I suppose.

Another option on ELF platforms may be to declare dbopen as a weak symbol
aliased to tdsdbopen. I think this would have the desired effect, but I'm
not certain; someone would need to test this. If it works, it would be a
more general solution than relying on application link order.

Steve Langasek
postmodern programmer


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