Thread: Various bugs with PG7.1 8th March snapshot on Solaris 8 INTEL
Hi all,
Sorry for sending this directly as an email. The Bug Form on the
PostgreSQL webpage keeps on timing out on me. (Server overload?)
These are five errors/bugs and solutions from the 8th March 2001
PostgreSQL 7.1 snapshot.
The system :
Solaris 8 INTEL (10/00 release as available for download from Sun)
Maintenance Update 3 installed, recommended patches installed.
128 MB RAM
2 x 400 Mhz CPU's
GCC 2.95.2
GNU Make 3.79.1
GNU Flex 2.5.4
GNU Bison 1.28
OpenSSL 0.9.6 installed
Didn't have readline installed
General other GNU utils installed, nothing weird.
This system is known to be stable and doesn't generally have compilation
problems.
Compilation command :
./configure --p=/opt/postgresql71 --enable-syslog
--with-openssl=/opt/openssl
*** 1 ***
Firstly there is a complation error :
When --with-openssl=<the path to my openssl dir> is given to configure
on Solaris 8 INTEL, the compilation errors in :
- src/backend/libpg/crypt.c (line 26)
- src/backend/libpg/password.c (line 14)
- src/interfaces/libpq/fe-auth.c (line 49)
- src/interfaces/libpq/fe-connect.c (line 43)
because of :
#ifdef HAVE_CRYPT_H
#include <crypt.h>
#endif
Seems to be causing a conflict with the built in /usr/include/crypt.h
and the <openssl dir>/include/openssl/des.h
The error given by the compilation process is (this one's for
fe-connect.c):
make[3]: Entering directory
`/install/new2/postgresql-snapshot/src/interfaces/libpq'
gcc -Wall -Wmissing-prototypes -Wmissing-declarations -fPIC -I.
-I../../../src/include -I/opt/openssl/include -DFRONTEND
-DSYSCONFDIR='"/opt/postgresql71/etc"' -c -o fe-connect.o fe-connect.c
In file included from fe-connect.c:44:
/usr/include/crypt.h:23: conflicting types for `des_encrypt'
/opt/openssl/include/openssl/des.h:150: previous declaration of
`des_encrypt'
make[3]: *** [fe-connect.o] Error 1
make[3]: Leaving directory
`/install/new2/postgresql-snapshot/src/interfaces/libpq'
make[2]: *** [all] Error 2
make[2]: Leaving directory
`/install/new2/postgresql-snapshot/src/interfaces'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/install/new2/postgresql-snapshot/src'
make: *** [all] Error 2
I fixed this by just commenting out the #ifdef section and it's included
<crypt.h> in each of these 4 files. Compiles fine after this.
*** 2 ***
Next problem is that running 'gmake check' expects to find the new
'postgres' file in the normal PATH, not in the temporary installation
PATH. I deduce this from the ./src/test/regress/log/initdb.log file
which complains about not being able to find the 'postgres' file in the
installation location.
Here's the relevant error from 'gmake check' :
<snip>
============== creating temporary installation ==============
============== initializing database system ==============
pg_regress: initdb failed
Examine ./log/initdb.log for the reason.
make[2]: *** [check] Error 2
rm regress.o
make[2]: Leaving directory
`/install/new2/postgresql-snapshot/src/test/regress'
make[1]: *** [check] Error 2
make[1]: Leaving directory `/install/new2/postgresql-snapshot/src/test'
make: *** [check] Error 2
bash-2.03$ echo $PATH
/usr/local/bin:/usr/bin:/usr/openwin/bin:/usr/ccs/bin:/opt/postgresql71/bin:/usr/dt/bin:/usr/local/qt/bin:/usr/games:/opt/kde/bin
bash-2.03$ more src/test/regress/log/initdb.log
The program 'postgres' is needed by initdb but was not found in
the directory '/opt/postgresql71/bin'. Check your installation.
bash-2.03$ find . -name "postgres" -type f
./src/backend/postgres
./src/test/regress/tmp_check/install/opt/postgresql71/bin/postgres
bash-2.03$
*** 3 ***
A third problem and solution is this misleading error message :
Even after doing a 'make install' to ensure the above make check will
find the files it's after, I get this :
bash-2.03$ make install
<snipped installation stuff>
bash-2.03$ make check
<snipped general make check stuff>
============== removing existing temp installation ==============
============== creating temporary installation ==============
============== initializing database system ==============
pg_regress: initdb failed
Examine ./log/initdb.log for the reason.
make[2]: *** [check] Error 2
make[2]: Leaving directory
`/install/new2/postgresql-snapshot/src/test/regress'
make[1]: *** [check] Error 2
make[1]: Leaving directory `/install/new2/postgresql-snapshot/src/test'
make: *** [check] Error 2
bash-2.03$ more src/test/regress/log/initdb.log
The program '/opt/postgresql71/bin/postgres' needed by initdb does not
belong to PostgreSQL version 7.1beta5. Check your installation.
bash-2.03$
This sounded like I had a bad PATH, or existing PostgreSQL files in
LD_LIBRARY_PATH or something.
After investigating a bit futher, the reason for the error message was
really that I didn't have the path to the openssl library files in
LD_LIBRARY_PATH :
$ initdb
The program '/opt/postgresql71/bin/postgres' needed by initdb does not
belong to PostgreSQL version 7.1beta5. Check your installation.
$ cd /opt/postgresql71/bin
$ ./postgres -version
ld.so.1: ./postgres: fatal: libssl.so.0: open failed: No such file or
directory
Killed
$ echo $LD_LIBRARY_PATH
/opt/postgresql71/lib
$ LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/openssl/lib
$ export LD_LIBRARY_PATH
$ ./postgres -version
FATAL 1: Can't create lock file /opt/postgresql71/data/postmaster.pid:
No such file or directory
$ initdb
This database system will be initialized with username "postgres".
This user will own all the data files and must also own the server
process.
Creating directory /opt/postgresql71/data
Creating directory /opt/postgresql71/data/base
Creating directory /opt/postgresql71/data/global
Creating directory /opt/postgresql71/data/pg_xlog
Creating template1 database in /opt/postgresql71/data/base/1
DEBUG: starting up
DEBUG: database system was shut down at 2001-03-12 18:08:15
DEBUG: CheckPoint record at (0, 8)
DEBUG: Redo record at (0, 8); Undo record at (0, 8); Shutdown TRUE
DEBUG: NextTransactionId: 514; NextOid: 16384
DEBUG: database system is in production state
Creating global relations in /opt/postgresql71/data/global
DEBUG: starting up
DEBUG: database system was shut down at 2001-03-12 18:08:18
DEBUG: CheckPoint record at (0, 112)
DEBUG: Redo record at (0, 112); Undo record at (0, 0); Shutdown TRUE
DEBUG: NextTransactionId: 514; NextOid: 17199
DEBUG: database system is in production state
Initializing pg_shadow.
Enabling unlimited row width for system tables.
Creating system views.
Loading pg_description.
Setting lastsysoid.
Vacuuming database.
Copying template1 to template0.
Success. You can now start the database server using:
/opt/postgresql71/bin/postmaster -D /opt/postgresql71/data
or
/opt/postgresql71/bin/pg_ctl -D /opt/postgresql71/data start
$
So.. suddenly it works. After finding this out, I set the
LD_LIBRARY_PATH to include the openssl libraries and did another make
check in the src/test/regress directory and this time it worked.
So, I don't know how you would do it, but I believe the error message
about the version of 'postgres' not belonging to 7.1beta5 to be really
misleading, as what it should be complaining about is not being able to
find the openssl libraries.
*** 4 ***
In the regression test side of things, Solaris 8 INTEL seems be having
troubles with handling int8 types. Not sure if this is a known
problem. The int8 tests failed with error messages like :
INSERT INTO INT8_TBL VALUES('123','4567890123456789');
+ ERROR: int8 value out of range: "4567890123456789"
Naturally, the rest of the int8 tests didn't complete nicely as the data
wasn't there to test with. The subselect and union tests also failed in
the parts that were to do with int8, due to these large numbers it
doesn't seem to be able to handle.
*** 5 ***
'Make clean' doesn't work :
$ make clean
make -C doc clean
make[1]: Entering directory `/install/new2/postgresql-snapshot/doc'
make[1]: Nothing to be done for `clean'.
make[1]: Leaving directory `/install/new2/postgresql-snapshot/doc'
make -C contrib clean
make[1]: Entering directory `/install/new2/postgresql-snapshot/contrib'
for dir in array cube earthdistance findoidjoins fulltextindex intarray
isbn_issn lo mSQL-interface mac miscutil noupdate oid2name pg_dumplo
pg_logger pgbench pgcrypto rserv seg soundex spi string tips unixdate
userlock vacuumlo ; do \
if [ -e $dir/Makefile ]; then \
make -C $dir clean; \
fi; \
done
/bin/sh: test: argument expected
make[1]: *** [clean] Error 1
make[1]: Leaving directory `/install/new2/postgresql-snapshot/contrib'
make: *** [clean] Error 2
$
At this stage, I was tired and grumpy and Couldn't Be Bothered checking
which Makefile had the error in it. :-/
Regards and best wishes,
Justin Clift
Justin Clift writes:
> When --with-openssl=<the path to my openssl dir> is given to configure
> on Solaris 8 INTEL, the compilation errors in :
This is an OpenSSL namespace problem on some platforms (Solaris, Unixware
so far). Nothing we can really do about it.
> Next problem is that running 'gmake check' expects to find the new
> 'postgres' file in the normal PATH, not in the temporary installation
> PATH. I deduce this from the ./src/test/regress/log/initdb.log file
> which complains about not being able to find the 'postgres' file in the
> installation location.
> The program 'postgres' is needed by initdb but was not found in
> the directory '/opt/postgresql71/bin'. Check your installation.
Odd. The initdb program first tries the path that itself is in and then
the path that it is *supposed* to be in:
if echo "$0" | grep '/' > /dev/null 2>&1
then
# explicit dir name given
self_path=`echo $0 | sed 's,/[^/]*$,,'` # (dirname command is not portable)
else
# look for it in PATH ('which' command is not portable)
for dir in `echo "$PATH" | sed 's/:/ /g'`
do
# empty entry in path means current dir
[ -z "$dir" ] && dir='.'
if [ -f "$dir/$CMDNAME" ]
then
self_path="$dir"
break
fi
done
fi
The regression test script should always invoke the first case ($0 starts
contains '/'). Apparently, in your case something went wrong there and it
tries looking for it in PATH. Can you see why that is the case? (E.g,
run gmake check SHELL='/bin/sh -x' or sh -x initdb.)
> A third problem and solution is this misleading error message :
> After investigating a bit futher, the reason for the error message was
> really that I didn't have the path to the openssl library files in
> LD_LIBRARY_PATH :
>
> $ initdb
> The program '/opt/postgresql71/bin/postgres' needed by initdb does not
> belong to PostgreSQL version 7.1beta5. Check your installation.
>
> $ cd /opt/postgresql71/bin
> $ ./postgres -version
> ld.so.1: ./postgres: fatal: libssl.so.0: open failed: No such file or
> directory
> Killed
The problem here is that we can't really distinguish this failure from
other failures (such as not implementing the --version option), so I don't
know how to make the error message better. I suppose we could capture the
stderr and print it to the screen. In fact, I'll try that. However,
another way to view this problem is that the OpenSSL libraries weren't
linked properly.
> In the regression test side of things, Solaris 8 INTEL seems be having
> troubles with handling int8 types. Not sure if this is a known
> problem. The int8 tests failed with error messages like :
>
> INSERT INTO INT8_TBL VALUES('123','4567890123456789');
> + ERROR: int8 value out of range: "4567890123456789"
Ugh. Did configure detect a working 64 bit integer? HAVE_LONG_INT_64 and
HAVE_LONG_LONG_INT_64 should be defined in config.h.
> if [ -e $dir/Makefile ]; then \
> make -C $dir clean; \
> fi; \
> done
> /bin/sh: test: argument expected
I see. 'test -e' is known to be missing on Solaris. Will fix.
--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
Peter Eisentraut <peter_e@gmx.net> writes:
> Justin Clift writes:
>> In the regression test side of things, Solaris 8 INTEL seems be having
>> troubles with handling int8 types. Not sure if this is a known
>> problem. The int8 tests failed with error messages like :
>>
>> INSERT INTO INT8_TBL VALUES('123','4567890123456789');
>> + ERROR: int8 value out of range: "4567890123456789"
> Ugh. Did configure detect a working 64 bit integer?
IIRC, someone else reported a few days ago that the int8 tests failed on
their platform if and only if openssl was linked in. Not sure what
openssl could be doing to screw up long long int arithmetic, but that
was the report.
regards, tom lane
Tom Lane writes: > IIRC, someone else reported a few days ago that the int8 tests failed on > their platform if and only if openssl was linked in. Not sure what > openssl could be doing to screw up long long int arithmetic, but that > was the report. Of course! The test program aborts because it can't find the shared library. Yet another reason to avoid AC_TRY_RUN. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
Peter Eisentraut <peter_e@gmx.net> writes:
>> IIRC, someone else reported a few days ago that the int8 tests failed on
>> their platform if and only if openssl was linked in. Not sure what
>> openssl could be doing to screw up long long int arithmetic, but that
>> was the report.
> Of course! The test program aborts because it can't find the shared
> library. Yet another reason to avoid AC_TRY_RUN.
Er ... what? Why would the test program be trying to use that shlib?
regards, tom lane
Tom Lane writes: > Peter Eisentraut <peter_e@gmx.net> writes: > >> IIRC, someone else reported a few days ago that the int8 tests failed on > >> their platform if and only if openssl was linked in. Not sure what > >> openssl could be doing to screw up long long int arithmetic, but that > >> was the report. > > > Of course! The test program aborts because it can't find the shared > > library. Yet another reason to avoid AC_TRY_RUN. > > Er ... what? Why would the test program be trying to use that shlib? Because -lssl is added to LIBS, the test program is linked against LIBS, and when the program starts it tries to locate all the dependent libraries (not matter if it doesn't actually have to use them). -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
Peter Eisentraut <peter_e@gmx.net> writes:
> Of course! The test program aborts because it can't find the shared
> library. Yet another reason to avoid AC_TRY_RUN.
>>
>> Er ... what? Why would the test program be trying to use that shlib?
> Because -lssl is added to LIBS, the test program is linked against LIBS,
> and when the program starts it tries to locate all the dependent libraries
> (not matter if it doesn't actually have to use them).
Interesting theory, but if LIBS is broken then wouldn't the backend fail
to run at all? How'd they manage to pass the other regress tests?
regards, tom lane
Tom Lane writes:
> >> Er ... what? Why would the test program be trying to use that shlib?
>
> > Because -lssl is added to LIBS, the test program is linked against LIBS,
> > and when the program starts it tries to locate all the dependent libraries
> > (not matter if it doesn't actually have to use them).
>
> Interesting theory, but if LIBS is broken then wouldn't the backend fail
> to run at all? How'd they manage to pass the other regress tests?
Presumably the backend would print an error message along the lines of
"cannot find shared library libxyz.so" and the user would take appropriate
configuration steps. However, this doesn't really help when running
configure because no user actually reads every 'checking...' line and
tries to challenge the result by examining config.log.
The same problem occurs when the backend is run from within initdb to
check the version. If there's a shared library loading problem the
postgres --version invocation will fail and the user will see a misleading
error message. I'm currently changing it to print the backend's stderr if
any was provided, so I now get
$ pg-install/bin/initdb pg-install/var/data
The program
'/home/peter/pg-install/bin/postgres'
needed by initdb does not belong to PostgreSQL version 7.1beta5, or
there may be a configuration problem.
This was the error message issued by that program:
cannot open shared library libxyz.so
(Here I replaced 'postgres' with a simple shell script.)
--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane writes:
>> Interesting theory, but if LIBS is broken then wouldn't the backend fail
>> to run at all? How'd they manage to pass the other regress tests?
> Presumably the backend would print an error message along the lines of
> "cannot find shared library libxyz.so" and the user would take appropriate
> configuration steps. However, this doesn't really help when running
> configure because no user actually reads every 'checking...' line and
> tries to challenge the result by examining config.log.
Oh, I see: you posit that the user fixed the shlib configuration problem
after discovering the backend wouldn't run, but did not then go back and
re-run configure. Yes, that makes sense. Justin, are the INT64 flags
in your config.h wrong?
> Yet another reason to avoid AC_TRY_RUN.
The tests that we have to see whether 64-bit arithmetic actually works
are probably just unnecessary paranoia. However, the tests to see
whether snprintf does the right thing, and with what format flags,
still seem necessary; and I see no way to handle those without a runtime
check.
Maybe the AC_TRY_RUN tests could be moved up to before we start probing
for libraries?
regards, tom lane
Tom Lane writes: > Maybe the AC_TRY_RUN tests could be moved up to before we start probing > for libraries? The overall order of the tests should stay this way, I think. Some library could actually alter the result of a run test. (Think about some -lcompat or -lbsd getting in the way, not unlikely at all with snprintf.) Instead we could run an empty test program before the real tests. If an empty program fails to run we can abort in good conscience. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
Peter Eisentraut <peter_e@gmx.net> writes:
> Instead we could run an empty test program before the real tests. If an
> empty program fails to run we can abort in good conscience.
That sounds like a plan. Do you want to do it, or shall I?
regards, tom lane
Hi Tom,
Sorry for taking so long to get back to this stuff. Being busy in Life.
Has anything else regarding general broken int8 tests been found out,
with regards to it being caused by OpenSSL. If that's the case
shouldn't we ask the OpenSSL guys about known issues, or at least let
them know that something may be wrong?
They're up to beta2 of their next release so now's probably the time to
work things out.
Regards and best wishes,
Justin Clift
Tom Lane wrote:
>
> Peter Eisentraut <peter_e@gmx.net> writes:
> > Justin Clift writes:
> >> In the regression test side of things, Solaris 8 INTEL seems be having
> >> troubles with handling int8 types. Not sure if this is a known
> >> problem. The int8 tests failed with error messages like :
> >>
> >> INSERT INTO INT8_TBL VALUES('123','4567890123456789');
> >> + ERROR: int8 value out of range: "4567890123456789"
>
> > Ugh. Did configure detect a working 64 bit integer?
>
> IIRC, someone else reported a few days ago that the int8 tests failed on
> their platform if and only if openssl was linked in. Not sure what
> openssl could be doing to screw up long long int arithmetic, but that
> was the report.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/users-lounge/docs/faq.html
--
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
Hi Peter, Can't this be at least worked around by ./configure detecting there will be a conflict (i.e. being compiled with OpenSSL support on Solaris or Unixware) then creating something like #define OPENSSL_DES_ENCRYPT_NAMESPACE_CONFLICT in the Makefile, and then having crypt.c (etc) check for this and not #include <crypt.h> ? Things compile fine without <crypt.h> being included, in the case of OpenSSL support being needed. As the problem appears to be in already-released versions of OpenSSL, wouldn't the best approach be to notify the OpenSSL guys (they're decent people, and CC'ing this now to their developer list) and also work around the problem ourselves? Regards and best wishes, + Justin Clift Peter Eisentraut wrote: > > Justin Clift writes: > > > When --with-openssl=<the path to my openssl dir> is given to configure > > on Solaris 8 INTEL, the compilation errors in : > > This is an OpenSSL namespace problem on some platforms (Solaris, Unixware > so far). Nothing we can really do about it.
Justin Clift writes: > Has anything else regarding general broken int8 tests been found out, > with regards to it being caused by OpenSSL. If that's the case > shouldn't we ask the OpenSSL guys about known issues, or at least let > them know that something may be wrong? This has been fixed. It was a linker problem. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
Peter Eisentraut <peter_e@gmx.net> writes:
> Justin Clift writes:
>> Has anything else regarding general broken int8 tests been found out,
>> with regards to it being caused by OpenSSL. If that's the case
>> shouldn't we ask the OpenSSL guys about known issues, or at least let
>> them know that something may be wrong?
> This has been fixed. It was a linker problem.
We think, anyway. At least we found a plausible mechanism for the
failure...
regards, tom lane
* Justin Clift <jclift@iprimus.com.au> [010325 07:34]: > Hi Peter, > > Can't this be at least worked around by ./configure detecting there will > be a conflict (i.e. being compiled with OpenSSL support on Solaris or > Unixware) then creating something like #define > OPENSSL_DES_ENCRYPT_NAMESPACE_CONFLICT in the Makefile, and then having > crypt.c (etc) check for this and not #include <crypt.h> ? > > Things compile fine without <crypt.h> being included, in the case of > OpenSSL support being needed. As the problem appears to be in > already-released versions of OpenSSL, wouldn't the best approach be to > notify the OpenSSL guys (they're decent people, and CC'ing this now to > their developer list) and also work around the problem ourselves? I've been in contact with an OpenSSL guy, and given him a shell account here. He's looking into it. LER > > Regards and best wishes, > > + Justin Clift > > Peter Eisentraut wrote: > > > > Justin Clift writes: > > > > > When --with-openssl=<the path to my openssl dir> is given to configure > > > on Solaris 8 INTEL, the compilation errors in : > > > > This is an OpenSSL namespace problem on some platforms (Solaris, Unixware > > so far). Nothing we can really do about it. > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster -- 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
* Richard Levitte - VMS Whacker <levitte@stacken.kth.se> [010325 14:41]: > From: Larry Rosenman <ler@lerctr.org> > > ler> * Justin Clift <jclift@iprimus.com.au> [010325 07:34]: > ler> > Hi Peter, > ler> > > ler> > Can't this be at least worked around by ./configure detecting there will > ler> > be a conflict (i.e. being compiled with OpenSSL support on Solaris or > ler> > Unixware) then creating something like #define > ler> > OPENSSL_DES_ENCRYPT_NAMESPACE_CONFLICT in the Makefile, and then having > ler> > crypt.c (etc) check for this and not #include <crypt.h> ? > ler> > > ler> > Things compile fine without <crypt.h> being included, in the case of > ler> > OpenSSL support being needed. As the problem appears to be in > ler> > already-released versions of OpenSSL, wouldn't the best approach be to > ler> > notify the OpenSSL guys (they're decent people, and CC'ing this now to > ler> > their developer list) and also work around the problem ourselves? > ler> I've been in contact with an OpenSSL guy, and given him a shell > ler> account here. He's looking into it. > > The problem is how to make it smoothe. I'm open for suggestions. And > it's not as simple as just skipping compilation of des_encrypt() in > OpenSSL, because it's needed internally. I've no idea if the bast way > is really to rename the function or something else. Just removing it > from the exported headers is *not* the solution, because there will > still be a name clash, the only difference being that ld won't make a > fuss about it, and the OpenSSL implementation will most probably win, > making those who call it thinking it's the libc ds_encrypt() loosers! I suspect renaming it would be the best way, since we have 2 major (SUN, SCO) vendors claiming a des_encrypt() function in their libcrypt and/or libc. 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
That sounds like The Right Way of doing it; most responsible, technically sound, etc. Regards and best wishes, Justin Clift Larry Rosenman wrote: <snip> > I suspect renaming it would be the best way, since we have 2 major > (SUN, SCO) vendors claiming a des_encrypt() function in their libcrypt > and/or libc. > > 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 > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > Development Mailing List openssl-dev@openssl.org > Automated List Manager majordomo@openssl.org -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
Re: Various bugs with PG7.1 8th March snapshot on Solaris 8INTEL
From
Richard Levitte - VMS Whacker
Date:
From: Larry Rosenman <ler@lerctr.org> ler> * Justin Clift <jclift@iprimus.com.au> [010325 07:34]: ler> > Hi Peter, ler> > ler> > Can't this be at least worked around by ./configure detecting there will ler> > be a conflict (i.e. being compiled with OpenSSL support on Solaris or ler> > Unixware) then creating something like #define ler> > OPENSSL_DES_ENCRYPT_NAMESPACE_CONFLICT in the Makefile, and then having ler> > crypt.c (etc) check for this and not #include <crypt.h> ? ler> > ler> > Things compile fine without <crypt.h> being included, in the case of ler> > OpenSSL support being needed. As the problem appears to be in ler> > already-released versions of OpenSSL, wouldn't the best approach be to ler> > notify the OpenSSL guys (they're decent people, and CC'ing this now to ler> > their developer list) and also work around the problem ourselves? ler> I've been in contact with an OpenSSL guy, and given him a shell ler> account here. He's looking into it. The problem is how to make it smoothe. I'm open for suggestions. And it's not as simple as just skipping compilation of des_encrypt() in OpenSSL, because it's needed internally. I've no idea if the bast way is really to rename the function or something else. Just removing it from the exported headers is *not* the solution, because there will still be a name clash, the only difference being that ld won't make a fuss about it, and the OpenSSL implementation will most probably win, making those who call it thinking it's the libc ds_encrypt() loosers! -- Richard Levitte \ Spannvägen 38, II \ LeViMS@stacken.kth.se Chairman@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 Redakteur@Stacken \ SWEDEN \ or +46-709-50 36 10 Procurator Odiosus Ex Infernis -- poei@bofh.se Member of the OpenSSL development team: http://www.openssl.org/ Software Engineer, Celo Communications: http://www.celocom.com/ Unsolicited commercial email is subject to an archival fee of $400. See <http://www.stacken.kth.se/~levitte/mail/> for more info.