In message <[EMAIL PROTECTED]> on Sat, 20 Apr
2002 09:51:44 -0700 (PDT), Doug Kaufman <[EMAIL PROTECTED]> said:
dkaufman> On Sat, 20 Apr 2002, Richard Levitte - VMS Whacker wrote:
[...]
dkaufman> > I understand the reasons behind several things you do, like the
dkaufman> > symlink hackery. However, I can't help but wonder why you do that at
dkaufman> > all in Configure when util/mklink.pl already deals with the situation,
dkaufman> > and would therefore properly take care of it when 'make links' is run.
dkaufman>
dkaufman> The problem is that util/mklink.pl only works with algorithms that
dkaufman> are included in the build. It is called from the makefile in each
dkaufman> subdirectory. When algorithms are excluded (e.g., by configureing with
dkaufman> no-idea), then mklink.pl is never called for the excluded directories
dkaufman> (e.g., crypto/idea). The symlink alternatives in Configure are made
dkaufman> only for the excluded algorithms (@skip). The other changes are in
dkaufman> mklink.pl. If you don't make the links for the excluded algorithms,
dkaufman> there will be errors, at least with the doing "make test". You may not
dkaufman> see this if your tar program makes the symbolic links on unpacking the
dkaufman> archive.
In that case, it's the test programs that need to be changed so as not
to get built with any tests if the algorithm tested isn't present.
In any case, shouldn't linking with libcrypto.a produce linker errors
if you try to get algorithms that aren't there?
Checking if an algorithm is present isn't difficult. All the
corresponding macros (OPENSSL_NO_* in 0.9.7) are stored in
openssl/opensslconf.h.
dkaufman> > Does system() not work in perl under DOS? It seems like you want to
dkaufman> > avoid using system() as much as you can. If not, then why the hackery
dkaufman> > of util/mklinks.pl?
dkaufman>
dkaufman> System does work under DJGPP. Depending on how it is called, it may
dkaufman> call bash or the DOS command.com file. system() should work (I think
dkaufman> I submitted the original patch that put it there), but this assumes
dkaufman> that compatible utilities are on the system. It seemed more robust to
dkaufman> keep all the work within perl, rather than assuming that the correct
dkaufman> utilities are there.
OK, I can see that point. It still works to have to call make in
Configure, right?
--
Richard Levitte \ Spannv�gen 38, II \ [EMAIL PROTECTED]
Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47
\ SWEDEN \ or +46-708-26 53 44
Procurator Odiosus Ex Infernis -- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/
Unsolicited commercial email is subject to an archival fee of $400.
See <http://www.stacken.kth.se/~levitte/mail/> for more info.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
