Thread: crypt not included when compiling libpgtcl !!!!!!!
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 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) Constantin Teodorescu FLEX Consulting Braila, ROMANIA
> 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
Re: [HACKERS] Re: [INTERFACES] crypt not included when compiling libpgtcl !!!!!!!
From
Bruce Momjian
Date:
> 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
Re: [INTERFACES] crypt not included when compiling libpgtcl !!!!!!!
From
Constantin Teodorescu
Date:
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
Re: [INTERFACES] crypt not included when compiling libpgtcl !!!!!!!
From
Constantin Teodorescu
Date:
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
Re: [INTERFACES] crypt not included when compiling libpgtcl !!!!!!!
From
Constantin Teodorescu
Date:
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
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
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