> No magic, but common sense once you have tried it: > > $ tar xzfproftpd-9.9.9.tar.gz > $ mkdir build > $ cd build > > $ ../proftpd-9.9.9/configure --localstatedir=/var/run --enable-openssl > \ > --with-modules=mod_tls > [the usual output] > $ make > $ sudo make install
The above should now work correctly; I've turned your patch into a PR, and included more changes for supporting multi-file module builds, the NLS files, running unit tests, etc: https://github.com/proftpd/proftpd/pull/412 And hopefully this will let us finally close out the long-standing request for this functionality: http://bugs.proftpd.org/show_bug.cgi?id=3127 > I found two non-standard behaviours while getting the install target to > work. > Usually I make a two-step install when building software: > > $ make DESTDIR=/tmp/blind install > [check for irregularites, partially script aided] > $ sudo make install > > It turned out, however, that the main product 'proftpd' is built twice, > at first during the default target, then again during the install target, > because it is produced by linking object files and libraries once more. > Somehow I am under the impression that something is not optimal there, > but I am uncertain as exactly what is happening. Libtool? I think it is not libtool, but rather the dependencies declared for the "proftpd$(EXEEXT)" target, i.e. the list of directory names. The Makefiles in those directories may touch/update the timestamps on the object files/archives, thus later `make` may think it needs to relink the `proftpd` executable. Definitely something to improve, but I'd like to address that separately. Cheers, TJ ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ ProFTPD Developers List <[email protected]> https://lists.sourceforge.net/lists/listinfo/proftp-devel
