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@lerctr.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 2Why do WE define _fini?
LER
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.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@candle.pha.pa.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 2Why do WE define _fini?
LER
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.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@lerctr.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@gmx.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
Show quoted text
probably other non-GCC setups.
Why do WE define _fini?
Because we need to 'fini' something, I suspect.
--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
Import Notes
Reply to msg id not found: Pine.LNX.4.30.0103221714510.1208-100000@peter.localdomainReference msg id not found: Pine.LNX.4.30.0103221714510.1208-100000@peter.localdomain | Resolved by subject fallback
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@gmx.net http://yi.org/peter-e/
Peter Eisentraut <peter_e@gmx.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@gmx.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.26UX: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@gmx.net http://yi.org/peter-e/
--
Peter Eisentraut peter_e@gmx.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@sss.pgh.pa.us> wrote regarding Re:
[HACKERS] odbc/UnixWare 7.1.1: No Go. :
Show quoted text
Peter Eisentraut <peter_e@gmx.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@gmx.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@sss.pgh.pa.us> wrote regarding Re:
[HACKERS] odbc/UnixWare 7.1.1: No Go. :
Show quoted text
Peter Eisentraut <peter_e@gmx.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?
Larry Rosenman <ler@lerctr.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@sss.pgh.pa.us> wrote regarding Re:
[HACKERS] odbc/UnixWare 7.1.1: No Go. :
Show quoted text
Larry Rosenman <ler@lerctr.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@lerctr.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@sss.pgh.pa.us> wrote regarding Re:
[HACKERS] odbc/UnixWare 7.1.1: No Go. :
Show quoted text
Larry Rosenman <ler@lerctr.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@sss.pgh.pa.us> wrote regarding Re:
[HACKERS] odbc/UnixWare 7.1.1: No Go. :
Show quoted text
Larry Rosenman <ler@lerctr.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@postgresql.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@lerctr.org> wrote regarding Re:
[HACKERS] odbc/UnixWare 7.1.1: No Go. :
Show quoted text
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@sss.pgh.pa.us> wrote regarding Re:
[HACKERS] odbc/UnixWare 7.1.1: No Go. :
Larry Rosenman <ler@lerctr.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@postgresql.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.soOriginal Message <<<<<<<<<<<<<<<<<<
On 3/22/01, 12:23:57 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:
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@gmx.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@gmx.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@gmx.net> wrote regarding
Re: [HACKERS] odbc/UnixWare 7.1.1: No Go. :
Show quoted text
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.soOriginal Message <<<<<<<<<<<<<<<<<<
On 3/22/01, 12:23:57 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:
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@gmx.net http://yi.org/peter-e/
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
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@sss.pgh.pa.us> wrote regarding Re:
[HACKERS] odbc/UnixWare 7.1.1: No Go. :
Show quoted text
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
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@sss.pgh.pa.us> wrote regarding Re:
[HACKERS] odbc/UnixWare 7.1.1: No Go. :
Show quoted text
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
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@lerctr.org> wrote regarding Re:
[HACKERS] odbc/UnixWare 7.1.1: No Go. :
Show quoted text
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@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
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
I'll take the deafening silence as a NO?
LER
* Larry Rosenman <ler@lerctr.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@lerctr.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@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
---------------------------(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@postgresql.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@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Larry Rosenman <ler@lerctr.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@gmx.net> [010324 17:35]:
Tom Lane writes:
Larry Rosenman <ler@lerctr.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@gmx.net http://yi.org/peter-e/
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Import Notes
Reply to msg id not found: Pine.LNX.4.30.0103250044100.2319-100000@peter.localdomain
Tom Lane writes:
Larry Rosenman <ler@lerctr.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@gmx.net http://yi.org/peter-e/