crypt not included when compiling libpgtcl !!!!!!!

Also, PgAccess version that has been included in 6.4 final version is
0.90 , but current stable version is 0.91
(ftp://ftp.flex.ro/pub/pgaccess/pgaccess-0.91.tar.gz)

Yes, it missed the code freeze cutoff and the bug fix cutoff. Next
release try to get the new version announced at least a couple of weeks
before the nominal release date, and a month before would be even
better. Should be in v6.4.1 but I don't think anyone has committed it
yet.

- Tom

Constantin Teodorescu <teo@flex.ro> writes:

RedHat 5.1 i386 with PostgreSQL v6.4 final version
after installing libpgtcl , cannot run pgaccess because library crypt
hasn't been linked into libpgtcl.so
must manually add -lcrypt in Makefile into src/interfaces/libpgtcl

I don't think that's the right approach. libpgtcl doesn't depend on
libcrypt. libpq does, and that's where we need to fix this, or else
we'll see the same problem with any other shared library that depends
on libpq.

Would you check whether it works to add the following patch to
src/interfaces/libpq's Makefile, and then build libpgtcl *without*
a reference to crypt? (I can't test it here since crypt is part of
libc on my machine...)

*** Makefile.in~	Thu Nov  5 18:08:26 1998
--- Makefile.in	Thu Nov  5 18:11:43 1998
***************
*** 34,39 ****
--- 34,43 ----
  OBJS+= common.o wchar.o conv.o
  endif

+ # If crypt is a separate library, rather than part of libc,
+ # make sure it gets included in shared libpq.
+ SHLIB_LINK= $(findstring -lcrypt,$(LIBS))
+ 
  # Shared library stuff, also default 'all' target
  include $(SRCDIR)/Makefile.shlib

regards, tom lane

On Thu, 5 Nov 1998, Thomas G. Lockhart wrote:

Also, PgAccess version that has been included in 6.4 final version is
0.90 , but current stable version is 0.91
(ftp://ftp.flex.ro/pub/pgaccess/pgaccess-0.91.tar.gz)

Yes, it missed the code freeze cutoff and the bug fix cutoff. Next
release try to get the new version announced at least a couple of weeks
before the nominal release date, and a month before would be even
better. Should be in v6.4.1 but I don't think anyone has committed it
yet.

Working on it right now...sorry Constantin :(

Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

On Thu, 5 Nov 1998, Thomas G. Lockhart wrote:

Also, PgAccess version that has been included in 6.4 final version is
0.90 , but current stable version is 0.91
(ftp://ftp.flex.ro/pub/pgaccess/pgaccess-0.91.tar.gz)

Yes, it missed the code freeze cutoff and the bug fix cutoff. Next
release try to get the new version announced at least a couple of weeks
before the nominal release date, and a month before would be even
better. Should be in v6.4.1 but I don't think anyone has committed it
yet.

Working on it right now...sorry Constantin :(

I did pull down 0.90 about a month ago, and never went back to see if a
newer one existed.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@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

Tom Lane wrote:

I don't think that's the right approach. libpgtcl doesn't depend on
libcrypt. libpq does, and that's where we need to fix this, or else
we'll see the same problem with any other shared library that depends
on libpq.

Would you check whether it works to add the following patch to
src/interfaces/libpq's Makefile, and then build libpgtcl *without*
a reference to crypt? (I can't test it here since crypt is part of
libc on my machine...)

Completely delete postgresql from my machine and any trace of libpq and
libpgtcl
Untarred the 6.4 final distribution
apply the patch
compiled from scratch
installed

Got :

[teo@teo teo]$ Error in startup script: couldn't load file
"libpgtcl.so": /usr/local/pgsql/lib/libpgtcl.so: undefined symbol: crypt
while executing
"load libpgtcl.so"
(procedure "main" line 3)
invoked from within
"main $argc $argv"
(file "pgaccess.tcl" line 4813)

When modify the Makefile from libpgtcl adding -lcrypt , recompile,
install . Everything it's ok.

*** Makefile.in~        Thu Nov  5 18:08:26 1998
--- Makefile.in Thu Nov  5 18:11:43 1998
***************
*** 34,39 ****
--- 34,43 ----
OBJS+= common.o wchar.o conv.o
endif

+ # If crypt is a separate library, rather than part of libc,
+ # make sure it gets included in shared libpq.
+ SHLIB_LINK= $(findstring -lcrypt,$(LIBS))
+
# Shared library stuff, also default 'all' target
include $(SRCDIR)/Makefile.shlib

regards, tom lane

--
Constantin Teodorescu
FLEX Consulting Braila, ROMANIA

Constantin Teodorescu <teo@flex.ro> writes:

Tom Lane wrote:

Would you check whether it works to add the following patch to
src/interfaces/libpq's Makefile, and then build libpgtcl *without*
a reference to crypt? (I can't test it here since crypt is part of
libc on my machine...)

[ Still doesn't work ]

Odd. Perhaps your system doesn't support libraries referring to other
shared libraries? (Seems unlikely, but...) In that case you'd be
getting the static libpq.a bound into libpgtcl.so, minus crypt of
course, and then this would happen.

If that's what's happening you should easily be able to tell from the
sizes of libpgtcl.so and libpq.so. On my machine, libpgtcl is actually
smaller than libpq (about half as big, in fact). If libpq is getting
bound into libpgtcl.so then libpgtcl.so would have to be bigger than
libpq.so. Which one is bigger on your machine?

Also, do you have any sort of utility that shows directly what a
program's shared library requirements are? For example, on HPUX
I can do

$ chatr /usr/local/pgsql/bin/pgtclsh
/usr/local/pgsql/bin/pgtclsh:
shared executable
shared library dynamic path search:
SHLIB_PATH disabled second
embedded path enabled first /usr/local/pgsql/lib
shared library list:
static pgtclsh
dynamic ../../interfaces/libpgtcl/libpgtcl.sl
dynamic ../../interfaces/libpq/libpq.sl
dynamic /usr/lib/libdld.sl
dynamic /lib/libcurses.sl
dynamic /lib/libc.sl
shared library binding:
deferred

$ chatr /usr/local/pgsql/lib/libpgtcl.sl
/usr/local/pgsql/lib/libpgtcl.sl:
shared library
shared library list:
dynamic ../libpq/libpq.sl

On Linux I think the corresponding command is "ldd".

regards, tom lane

Yes. libpgtcl is bigger than libpq

But ldd shows that libpq is statically linked :-( . Maybe this is the
problem ?

[root@teo libpgtcl]# ldd libpgtcl.so.2.0
libcrypt.so.1 => /lib/libcrypt.so.1 (0x40014000)
libc.so.6 => /lib/libc.so.6 (0x40041000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00000000)

[root@teo libpgtcl]# ldd ../libpq/libpq.so.2.0
statically linked

[root@teo libpgtcl]# vdir ../libpq/libpq.so.2.0
-rwxr-xr-x 1 root root 50014 Nov 6 10:08
../libpq/libpq.so.2.0

[root@teo libpgtcl]# vdir libpgtcl.so.2.0
-rwxr-xr-x 1 root root 64725 Nov 6 10:19 libpgtcl.so.2.0

--
Constantin Teodorescu
FLEX Consulting Braila, ROMANIA

Constantin Teodorescu <teo@flex.ro> writes:

[root@teo libpgtcl]# ldd libpgtcl.so.2.0
libcrypt.so.1 => /lib/libcrypt.so.1 (0x40014000)
libc.so.6 => /lib/libc.so.6 (0x40041000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00000000)

[root@teo libpgtcl]# ldd ../libpq/libpq.so.2.0
statically linked

Well, that's pretty interesting. Evidently you were able to persuade
the linker to dynamically link libpgtcl.so to libcrypt.so, but the patch
I suggested did *not* persuade the linker to dynamically link libpq.so
to libcrypt.so. Just exactly what change did you make in libpgtcl's
Makefile, anyway? I assumed it was simply adding -lcrypt, but now I
am not so sure.

It's also curious that libpq.so is not showing any dynamic dependency
on libc. I think we must have the wrong linker options for libpq.

[root@teo libpgtcl]# vdir ../libpq/libpq.so.2.0
-rwxr-xr-x 1 root root 50014 Nov 6 10:08
../libpq/libpq.so.2.0

[root@teo libpgtcl]# vdir libpgtcl.so.2.0
-rwxr-xr-x 1 root root 64725 Nov 6 10:19 libpgtcl.so.2.0

And we also need to figure out why the linker is including libpq.a into
libpgtcl.so, instead of creating a dynamic link from libpgtcl.so to
libpq.so like it did for libcrypt and libc.

(BTW, do you have a libcrypt.a in /lib, or just libcrypt.so?)

It seems clear from your ldd results that your machine is capable of
doing the right thing, but we aren't invoking the linker with the right
options. Where I want to get to is:

libpgtcl.so: dynamic dependency on libpq.so (and libc of course)

libpq.so: dynamic dependency on libcrypt.so (and libc of course)

It might be worth extracting the part of the "make all" log that shows
what commands are being used to build each of these libraries.

regards, tom lane

Tom Lane wrote:

It's also curious that libpq.so is not showing any dynamic dependency
on libc. I think we must have the wrong linker options for libpq.

To get the shared library dependency on libc you need to add -lc at the
end of the link options.

--
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP key from public servers; key ID 32B8FAA1
========================================
"Let all that you do be done in love."
1 Corinthians 16:14

Tom Lane wrote:

Constantin Teodorescu <teo@flex.ro> writes:

[root@teo libpgtcl]# ldd libpgtcl.so.2.0
libcrypt.so.1 => /lib/libcrypt.so.1 (0x40014000)
libc.so.6 => /lib/libc.so.6 (0x40041000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00000000)

[root@teo libpgtcl]# ldd ../libpq/libpq.so.2.0
statically linked

Well, that's pretty interesting. Evidently you were able to persuade
the linker to dynamically link libpgtcl.so to libcrypt.so, but the patch
I suggested did *not* persuade the linker to dynamically link libpq.so
to libcrypt.so.

The patch that you send me I have applied ONLY to Makefile.in from
src/interfaces/libpgtcl directory.
Should I apply it to Makefile.in from src/interfaces/libpq directory ?

Just exactly what change did you make in libpgtcl's
Makefile, anyway? I assumed it was simply adding -lcrypt, but now I
am not so sure.

Yes. Only add -lcrypt

And we also need to figure out why the linker is including libpq.a into
libpgtcl.so, instead of creating a dynamic link from libpgtcl.so to
libpq.so like it did for libcrypt and libc.

(BTW, do you have a libcrypt.a in /lib, or just libcrypt.so?)

in /usr/lib libcrypt.a and libcrypt.so
in /lib/libcrypt.so

--
Constantin Teodorescu
FLEX Consulting Braila, ROMANIA

Constantin Teodorescu <teo@flex.ro> writes:

The patch that you send me I have applied ONLY to Makefile.in from
src/interfaces/libpgtcl directory.
Should I apply it to Makefile.in from src/interfaces/libpq directory ?

No no, that change was intended to be applied to libpq's Makefile *not*
libpgtcl's. Sorry if I wasn't clear.

There's also the question of why the linker is making a dynamic
dependency on libc for libpgtcl but not libpq. Oliver suggested
that -lc is needed as well as -lcrypt in the link step, but that
doesn't seem to explain all the facts --- libpgtcl doesn't have
-lc, and it seems to be getting built right. Still, you might try
adding -lc to SHLIB_LINK in libpq's Makefile, and see if that
changes the ldd result.

regards, tom lane

how can i limit the number of rows obtained from a select statement
in postgreSQL to say, 10 rows while the select condition actually
matches more than that. in oracle we can use the ROW_NUM variable
for this purpose but now i met such an issue with postgreSQL

thanks in advance

CV Radhakrishnan

http://www.river-valley.com

Hello Radhakrishnan,

luned�, 9 novembre 98, you wrote:

RCV> how can i limit the number of rows obtained from a select statement
RCV> in postgreSQL to say, 10 rows while the select condition actually
RCV> matches more than that. in oracle we can use the ROW_NUM variable
RCV> for this purpose but now i met such an issue with postgreSQL

On v6.4 you can specify a limit for queries as:

set QUERY_LIMIT TO '10';
To have only the first 10 rows from a select;

-Jose'-

On Thu, 5 Nov 1998, Constantin Teodorescu wrote:

RedHat 5.1 i386 with PostgreSQL v6.4 final version

./configure --with-tcl

after installing libpgtcl , cannot run pgaccess because library crypt
hasn't been linked into libpgtcl.so

must manually add -lcrypt in Makefile into src/interfaces/libpgtcl

Hi Constantin. This is a problem only with systems running glibc, because
for legal reasons the FSF doesn't want to include encryption as part of
glibc. I assume you are doing this on Debian or on Red Hat 5.x?

Perhaps we need an extra template for glibc?

I came across this problem too today (I am currently packaging 6.4 into an
RPM for Red Hat 5.2). I have generated a patch file which fixes the lack
of -lcrypt in a number of places for glibc systems. After I have
thoroughly tested it I'll try to post it here.

Also, PgAccess version that has been included in 6.4 final version is
0.90 , but current stable version is 0.91
(ftp://ftp.flex.ro/pub/pgaccess/pgaccess-0.91.tar.gz)

Thanks for the pointer. I will incorporate that as another patch in
the .spec file for my Red Hat RPM.

--
Eric Lee Green eric@linux-hw.com http://www.linux-hw.com/~eric
"Linux represents a best-of-breed UNIX, that is trusted in mission
critical applications..." -- internal Microsoft memo

Eric Lee Green <eric@linux-hw.com> writes:

On Thu, 5 Nov 1998, Constantin Teodorescu wrote:

must manually add -lcrypt in Makefile into src/interfaces/libpgtcl

I came across this problem too today (I am currently packaging 6.4 into an
RPM for Red Hat 5.2). I have generated a patch file which fixes the lack
of -lcrypt in a number of places for glibc systems.

I believe this is already fixed in the current Postgres sources. Rather
than generating your own patch, would you verify that the current
sources are fixed?

You can get the current code from the Postgres CVS server --- see
http://www.postgresql.org/docs/faq-cvs.shtml. Do the checkout with
"-r REL6_4" to get the soon-to-be-6.4.1 stable branch, rather than
the 6.5 development branch...

regards, tom lane

(I am currently packaging 6.4 into an RPM for Red Hat 5.2).

Is this an alternative to the RedHat packaging, or are you using the
same layout and RPM setup that the RedHat 6.3 package had? Just curious;
I've been thinking about trying to help with RPM support but would be
happy that someone else is looking after it.

btw, we are currently looking at a date/time peculiarity in Postgres
with glibc2 which gives funny results for at least one test case. You
might want to stay in touch so we can fix that up for you also, once we
have a good workaround.

Actually, we should also test with RH5.2 to make sure the date/time
problem is still present, since it may have been due to a problem in
glibc2 which has since been fixed. I'm only running RH4.2 and RH5.1 so
can't directly test that myself...

- Tom

(I am currently packaging 6.4 into an RPM for Red Hat 5.2).

Is this an alternative to the RedHat packaging, or are you using the
same layout and RPM setup that the RedHat 6.3 package had? Just curious;
I've been thinking about trying to help with RPM support but would be
happy that someone else is looking after it.

btw, we are currently looking at a date/time peculiarity in Postgres
with glibc2 which gives funny results for at least one test case. You
might want to stay in touch so we can fix that up for you also, once we
have a good workaround.

Actually, we should also test with RH5.2 to make sure the date/time
problem is still present, since it may have been due to a problem in
glibc2 which has since been fixed. I'm only running RH4.2 and RH5.1 so
can't directly test that myself...

I am running PG 6.4 on RH5.2. If you give me the details I can try a test.

On Sun, 6 Dec 1998, Tom Lane wrote:

Eric Lee Green <eric@linux-hw.com> writes:

On Thu, 5 Nov 1998, Constantin Teodorescu wrote:

must manually add -lcrypt in Makefile into src/interfaces/libpgtcl

I came across this problem too today (I am currently packaging 6.4 into an
RPM for Red Hat 5.2). I have generated a patch file which fixes the lack
of -lcrypt in a number of places for glibc systems.

I believe this is already fixed in the current Postgres sources. Rather
than generating your own patch, would you verify that the current
sources are fixed?

Hi, Tom. I'll see if I can do that, but be forewarned that I will not be
able to actually run the "current" Postgres sources in order to actually
test it. I am working on a database application, not on Postgres, and I
have to maintain a stable Postgres on my development machine. The reason
I'm working on the 6.4 RPM for Red Hat 5.2 is for deployment purposes, not
for testing purposes, though of course I'll test it before deploying it.
(I want the latest stable version possible for deployment, because once
deployed, it will be out there for a LONG time).

BTW, congrats to everybody on an excellent job. I examined several
databases, including some commercial ones, and for everything but speed
PostgreSQL measured up nicely. And speed wasn't THAT bad, certainly quite
acceptable for my purposes (and definitely a lot faster than it used to
be!).

--
Eric Lee Green eric@linux-hw.com http://www.linux-hw.com/~eric
"Linux represents a best-of-breed UNIX, that is trusted in mission
critical applications..." -- internal Microsoft memo

On Sun, 6 Dec 1998, Thomas G. Lockhart wrote:

(I am currently packaging 6.4 into an RPM for Red Hat 5.2).

Is this an alternative to the RedHat packaging, or are you using the
same layout and RPM setup that the RedHat 6.3 package had? Just curious;

I am using the same layout and RPM setup that the Red Hat 6.3 package
had, but I had to make a fair number of changes to their setup to make
6.4 work. I think I probably ended up changing about 1/3rd of the
"action" portions of their .spec file, and the patch file I used to
make it install and link cleanly was generated from scratch. I am not
doing this for Red Hat Software, I am doing it because I need to
deploy 6.4 and doing it via RPM is the easiest way to deploy on Red
Hat. And perhaps more importantly, I'm doing it because it's there
:-).

I've been thinking about trying to help with RPM support but would be
happy that someone else is looking after it.

Well, if you have some suggestions I'm certainly not loathe to ignore them!
Right now, the only suggestion I can think of that I'd like to implement
would be to somehow figure out how to compile the Python module at the same
time that I compile the rest of it, but I'm not sure that Python is capable
yet of doing that Perl trick of compiling a module against the Perl .so
link library without having the source code around. I'll have to check
with the Python gurus on that one.

Actually, we should also test with RH5.2 to make sure the date/time
problem is still present, since it may have been due to a problem in
glibc2 which has since been fixed. I'm only running RH4.2 and RH5.1 so
can't directly test that myself...

Well, RH5.2 is still using glibc 2.0.7, albeit patched up about 10
more times since RH 5.1 :-). But sure, if you have a test case to run,
drop it in the mail to me and I'll be happy to run it.

One thought: Do you have a TZ environment variable set on your RH5.1?
I don't remember whether glibc needs one or not (I know there were other
programs sensitive to the TZ environment variable under RH5.1, like BRU,
but it is 12:30am here on the east coast and my mind is not as clear as
it should be :-).

--
Eric Lee Green eric@linux-hw.com http://www.linux-hw.com/~eric
"Linux represents a best-of-breed UNIX, that is trusted in mission
critical applications..." -- internal Microsoft memo

Eric Lee Green <eric@linux-hw.com> writes:

I have to maintain a stable Postgres on my development machine. The reason
I'm working on the 6.4 RPM for Red Hat 5.2 is for deployment purposes, not
for testing purposes, though of course I'll test it before deploying it.
(I want the latest stable version possible for deployment, because once
deployed, it will be out there for a LONG time).

Fair enough. I have not been around Postgres very long and may be out
of line to make this remark, but here goes anyway: as far as I've seen,
the minor releases (6.3.2, 6.4.1, etc) are likely to be your best bet
for a solid install-and-forget version. Major releases are for feature
additions, minor releases are made to clean up whatever got broken.
We do the best we can to test major releases before they go out, but
things do slip through the cracks sometimes.

In short, unless you need something in the next few days, the upcoming
6.4.1 release is likely to be a better bet for an RPM distribution
than 6.4.

Perhaps one of the senior Postgres guys would like to expound on the
release philosophy? The above is just what I've observed, it may
not be the official policy...

regards, tom lane