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