Re: odbc/UnixWare 7.1.1: No Go.

Since I am playing with StarOffice, I figured I'd try --with-odbc,
current sources, except for the big Bruce commit I just saw :-)

UX:tsort: INFO: psqlodbc.o
UX:tsort: INFO: dlg_specific.o
UX:tsort: INFO: convert.o
UX:tsort: WARNING: Cycle in data
UX:tsort: INFO: psqlodbc.o
UX:tsort: INFO: dlg_specific.o
UX:tsort: INFO: misc.o
UX:tsort: WARNING: Cycle in data
UX:tsort: INFO: dlg_specific.o
UX:tsort: INFO: psqlodbc.o
: libpsqlodbc.a
cc -G -Wl,-z,text -Wl,-h,libpsqlodbc.so.0 -Wl,-Bsymbolic info.o bind.o columninfo.o connection.o convert.o drvconn.o environ.o execute.o lobj.o misc.o options.o pgtypes.o psqlodbc.o qresult.o results.o socket.o parse.o statement.o gpps.o tuple.o tuplelist.o dlg_specific.o -lm -Wl,-R/usr/local/pgsql/lib -o libpsqlodbc.so.0.26
UX:ld: ERROR: psqlodbc.o: symbol: '_fini' multiply defined; also in file /usr/ccs/lib/crti.o
gmake[3]: *** [libpsqlodbc.so.0.26] Error 1
gmake[3]: Leaving directory `/home/ler/pg-dev/pgsql/src/interfaces/odbc'
gmake[2]: *** [all] Error 2
gmake[2]: Leaving directory `/home/ler/pg-dev/pgsql/src/interfaces'
gmake[1]: *** [all] Error 2
gmake[1]: Leaving directory `/home/ler/pg-dev/pgsql/src'
gmake: *** [all] Error 2

Why do WE define _fini?

LER

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler(at)lerctr(dot)org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

Works fine here.

> Since I am playing with StarOffice, I figured I'd try --with-odbc,
> current sources, except for the big Bruce commit I just saw :-)
>
>
> UX:tsort: INFO: psqlodbc.o
> UX:tsort: INFO: dlg_specific.o
> UX:tsort: INFO: convert.o
> UX:tsort: WARNING: Cycle in data
> UX:tsort: INFO: psqlodbc.o
> UX:tsort: INFO: dlg_specific.o
> UX:tsort: INFO: misc.o
> UX:tsort: WARNING: Cycle in data
> UX:tsort: INFO: dlg_specific.o
> UX:tsort: INFO: psqlodbc.o
> : libpsqlodbc.a
> cc -G -Wl,-z,text -Wl,-h,libpsqlodbc.so.0 -Wl,-Bsymbolic info.o bind.o columninfo.o connection.o convert.o drvconn.o environ.o execute.o lobj.o misc.o options.o pgtypes.o psqlodbc.o qresult.o results.o socket.o parse.o statement.o gpps.o tuple.o tuplelist.o dlg_specific.o -lm -Wl,-R/usr/local/pgsql/lib -o libpsqlodbc.so.0.26
> UX:ld: ERROR: psqlodbc.o: symbol: '_fini' multiply defined; also in file /usr/ccs/lib/crti.o
> gmake[3]: *** [libpsqlodbc.so.0.26] Error 1
> gmake[3]: Leaving directory `/home/ler/pg-dev/pgsql/src/interfaces/odbc'
> gmake[2]: *** [all] Error 2
> gmake[2]: Leaving directory `/home/ler/pg-dev/pgsql/src/interfaces'
> gmake[1]: *** [all] Error 2
> gmake[1]: Leaving directory `/home/ler/pg-dev/pgsql/src'
> gmake: *** [all] Error 2
>
> Why do WE define _fini?
>
> LER
>
>
> --
> Larry Rosenman http://www.lerctr.org/~ler
> Phone: +1 972-414-9812 E-Mail: ler(at)lerctr(dot)org
> US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo(at)postgresql(dot)org
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

* Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> [010321 23:08]:
> Works fine here.
on a GCC platform, it does. I suspect this is a portability issue.

LER

>
>
> > Since I am playing with StarOffice, I figured I'd try --with-odbc,
> > current sources, except for the big Bruce commit I just saw :-)
> >
> >
> > UX:tsort: INFO: psqlodbc.o
> > UX:tsort: INFO: dlg_specific.o
> > UX:tsort: INFO: convert.o
> > UX:tsort: WARNING: Cycle in data
> > UX:tsort: INFO: psqlodbc.o
> > UX:tsort: INFO: dlg_specific.o
> > UX:tsort: INFO: misc.o
> > UX:tsort: WARNING: Cycle in data
> > UX:tsort: INFO: dlg_specific.o
> > UX:tsort: INFO: psqlodbc.o
> > : libpsqlodbc.a
> > cc -G -Wl,-z,text -Wl,-h,libpsqlodbc.so.0 -Wl,-Bsymbolic info.o bind.o columninfo.o connection.o convert.o drvconn.o environ.o execute.o lobj.o misc.o options.o pgtypes.o psqlodbc.o qresult.o results.o socket.o parse.o statement.o gpps.o tuple.o tuplelist.o dlg_specific.o -lm -Wl,-R/usr/local/pgsql/lib -o libpsqlodbc.so.0.26
> > UX:ld: ERROR: psqlodbc.o: symbol: '_fini' multiply defined; also in file /usr/ccs/lib/crti.o
> > gmake[3]: *** [libpsqlodbc.so.0.26] Error 1
> > gmake[3]: Leaving directory `/home/ler/pg-dev/pgsql/src/interfaces/odbc'
> > gmake[2]: *** [all] Error 2
> > gmake[2]: Leaving directory `/home/ler/pg-dev/pgsql/src/interfaces'
> > gmake[1]: *** [all] Error 2
> > gmake[1]: Leaving directory `/home/ler/pg-dev/pgsql/src'
> > gmake: *** [all] Error 2
> >
> > Why do WE define _fini?
> >
> > LER
> >
> >
> > --
> > Larry Rosenman http://www.lerctr.org/~ler
> > Phone: +1 972-414-9812 E-Mail: ler(at)lerctr(dot)org
> > US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 1: subscribe and unsubscribe commands go to majordomo(at)postgresql(dot)org
> >
>
>
> --
> Bruce Momjian | http://candle.pha.pa.us
> pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
> + If your life is a hard drive, | 830 Blythe Avenue
> + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler(at)lerctr(dot)org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

Can't we do something with atexit or other PORTABLE end stuff?

I'll look at it for 7.2.

LER

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

On 3/22/01, 10:16:03 AM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote regarding
Re: [HACKERS] odbc/UnixWare 7.1.1: No Go.:

> Larry Rosenman writes:

> > cc -G -Wl,-z,text -Wl,-h,libpsqlodbc.so.0 -Wl,-Bsymbolic info.o bind.o
columninfo.o connection.o convert.o drvconn.o environ.o execute.o lobj.o
misc.o options.o pgtypes.o psqlodbc.o qresult.o results.o socket.o parse.o
statement.o gpps.o tuple.o tuplelist.o dlg_specific.o -lm
-Wl,-R/usr/local/pgsql/lib -o libpsqlodbc.so.0.26
> > UX:ld: ERROR: psqlodbc.o: symbol: '_fini' multiply defined; also in file
/usr/ccs/lib/crti.o
> > gmake[3]: *** [libpsqlodbc.so.0.26] Error 1

> This is a known portability problem on Unixware (at least known to me)
and
> probably other non-GCC setups.

> > Why do WE define _fini?

> Because we need to 'fini' something, I suspect.

> --
> Peter Eisentraut peter_e(at)gmx(dot)net http://yi.org/peter-e/

Larry Rosenman writes:

> cc -G -Wl,-z,text -Wl,-h,libpsqlodbc.so.0 -Wl,-Bsymbolic info.o bind.o columninfo.o connection.o convert.o drvconn.o environ.o execute.o lobj.o misc.o options.o pgtypes.o psqlodbc.o qresult.o results.o socket.o parse.o statement.o gpps.o tuple.o tuplelist.o dlg_specific.o -lm -Wl,-R/usr/local/pgsql/lib -o libpsqlodbc.so.0.26
> UX:ld: ERROR: psqlodbc.o: symbol: '_fini' multiply defined; also in file /usr/ccs/lib/crti.o
> gmake[3]: *** [libpsqlodbc.so.0.26] Error 1

This is a known portability problem on Unixware (at least known to me) and
probably other non-GCC setups.

> Why do WE define _fini?

Because we need to 'fini' something, I suspect.

--
Peter Eisentraut peter_e(at)gmx(dot)net http://yi.org/peter-e/

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Larry Rosenman writes:
>> Why do WE define _fini?

> Because we need to 'fini' something, I suspect.

See src/interfaces/odbc/psqlodbc.c line 126. It doesn't look to me like
the _fini() does anything useful; could we take it out?

We do not actually need the _init() anymore either. Possibly the whole
#ifdef not-Windows segment (lines 92-132) is just asking for trouble and
should be removed.

regards, tom lane

Larry Rosenman writes:

> Can't we do something with atexit or other PORTABLE end stuff?

It's supposed to work transparently for the library user. At least the
_fini can probably be hooked in atexit, but the _init would probably have
to be handled some other way. Maybe some

if (!already_inited)
{
already_inited = 1;
do_init();
}

hooked into one or more functions that the ODBC user would likely call
first (like connect maybe).

>
> I'll look at it for 7.2.
>
> LER
>
> >>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<
>
> On 3/22/01, 10:16:03 AM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote regarding
> Re: [HACKERS] odbc/UnixWare 7.1.1: No Go.:
>
>
> > Larry Rosenman writes:
>
> > > cc -G -Wl,-z,text -Wl,-h,libpsqlodbc.so.0 -Wl,-Bsymbolic info.o bind.o
> columninfo.o connection.o convert.o drvconn.o environ.o execute.o lobj.o
> misc.o options.o pgtypes.o psqlodbc.o qresult.o results.o socket.o parse.o
> statement.o gpps.o tuple.o tuplelist.o dlg_specific.o -lm
> -Wl,-R/usr/local/pgsql/lib -o libpsqlodbc.so.0.26
> > > UX:ld: ERROR: psqlodbc.o: symbol: '_fini' multiply defined; also in file
> /usr/ccs/lib/crti.o
> > > gmake[3]: *** [libpsqlodbc.so.0.26] Error 1
>
> > This is a known portability problem on Unixware (at least known to me)
> and
> > probably other non-GCC setups.
>
> > > Why do WE define _fini?
>
> > Because we need to 'fini' something, I suspect.
>
> > --
> > Peter Eisentraut peter_e(at)gmx(dot)net http://yi.org/peter-e/
>
>

--
Peter Eisentraut peter_e(at)gmx(dot)net http://yi.org/peter-e/

In a very quick look I just made, I tend to agree with Tom, that the
whole non-gcc, non-windows stuff should go.

LER

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

On 3/22/01, 10:20:11 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote regarding Re:
[HACKERS] odbc/UnixWare 7.1.1: No Go. :

> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> > Larry Rosenman writes:
> >> Why do WE define _fini?

> > Because we need to 'fini' something, I suspect.

> See src/interfaces/odbc/psqlodbc.c line 126. It doesn't look to me like
> the _fini() does anything useful; could we take it out?

> We do not actually need the _init() anymore either. Possibly the whole
> #ifdef not-Windows segment (lines 92-132) is just asking for trouble and
> should be removed.

> regards, tom lane

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> It's supposed to work transparently for the library user. At least the
> _fini can probably be hooked in atexit, but the _init would probably have
> to be handled some other way.

The _fini does nothing, and I already made a hack to cover lack of the
_init (which seems not to get called on HPUX) --- see odbc/environ.c
line 37.

regards, tom lane

Does this mean it's eligible to be fixed for 7.1?

LER

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

On 3/22/01, 11:05:29 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote regarding Re:
[HACKERS] odbc/UnixWare 7.1.1: No Go. :

> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> > It's supposed to work transparently for the library user. At least the
> > _fini can probably be hooked in atexit, but the _init would probably have
> > to be handled some other way.

> The _fini does nothing, and I already made a hack to cover lack of the
> _init (which seems not to get called on HPUX) --- see odbc/environ.c
> line 37.

> regards, tom lane

> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?

> http://www.postgresql.org/users-lounge/docs/faq.html

Larry Rosenman <ler(at)lerctr(dot)org> writes:
> Does this mean it's eligible to be fixed for 7.1?

We can talk about it anyway. Does removing the _fini alone make it work
for you, or do we have to remove _init too?

regards, tom lane

need to kill the _init too. Then we get other symbol issues, I think due
to -Wl,z,text, but I'm not sure.

ar crs libpsqlodbc.a `lorder info.o bind.o columninfo.o connection.o
convert.o drvconn.o environ.o execute.o lobj.o misc.o options.o pgtypes.o
psqlodbc.o qresult.o results.o socket.o parse.o statement.o gpps.o
tuple.o tuplelist.o dlg_specific.o | tsort`
UX:tsort: WARNING: Cycle in data
UX:tsort: INFO: results.o
UX:tsort: INFO: parse.o
UX:tsort: INFO: info.o
UX:tsort: WARNING: Cycle in data
UX:tsort: INFO: execute.o
UX:tsort: INFO: environ.o
UX:tsort: INFO: dlg_specific.o
UX:tsort: INFO: convert.o
UX:tsort: INFO: connection.o
UX:tsort: INFO: results.o
UX:tsort: INFO: parse.o
UX:tsort: INFO: statement.o
UX:tsort: INFO: bind.o
UX:tsort: WARNING: Cycle in data
UX:tsort: INFO: execute.o
UX:tsort: INFO: environ.o
UX:tsort: INFO: dlg_specific.o
UX:tsort: INFO: convert.o
UX:tsort: INFO: connection.o
UX:tsort: INFO: results.o
UX:tsort: INFO: qresult.o
UX:tsort: INFO: columninfo.o
: libpsqlodbc.a
cc -G -Wl,-z,text -Wl,-h,libpsqlodbc.so.0 -Wl,-Bsymbolic info.o bind.o
columninfo.o connection.o convert.o drvconn.o environ.o execute.o lobj.o
misc.o options.o pgtypes.o psqlodbc.o qresult.o results.o socket.o
parse.o statement.o gpps.o tuple.o tuplelist.o dlg_specific.o -lm
-Wl,-R/usr/local/pgsql/lib -o libpsqlodbc.so.0.26
Undefined first referenced
symbol in file
close socket.o
strcat info.o
getpwuid misc.o
atof connection.o
atoi info.o
atol convert.o
malloc info.o
labs tuplelist.o
strchr info.o
ldexpf libm.so
ldexpl libm.so
fgets gpps.o
strcmp info.o
strstr info.o
_lib_version libm.so
strcasecmp convert.o
_modf libm.so
strcpy info.o
memcpy convert.o
strlen info.o
__ctype convert.o
strrchr results.o
strtok info.o
modff libm.so
modfl libm.so
time convert.o
localtime convert.o
multibyte_char_check convert.o
__thr_errno libm.so
getpid misc.o
sprintf info.o
setbuf misc.o
inet_addr socket.o
multibyte_strchr convert.o
strdup columninfo.o
strncasecmp convert.o
getuid misc.o
check_client_encoding connection.o
ldexp libm.so
realloc info.o
multibyte_init convert.o
fclose gpps.o
fopen misc.o
strncat convert.o
strncpy connection.o
gethostbyname socket.o
strncmp info.o
sscanf connection.o
vfprintf misc.o
free info.o
_write libm.so
ilogb libm.so
frexpl libm.so
UX:ld: WARNING: Symbol referencing errors.
rm -f libpsqlodbc.so.0
ln -s libpsqlodbc.so.0.26 libpsqlodbc.so.0
rm -f libpsqlodbc.so
ln -s libpsqlodbc.so.0.26 libpsqlodbc.so

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

On 3/22/01, 12:23:57 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:
> > Does this mean it's eligible to be fixed for 7.1?

> We can talk about it anyway. Does removing the _fini alone make it work
> for you, or do we have to remove _init too?

> regards, tom lane

Larry Rosenman <ler(at)lerctr(dot)org> writes:
> need to kill the _init too. Then we get other symbol issues, I think due
> to -Wl,z,text, but I'm not sure.

Um. This suggests that the real problem is a completely wrong approach
to linking the shared lib. On this evidence I'm not going to touch the
_init/_fini ... looks more like you should be fooling with linker
switches.

regards, tom lane

Peter,
I'm not a GNU MAKE person, can you help here?

LER

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

On 3/22/01, 12:49:10 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:
> > need to kill the _init too. Then we get other symbol issues, I think due
> > to -Wl,z,text, but I'm not sure.

> Um. This suggests that the real problem is a completely wrong approach
> to linking the shared lib. On this evidence I'm not going to touch the
> _init/_fini ... looks more like you should be fooling with linker
> switches.

> regards, tom lane

using the following link, with the _init/_fini killed, works:

cc -G *.o -L /usr/local/pgsql/lib -lpq -R/usr/local/pgsql/lib -lsocket -o
libpsqlodbc.so.0.26

SO, Peter, how do we fix the generated make file?

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

On 3/22/01, 12:23:57 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:
> > Does this mean it's eligible to be fixed for 7.1?

> We can talk about it anyway. Does removing the _fini alone make it work
> for you, or do we have to remove _init too?

> regards, tom lane

> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo(at)postgresql(dot)org

and before you ask, the _init and _fini NEED to go away.

LER

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

On 3/22/01, 1:00:08 PM, Larry Rosenman <ler(at)lerctr(dot)org> wrote regarding Re:
[HACKERS] odbc/UnixWare 7.1.1: No Go. :

> using the following link, with the _init/_fini killed, works:

> cc -G *.o -L /usr/local/pgsql/lib -lpq -R/usr/local/pgsql/lib -lsocket -o
> libpsqlodbc.so.0.26

> SO, Peter, how do we fix the generated make file?

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

> On 3/22/01, 12:23:57 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:
> > > Does this mean it's eligible to be fixed for 7.1?

> > We can talk about it anyway. Does removing the _fini alone make it work
> > for you, or do we have to remove _init too?

> > regards, tom lane

> > ---------------------------(end of broadcast)---------------------------
> > TIP 1: subscribe and unsubscribe commands go to majordomo(at)postgresql(dot)org

Larry Rosenman writes:

> need to kill the _init too. Then we get other symbol issues, I think due
> to -Wl,z,text, but I'm not sure.

These look to be due to the -Bsymbolic. Note they're only warnings, but
you could really only tell by trying out the driver. I have a slight
suspicion that -z text plus -Bsymbolic is an idiosyncratic combination,
but I might be off.

>
> ar crs libpsqlodbc.a `lorder info.o bind.o columninfo.o connection.o
> convert.o drvconn.o environ.o execute.o lobj.o misc.o options.o pgtypes.o
> psqlodbc.o qresult.o results.o socket.o parse.o statement.o gpps.o
> tuple.o tuplelist.o dlg_specific.o | tsort`
> UX:tsort: WARNING: Cycle in data
> UX:tsort: INFO: results.o
> UX:tsort: INFO: parse.o
> UX:tsort: INFO: info.o
> UX:tsort: WARNING: Cycle in data
> UX:tsort: INFO: execute.o
> UX:tsort: INFO: environ.o
> UX:tsort: INFO: dlg_specific.o
> UX:tsort: INFO: convert.o
> UX:tsort: INFO: connection.o
> UX:tsort: INFO: results.o
> UX:tsort: INFO: parse.o
> UX:tsort: INFO: statement.o
> UX:tsort: INFO: bind.o
> UX:tsort: WARNING: Cycle in data
> UX:tsort: INFO: execute.o
> UX:tsort: INFO: environ.o
> UX:tsort: INFO: dlg_specific.o
> UX:tsort: INFO: convert.o
> UX:tsort: INFO: connection.o
> UX:tsort: INFO: results.o
> UX:tsort: INFO: qresult.o
> UX:tsort: INFO: columninfo.o
> : libpsqlodbc.a
> cc -G -Wl,-z,text -Wl,-h,libpsqlodbc.so.0 -Wl,-Bsymbolic info.o bind.o
> columninfo.o connection.o convert.o drvconn.o environ.o execute.o lobj.o
> misc.o options.o pgtypes.o psqlodbc.o qresult.o results.o socket.o
> parse.o statement.o gpps.o tuple.o tuplelist.o dlg_specific.o -lm
> -Wl,-R/usr/local/pgsql/lib -o libpsqlodbc.so.0.26
> Undefined first referenced
> symbol in file
> close socket.o
> strcat info.o
> getpwuid misc.o
> atof connection.o
> atoi info.o
> atol convert.o
> malloc info.o
> labs tuplelist.o
> strchr info.o
> ldexpf libm.so
> ldexpl libm.so
> fgets gpps.o
> strcmp info.o
> strstr info.o
> _lib_version libm.so
> strcasecmp convert.o
> _modf libm.so
> strcpy info.o
> memcpy convert.o
> strlen info.o
> __ctype convert.o
> strrchr results.o
> strtok info.o
> modff libm.so
> modfl libm.so
> time convert.o
> localtime convert.o
> multibyte_char_check convert.o
> __thr_errno libm.so
> getpid misc.o
> sprintf info.o
> setbuf misc.o
> inet_addr socket.o
> multibyte_strchr convert.o
> strdup columninfo.o
> strncasecmp convert.o
> getuid misc.o
> check_client_encoding connection.o
> ldexp libm.so
> realloc info.o
> multibyte_init convert.o
> fclose gpps.o
> fopen misc.o
> strncat convert.o
> strncpy connection.o
> gethostbyname socket.o
> strncmp info.o
> sscanf connection.o
> vfprintf misc.o
> free info.o
> _write libm.so
> ilogb libm.so
> frexpl libm.so
> UX:ld: WARNING: Symbol referencing errors.
> rm -f libpsqlodbc.so.0
> ln -s libpsqlodbc.so.0.26 libpsqlodbc.so.0
> rm -f libpsqlodbc.so
> ln -s libpsqlodbc.so.0.26 libpsqlodbc.so
>
> >>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<
>
> On 3/22/01, 12:23:57 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:
> > > Does this mean it's eligible to be fixed for 7.1?
>
> > We can talk about it anyway. Does removing the _fini alone make it work
> > for you, or do we have to remove _init too?
>
> > regards, tom lane
>
>

--
Peter Eisentraut peter_e(at)gmx(dot)net http://yi.org/peter-e/

Larry Rosenman writes:

> using the following link, with the _init/_fini killed, works:
>
> cc -G *.o -L /usr/local/pgsql/lib -lpq -R/usr/local/pgsql/lib -lsocket -o
> libpsqlodbc.so.0.26

The libpq should definitely not be there, but if additional libraries such
as -lsocket make you happy then look at adding a line

SHLIB_LINK += $(filter ...

similar to what's in libpq's Makefile.

However, I don't think this is strictly necessary, since the library is
going to be loaded by a driver manager which is likely to have all these
libraries linked in. I don't understand this architecture too well, so
it's best resolved by trying the library.

--
Peter Eisentraut peter_e(at)gmx(dot)net http://yi.org/peter-e/

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..

The -lpq is NOT needed, that was my f*** up.

LER

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

On 3/22/01, 2:50:53 PM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote regarding
Re: [HACKERS] odbc/UnixWare 7.1.1: No Go. :

> Larry Rosenman writes:

> > need to kill the _init too. Then we get other symbol issues, I think due
> > to -Wl,z,text, but I'm not sure.

> These look to be due to the -Bsymbolic. Note they're only warnings, but
> you could really only tell by trying out the driver. I have a slight
> suspicion that -z text plus -Bsymbolic is an idiosyncratic combination,
> but I might be off.

> >
> > ar crs libpsqlodbc.a `lorder info.o bind.o columninfo.o connection.o
> > convert.o drvconn.o environ.o execute.o lobj.o misc.o options.o pgtypes.o
> > psqlodbc.o qresult.o results.o socket.o parse.o statement.o gpps.o
> > tuple.o tuplelist.o dlg_specific.o | tsort`
> > UX:tsort: WARNING: Cycle in data
> > UX:tsort: INFO: results.o
> > UX:tsort: INFO: parse.o
> > UX:tsort: INFO: info.o
> > UX:tsort: WARNING: Cycle in data
> > UX:tsort: INFO: execute.o
> > UX:tsort: INFO: environ.o
> > UX:tsort: INFO: dlg_specific.o
> > UX:tsort: INFO: convert.o
> > UX:tsort: INFO: connection.o
> > UX:tsort: INFO: results.o
> > UX:tsort: INFO: parse.o
> > UX:tsort: INFO: statement.o
> > UX:tsort: INFO: bind.o
> > UX:tsort: WARNING: Cycle in data
> > UX:tsort: INFO: execute.o
> > UX:tsort: INFO: environ.o
> > UX:tsort: INFO: dlg_specific.o
> > UX:tsort: INFO: convert.o
> > UX:tsort: INFO: connection.o
> > UX:tsort: INFO: results.o
> > UX:tsort: INFO: qresult.o
> > UX:tsort: INFO: columninfo.o
> > : libpsqlodbc.a
> > cc -G -Wl,-z,text -Wl,-h,libpsqlodbc.so.0 -Wl,-Bsymbolic info.o bind.o
> > columninfo.o connection.o convert.o drvconn.o environ.o execute.o lobj.o
> > misc.o options.o pgtypes.o psqlodbc.o qresult.o results.o socket.o
> > parse.o statement.o gpps.o tuple.o tuplelist.o dlg_specific.o -lm
> > -Wl,-R/usr/local/pgsql/lib -o libpsqlodbc.so.0.26
> > Undefined first referenced
> > symbol in file
> > close socket.o
> > strcat info.o
> > getpwuid misc.o
> > atof connection.o
> > atoi info.o
> > atol convert.o
> > malloc info.o
> > labs tuplelist.o
> > strchr info.o
> > ldexpf libm.so
> > ldexpl libm.so
> > fgets gpps.o
> > strcmp info.o
> > strstr info.o
> > _lib_version libm.so
> > strcasecmp convert.o
> > _modf libm.so
> > strcpy info.o
> > memcpy convert.o
> > strlen info.o
> > __ctype convert.o
> > strrchr results.o
> > strtok info.o
> > modff libm.so
> > modfl libm.so
> > time convert.o
> > localtime convert.o
> > multibyte_char_check convert.o
> > __thr_errno libm.so
> > getpid misc.o
> > sprintf info.o
> > setbuf misc.o
> > inet_addr socket.o
> > multibyte_strchr convert.o
> > strdup columninfo.o
> > strncasecmp convert.o
> > getuid misc.o
> > check_client_encoding connection.o
> > ldexp libm.so
> > realloc info.o
> > multibyte_init convert.o
> > fclose gpps.o
> > fopen misc.o
> > strncat convert.o
> > strncpy connection.o
> > gethostbyname socket.o
> > strncmp info.o
> > sscanf connection.o
> > vfprintf misc.o
> > free info.o
> > _write libm.so
> > ilogb libm.so
> > frexpl libm.so
> > UX:ld: WARNING: Symbol referencing errors.
> > rm -f libpsqlodbc.so.0
> > ln -s libpsqlodbc.so.0.26 libpsqlodbc.so.0
> > rm -f libpsqlodbc.so
> > ln -s libpsqlodbc.so.0.26 libpsqlodbc.so
> >
> > >>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<
> >
> > On 3/22/01, 12:23:57 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:
> > > > Does this mean it's eligible to be fixed for 7.1?
> >
> > > We can talk about it anyway. Does removing the _fini alone make it work
> > > for you, or do we have to remove _init too?
> >
> > > regards, tom lane
> >
> >

> --
> Peter Eisentraut peter_e(at)gmx(dot)net http://yi.org/peter-e/

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

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

OK, it *IS* just a WARNING that the symbols are undefined.

SO, can we get the _fini/_init stuff commented/taken out for 7.1?

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

Can I get a go/nogo decision on whether these two functions can be #if'd
out for 7.1?

Thanks.

LER

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

On 3/22/01, 4:02:45 PM, Larry Rosenman <ler(at)lerctr(dot)org> wrote regarding Re:
[HACKERS] odbc/UnixWare 7.1.1: No Go. :

> OK, it *IS* just a WARNING that the symbols are undefined.

> SO, can we get the _fini/_init stuff commented/taken out for 7.1?

> 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

> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster

I'll take the deafening silence as a NO?

LER

* Larry Rosenman <ler(at)lerctr(dot)org> [010323 16:59]:
> Can I get a go/nogo decision on whether these two functions can be #if'd
> out for 7.1?
>
> Thanks.
>
> LER
>
>
> >>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<
>
> On 3/22/01, 4:02:45 PM, Larry Rosenman <ler(at)lerctr(dot)org> wrote regarding Re:
> [HACKERS] odbc/UnixWare 7.1.1: No Go. :
>
>
> > OK, it *IS* just a WARNING that the symbols are undefined.
>
> > SO, can we get the _fini/_init stuff commented/taken out for 7.1?
>
> > 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
>
> > ---------------------------(end of broadcast)---------------------------
> > TIP 4: Don't 'kill -9' the postmaster
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler(at)lerctr(dot)org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

Larry Rosenman <ler(at)lerctr(dot)org> writes:
> I'll take the deafening silence as a NO?

I was (a) waiting to see what Peter thought about it, and (b) wondering
whether you'd actually tested to see that the built ODBC driver does
something useful. I'm not eager to risk a post-RC1 change that could
conceivably break other platforms. Moving ODBC on UW from "doesn't
compile" to "compiles" isn't enough of a reason to take the risk.
You need to demonstrate that it moves all the way to "works".

It'd probably be a good idea to discuss the change on pgsql-odbc,
too, just in case anyone interested is hanging out there and not here.

regards, tom lane

* Peter Eisentraut <peter_e(at)gmx(dot)net> [010324 17:35]:
> Tom Lane writes:
>
> > Larry Rosenman <ler(at)lerctr(dot)org> writes:
> > > I'll take the deafening silence as a NO?
> >
> > I was (a) waiting to see what Peter thought about it,
>
> Don't ask me, I don't know what this does...
>
> > and (b) wondering
> > whether you'd actually tested to see that the built ODBC driver does
> > something useful. I'm not eager to risk a post-RC1 change that could
> > conceivably break other platforms. Moving ODBC on UW from "doesn't
> > compile" to "compiles" isn't enough of a reason to take the risk.
> > You need to demonstrate that it moves all the way to "works".
>
> Methinks so too.
then it'll have to wait for 7.2. I can't get enough bits to work,
and no answer on pgsql-odbc yet.
>
> --
> Peter Eisentraut peter_e(at)gmx(dot)net http://yi.org/peter-e/

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler(at)lerctr(dot)org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

Tom Lane writes:

> Larry Rosenman <ler(at)lerctr(dot)org> writes:
> > I'll take the deafening silence as a NO?
>
> I was (a) waiting to see what Peter thought about it,

Don't ask me, I don't know what this does...

> and (b) wondering
> whether you'd actually tested to see that the built ODBC driver does
> something useful. I'm not eager to risk a post-RC1 change that could
> conceivably break other platforms. Moving ODBC on UW from "doesn't
> compile" to "compiles" isn't enough of a reason to take the risk.
> You need to demonstrate that it moves all the way to "works".

Methinks so too.

--
Peter Eisentraut peter_e(at)gmx(dot)net http://yi.org/peter-e/