[tpop3d-discuss] auth_passwd problems with 1.5.1

[Travis Miller]

Chris, I think I figured it out.

It is problem with the linking order of libcrypt. When I configure with:

./configure \
--prefix=/usr \
--sysconfdir=/etc \
--localstatedir=/var \
--disable-auth-pam \
--enable-auth-passwd \
--enable-shadow-passwords \
--enable-mbox-bsd \
--disable-dotfile-locking \
--enable-tls \
--with-openssl-root=/usr/local/openssl

In the Makefile we get:
LIBS = -lssl -lcrypto -lcrypt

However if this is reordered to:
LIBS = -lcrypt -lssl -lcrypto

Everthing seems to work great.

- Travis




Chris Lightfoot wrote:
> (This is baffling me. That code hasn't changed since
> 1.4.1.)
> 
> On Wed, Aug 20, 2003 at 02:59:13PM -0500, Travis Miller wrote:
> 
>>>can you try (a) compiling test.c without -lcrypt;
>>
>>root@mailtest:/home/test# gcc test.c -o test
>>/tmp/ccuP56Q0.o: In function `main':
>>/tmp/ccuP56Q0.o(.text+0x28): undefined reference to `crypt'
>>collect2: ld returned 1 exit status
> 
> 
> OK... and compiling it with -lcrypt and running ldd on the
> result?
> 
> 
>>
>>>(b) running ldd on the tpop3d binary?
>>
>>root@mailtest:/home/test/tpop3d-1.5.1# ldd tpop3d
>>        libcrypt.so.1 => /lib/libcrypt.so.1 (0x40017000)
>>        libc.so.6 => /lib/libc.so.6 (0x40045000)
>>        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
>>
>>
>>
>>And for a reference, here is ldd on my older, working tpop3d binary:
>>
>>root@mailtest:/home/test/tpop3d-1.5.1# ldd /usr/sbin/tpop3d.working
>>        libmysqlclient.so.10 => 
>>/usr/local/mysql/lib/mysql/libmysqlclient.so.10 (0x40017000)
>>        libcrypt.so.1 => /lib/libcrypt.so.1 (0x40035000)
>>        libc.so.6 => /lib/libc.so.6 (0x40062000)
>>        libz.so.1 => /usr/lib/libz.so.1 (0x4014c000)
>>        libnsl.so.1 => /lib/libnsl.so.1 (0x4015b000)
>>        libm.so.6 => /lib/libm.so.6 (0x40170000)
>>        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
>>
>>That is, of course, with MySQL support enabled....
> 
> 
> Can you run strings or nm on each of those libraries to
> see if any of them (other than libcrypt, obviously)
> contain a crypt(3) implementation.
>