Any of the flags (ldap postgresql sqlite ssl clamav) causes proftpd to behave as in proftpd_bug 3702. I think this is because /usr/sbin/proftpd is linked with libthr.so.3. I am opening this bug because I can't reproduce this on the pure FreeBSD (I'll try prefix soon). FreeBSD's port uses `--with-shared` instead of `--with-modules` and proftpd is never linked with libthr.so.3. If I place `--with-shared` into ebuild, proftpd got linked with libthr.so.3 for any use-flag (postgres sqlite ssl), USE="ldap" no longer affects, USE="clamav" fails to compile. Reproducible: Always Steps to Reproduce: 1. emerge net-ftp/proftpd with any flag (ldap postgresql sqlite ssl openssl) 2. # /usr/sbin/proftpd -n 3. wait 15 sec Actual Results: # Alarm clock: 14 proftpd stopped Expected Results: proftpd should continue to work Everything is fine on fbsd-8.2, proftpd linked with libthr.so.3.
# lddtree /usr/sbin/proftpd proftpd => /usr/sbin/proftpd (interpreter => /libexec/ld-elf.so.1) libcrypt.so.5 => /usr/lib/libcrypt.so.5 libiconv.so.2 => /lib/libiconv.so.2 libintl.so.9 => /lib/libintl.so.9 libpcreposix.so.0 => /usr/lib/libpcreposix.so.0 libpcre.so.0 => /lib/libpcre.so.0 libssl.so.1.0.0 => /usr/lib/libssl.so.1.0.0 libthr.so.3 => /lib/libthr.so.3 libcrypto.so.1.0.0 => /usr/lib/libcrypto.so.1.0.0 libz.so.1 => /lib/libz.so.1 libpam.so.2 => /usr/lib/libpam.so.2 libc.so.7 => /lib/libc.so.7 libssl.1.0.0 is linked to libthr.so.3 and seems this is causeing the problem. Could you provide "ldd /usr/lib/libssl.so" on vanilla FreeBSD?
(In reply to comment #1) > libssl.1.0.0 is linked to libthr.so.3 and seems this is causeing the > problem. Could you provide "ldd /usr/lib/libssl.so" on vanilla FreeBSD? # ldd /usr/lib/libssl.so /usr/lib/libssl.so: libcrypto.so.6 => /lib/libcrypto.so.6 (0x2820c000) libc.so.7 => /lib/libc.so.7 (0x28093000)
Created attachment 316597 [details, diff] ./files/proftpd-1.3.4a-pthread.patch OK, then the problem is as same as proftpd bug 3702. Proftpd doesn't link against -pthread even openssl is built to be threaded. On Gentoo, we build openssl threaded, so we can just avoid this problem patching the configure script like the attachment. I've just confirmed it worked fine on Gentoo/FreeBSD. I feel improving upstream code a bit difficut, because I don't know how we can detect if openssl is build to be threaded or not.
Any comment from proftpd package maintainer?
(In reply to comment #4) > Any comment from proftpd package maintainer? I received email from TJ Saunders. He opened separate bug: http://bugs.proftpd.org/show_bug.cgi?id=3795 and committed a possible fix. Unfortunately, I have not yet had time to check it out.
A few days ago TJ Saunders commited a patch for ProFTPD CVS and a backport for ProFTPD 1.3.4 which should fix this issue. His patch checks if openssl was built with '-pthread' and in that case it builds ProFTPD with '-pthread', too. In the next days I will test his backport and provide a proftpd-1.3.4a-r2.ebuild for further testing with Gentoo/FreeBSD. Thanks for reporting this issue.
Dmitri & Naohiro, please test the following 'proftpd-1.3.4a-r2.ebuild' with the backported patch 'proftpd-1.3.4a-ubug-3795.patch' on your Gentoo/FreeBSD machines. As soon as you can confirm that this ebuild fixes that issue I will commit this revision bump to the portage tree. Thanks.
Created attachment 319322 [details] ProFTPD 1.3.4a r2 ebuild
Created attachment 319324 [details] ProFTPD 1.3.4a patch for upstream bug 3795
(In reply to comment #7) > Dmitri & Naohiro, please test the following 'proftpd-1.3.4a-r2.ebuild' with > the backported patch 'proftpd-1.3.4a-ubug-3795.patch' on your Gentoo/FreeBSD > machines. As soon as you can confirm that this ebuild fixes that issue I > will commit this revision bump to the portage tree. Thanks. It doesn't seems working. Why the new if is only tested only when postgresql is enabled? Are there dependency between openssl and postgresql?
Created attachment 321938 [details] ProFTPD 1.3.4b ebuild
Created attachment 321940 [details, diff] ProFTPD 1.3.4b patch for upstream bug #3795
(In reply to comment #10) > It doesn't seems working. During backporting the patch for this issue broke. I attached a ProFTPD 1.3.4b ebuild and the new backported patch for this problem. Dmitri & Naohiro, please verify that this new ebuild and patch are fixing the issue. Then I can commit the ProFTPD 1.3.4b ebuild to the portage tree. Thanks.
(In reply to comment #13) > (In reply to comment #10) > > It doesn't seems working. > During backporting the patch for this issue broke. I attached a ProFTPD > 1.3.4b ebuild and the new backported patch for this problem. Dmitri & > Naohiro, please verify that this new ebuild and patch are fixing the issue. > Then I can commit the ProFTPD 1.3.4b ebuild to the portage tree. Thanks. I've tried. Seems fine here. :)
1.3.4b with patch is in portage, thanks Bernd!
