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 sections remain. 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(at)sss(dot)pgh(dot)pa(dot)us> wrote regarding Re:
[HACKERS] odbc/UnixWare 7.1.1: No Go. :

> Larry Rosenman <ler(at)lerctr(dot)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