Re: Various bugs with PG7.1 8th March snapshot on Solaris 8INTEL
От | Larry Rosenman |
---|---|
Тема | Re: Various bugs with PG7.1 8th March snapshot on Solaris 8INTEL |
Дата | |
Msg-id | 20010325151242.A7390@lerami.lerctr.org обсуждение исходный текст |
Ответ на | Re: Various bugs with PG7.1 8th March snapshot on Solaris 8 INTEL (Peter Eisentraut <peter_e@gmx.net>) |
Список | pgsql-bugs |
* 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
В списке pgsql-bugs по дате отправления: