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: "Sarangi, Savitri (ODC - Satyam)" <SSarangi AT Satyam.odc.ml.com>
  • To: TDS Development Group <freetds AT franklin.oit.unc.edu>
  • Subject: Re: Link error for C++ with FreeTDS - certain dblib calls missing in FreeTDS lib
  • Date: Mon, 26 Aug 2002 20:42:04 +0530

Dear all

Thanks very much indeed for the prompt help. I have been busy working with
my code based on the clues provided.
Yes, I am trying to make Sybase Open Client application to work with SQL
Server. Since both the dblibraries are alike, I assumed in the first round
that everything should work. Thanks for the info that some functions are not
implemented. I have now removed them
Yet to grapple with the full dimension of the issues. Will be in touch

thanks and regards

savitri

> ----------
> From: Castellano, Nicholas[SMTP:Nicholas_Castellano AT acml.com]
> Reply To: TDS Development Group
> Sent: Monday, August 26, 2002 7:54 PM
> To: TDS Development Group
> Subject: [freetds] Re: Link error for C++ with FreeTDS - certain
> dblib calls missing in FreeTDS lib
>
> 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.
>
>
>
> ---
> You are currently subscribed to freetds as: [ssarangi AT Satyam.odc.ml.com]
> To unsubscribe, forward this message to
> $subst('Email.Unsub')
>

<<application/ms-tnef>>




Archive powered by MHonArc 2.6.24.

Top of Page