Thread: Re: [INTERFACES] crypt not included when compiling libpgtcl !!!!!!!
Hi,
I've just downloaded the new pgaccess 0.92b. Of course I experienced
the 'unresolved crypt' problem. I made a mod. both in the Makefile
for libpq and libpgtcl as follows:
diff on libpq/Makefile:
35,37d34
<
< LIBS = -lcrypt
<
42c39
< LDFLAGS_SL = -Bdynamic -shared -soname libpq.so.$(SO_MAJOR_VERSION)
---
> LDFLAGS_SL = -shared -soname libpq.so.$(SO_MAJOR_VERSION)
100c97
< $(LD) $(LDFLAGS_SL) -o $@ $(OBJS) $(LIBS)
---
> $(LD) $(LDFLAGS_SL) -o $@ $(OBJS)
diff on libpgtcl/Makefile:
42c42
< LDFLAGS_SL = -Bdynamic -shared
---
> LDFLAGS_SL = -shared
After compiling and installing this resulted in the following ourput from
'ldd libpgtcl.so':
libpq.so.1 => /usr/local/pgsql/lib/libpq.so.1 (0x4000b000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x40018000)
libc.so.6 => /lib/libc.so.6 (0x40045000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00000000)
Finally PgAccess could start, but ... when I load a database I do get the
tables shown, but I also get:
Error in startup script: First argument is not a valid query result
while executing
"pg_result $pgres -numTuples"
(procedure "open_database" line 31)
invoked from within
"open_database"
(procedure "main" line 18)
invoked from within
"main $argc $argv"
(file "pgaccess.tcl" line 4831)
I am using Tcl/Tk 8.0, but I am using PostgreSQL 6.3.2. Is this a
6.3.2/6.4 compatibility issue?
Greetings,
___________________________________________________________________________
/
_/ _/_/ / Leif Jensen (leif@danmos.dk)
_/ _/ _/ /
_/ _/_/ _/_/_/ /
_/ _/ _/ _/ _/ / Linux 2.0.33, gcc 2.7.2, wxWin 1.68C
_/ _/ _/_/ _/ _/ /
_/ _/ _/ _/ _/ /
_/_/_/_/ _/_/ _/_/ _/ / (and Windows 95 :-(
___________________________________________________________________________
leif@danmos.dk writes:
> I've just downloaded the new pgaccess 0.92b. Of course I experienced
> the 'unresolved crypt' problem. I made a mod. both in the Makefile
> for libpq and libpgtcl as follows:
>
> diff on libpq/Makefile:
>
> 35,37d34
> <
> < LIBS = -lcrypt
> <
> 42c39
> < LDFLAGS_SL = -Bdynamic -shared -soname libpq.so.$(SO_MAJOR_VERSION)
> ---
> > LDFLAGS_SL = -shared -soname libpq.so.$(SO_MAJOR_VERSION)
> 100c97
> < $(LD) $(LDFLAGS_SL) -o $@ $(OBJS) $(LIBS)
> ---
> > $(LD) $(LDFLAGS_SL) -o $@ $(OBJS)
>
> diff on libpgtcl/Makefile:
>
> 42c42
> < LDFLAGS_SL = -Bdynamic -shared
> ---
> > LDFLAGS_SL = -shared
Which version did you say you were using? There is no assignment of
LDFLAGS_SL in either libpq's or libpgtcl's Makefile in 6.4 --- that's
being done in src/Makefile.shlib now. I wonder whether you have some
6.4 beta version.
Still, this -Bdynamic switch looks interesting. Constantin, if you
add that to LDFLAGS_SL in src/Makefile.shlib (in the Linux case, of
course) does it work any better for you?
> After compiling and installing this resulted in the following ourput from
> 'ldd libpgtcl.so':
> libpq.so.1 => /usr/local/pgsql/lib/libpq.so.1 (0x4000b000)
> libcrypt.so.1 => /lib/libcrypt.so.1 (0x40018000)
> libc.so.6 => /lib/libc.so.6 (0x40045000)
> /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00000000)
That looks pretty good...
> Error in startup script: First argument is not a valid query result
> while executing
> "pg_result $pgres -numTuples"
>
> I am using Tcl/Tk 8.0, but I am using PostgreSQL 6.3.2. Is this a
> 6.3.2/6.4 compatibility issue?
6.4 libpq (and hence libpgtcl) cannot talk to a 6.3.2 backend at all.
But that should have resulted in a failure in the pg_connect statement,
because it would have been detected by the old backend as an unsupported
protocol version number.
I wonder whether what you actually have is a couple of different pre-6.4
code snapshots. We changed the FE/BE protocol a couple of times between
6.3.2 and 6.4beta1, but we only changed the protocol version number
once. Some of those intermediate states of the code would have failed
to talk to each other with peculiar symptoms, perhaps like this.
BTW, which Linux distribution are you using?
regards, tom lane
Re: [INTERFACES] crypt not included when compiling libpgtcl !!!!!!!
From
Constantin Teodorescu
Date:
leif@danmos.dk wrote: > > After compiling and installing this resulted in the following ourput from > 'ldd libpgtcl.so': > > libpq.so.1 => /usr/local/pgsql/lib/libpq.so.1 (0x4000b000) > libcrypt.so.1 => /lib/libcrypt.so.1 (0x40018000) > libc.so.6 => /lib/libc.so.6 (0x40045000) > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00000000) It looks good ! :-) > Finally PgAccess could start, but ... when I load a database I do get the > tables shown, but I also get: > > Error in startup script: First argument is not a valid query result > while executing > "pg_result $pgres -numTuples" > (procedure "open_database" line 31) > > I am using Tcl/Tk 8.0, but I am using PostgreSQL 6.3.2. Is this a > 6.3.2/6.4 compatibility issue? Yeap ! 0.92b goes fine with PostgreSQL 6.4 due to some changes in libpgtcl PgAccess v0.90 goes with PostgreSQL 6.3.2 I just wanted to say that I like *very* much PostgreSQL 6.4 , the guys from PostgreSQL development team are making a fine job. I plan to make some enhancements to PgAccess so the next 6.4.1 PostgreSQL will come with a better version of PgAccess. -- Constantin Teodorescu FLEX Consulting Braila, ROMANIA
Tom, I pulled down the latest 6.4 snapshot today & had a similar problem with the missing crypt, although not related to tcl. Following is the exact & only changes I had to make based on the earlier mail list discussion about this problem. Should this not make it to the source tree to save others from the same fate? It took a while just to chase the previous mailings. My system is RedHat Linux 5.0, kernel 2.0.31. $ diff Makefile.shlib.1 Makefile.shlib 107a108 > SHLIB_LINK := -lcrypt 110c111 < LDFLAGS_SL := -shared -soname $(shlib) --- > LDFLAGS_SL := -Bdynamic -shared -soname $(shlib) Ken
"Ken J. Wright" <ken@ori-ind.com> writes:
> I pulled down the latest 6.4 snapshot today & had a similar problem with
> the missing crypt, although not related to tcl. Following is the exact &
> only changes I had to make based on the earlier mail list discussion about
> this problem. Should this not make it to the source tree to save others
> from the same fate?
Thanks, Ken. I was just waiting for some confirmation that this would
fix things... I will apply an appropriate patch to the source trees.
regards, tom lane