Re: odbc/UnixWare 7.1.1: No Go.

OK, will do.  For the record:
-z text         In dynamic mode only, force a fatal error if any relocations         against non-writable, allocatable
sectionsremain. This is the         default for IA-64 objects.
 

I don't have a good way to test it yet, as the only ODBC client I have is 
Star Office which is a Linux binary, and I can't seem to get the unixODBC 
configuration to like it on the FreeBSD box. 

I guess this will have to wait for 7.2, since we are in Freeze, though. 

No biggie for me, just trying to help.

I do think that the _init/_fini stuff should go away for NON-GCC 
platforms, though. 

Also, docs for UnixWare are at:
http://uw7doc.sco.com/
or my local copy for my local system (accessable however):
http://www.lerctr.org:457/


LER

>>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<

On 3/22/01, 3:38:59 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote regarding Re: 
[HACKERS] odbc/UnixWare 7.1.1: No Go. :


> Larry Rosenman <ler@lerctr.org> writes:
> > My question is WHY are we using -Bsymbolic and/or -z text anyway?
> > These options don't appear to buy us anything but grief on SVR[45] ELF
> > systems..

> I have no idea what -z text means to your linker, but if it has a
> -Bsymbolic option then it's a good bet that you need that.  The ODBC
> driver contains some function names that duplicate names in the unixODBC
> driver manager.  The driver's own references to these functions *must*
> be resolved to its own routines and not the manager's, else havoc
> ensues.  But for some reason, the other way is the default on many
> platforms.

> Do not assume that you have this right just because the build succeeds.
> I found in testing on HPUX that not only could you build a wrongly
> linked driver, but it would actually load and connect.  Only certain
> kinds of queries exhibited the problem.  In short: better test it before
> you claim you have it fixed.

>                       regards, tom lane