In message <[EMAIL PROTECTED]> on Sun, 9 Jun
2002 18:51:25 -0700 (PDT), Doug Kaufman <[EMAIL PROTECTED]> said:
dkaufman> On 6 June 2002, Richard Levitte wrote:
dkaufman> > [...]
dkaufman> > > @@ -1226,6 +1230,50 @@
dkaufman> > > close(IN);
dkaufman> > > close(OUT);
dkaufman> > >
dkaufman> > > +my $dir;
dkaufman> > > +my $crypt1;
dkaufman> > > +my $crypt2;
dkaufman> > > +my $crypt3;
dkaufman> > > +my $crypt4;
dkaufman> > > +my $crypt5;
dkaufman> > > +my $crypt6;
dkaufman> > > +my $symlink_exists;
dkaufman> > > +mkdir ('include/openssl', 0777) unless -d 'include/openssl';
dkaufman> > > +$symlink_exists=eval {symlink("",""); 1};
dkaufman> > > +foreach $dir (@skip) {
dkaufman> > > + $crypt1=join('','crypto/', "$dir", '/', "$dir", 'test.c');
dkaufman> > > + $crypt2=join('', 'test/', "$dir", 'test.c');
dkaufman> > > + $crypt3=join('', '../', "$crypt1");
dkaufman> > > + $crypt4=join('', 'crypto/', "$dir", '/', "$dir", '.h');
dkaufman> > > + $crypt5=join('', 'include/openssl/', "$dir", '.h');
dkaufman> > > + $crypt6=join('', '../../', "$crypt4");
dkaufman> > > + if ($symlink_exists) {
dkaufman> > > + unlink "$crypt2";
dkaufman> > > + unlink "$crypt5";
dkaufman> > > + symlink("$crypt3", "$crypt2");
dkaufman> > > + symlink("$crypt6", "$crypt5");
dkaufman> > > + } else {
dkaufman> > > + open (OLD, "<$crypt1") or die "Can't open $crypt1\n";
dkaufman> > > + open (NEW, ">$crypt2") or die "Can't open $crypt2\n";
dkaufman> > > + open (OLD1, "<$crypt4") or die "Can't open $crypt4\n";
dkaufman> > > + open (NEW1, ">$crypt5") or die "Can't open $crypt5\n";
dkaufman> > > + binmode(OLD);
dkaufman> > > + binmode(NEW);
dkaufman> > > + while (<OLD>) {
dkaufman> > > + (print NEW $_);
dkaufman> > > + }
dkaufman> > > + binmode(OLD1);
dkaufman> > > + binmode(NEW1);
dkaufman> > > + while (<OLD1>) {
dkaufman> > > + (print NEW1 $_);
dkaufman> > > + }
dkaufman> > > + close (OLD);
dkaufman> > > + close (NEW);
dkaufman> > > + close (OLD1);
dkaufman> > > + close (NEW1);
dkaufman> > > + }
dkaufman> > > + }
dkaufman> > > +
dkaufman> >
dkaufman> > No, no, no and no. I will not do that. Sorry, all I see with that
dkaufman> > is a maintainance nightmare.
dkaufman>
dkaufman> Well, I can tell that this isn't the way you would fix the problem,
dkaufman> but I am not sure which part of the code is the problem. I don't see
dkaufman> where there would be a maintenance problem with this. Let me try to
dkaufman> recap the problem and what I tried to do to fix it. Perhaps someone
dkaufman> can come up with an acceptable solution.
The maintainance problem comes if there is anything special that needs
to be done, because the change will be done in the above code as well
as somewhere in the chain of calls to point.sh and mklink.pl. And
honestly, I prefer the control available through the various
Makefile.ssl rather than the various $cryptn variables above (they're
missing some header files, like pem2.h...).
dkaufman> Links to these files are made by "make links" which is run by the
dkaufman> Configure script. This, in turn, depends on the Makefile in each
dkaufman> subdirectory. When an algorithm is excluded at configure time, the
dkaufman> Makefile in that algorithm's directory is not created, and
dkaufman> "Make links" is not run.
I'm not sure how that is a problem. This means (in your case) that
you'll have a few zero-length files that you'll never use. And? And
since you added changes to mklink.pl to remove the goal file before
symlinking or copying it, it means that the files you will actually
used will be there in the way they're meant, or?
dkaufman> The header files for the excluded algorithms are not required by any
dkaufman> of the compiled files, but the compilation stops because they are
dkaufman> listed as dependencies (at least in crypto/evp/Makefile). I see three
dkaufman> ways that the "include" problem could be solved. Running "make depend"
dkaufman> takes care of this. Removing the header files as dependencies in
dkaufman> the Makefile should work. I chose to copy the header files for the
dkaufman> excluded directories into include/openssl. That way any changes in
dkaufman> the header files will cause the ".c" file to be recompiled, but the
dkaufman> overhead of running "make depend" is avoided.
You tell us that you end up initially with all header files in
include/openssl/ as zero-length files. That means that they are all
present even if the contents are not. How can the dependencies for
available files fail (that's what you suggest, isn't it)?
Oh, wait, you mention "recompiling". Does that mean that you've
configured it one way, compiled, and then reconfigured with some
algorithms removed, and get bit because some .c files do not get
recompiled properly? I'm not surprised, I thought that it was common
knowledge one should do something like "make clean" when one changes
the configuration of any package. Perhaps I've lived in the GNU world
too much (I'm pretty sure they recommend running make clean after a
reconfiguration, but it was a long time since I last read a GNU
INSTALL document)...
dkaufman> The test files for each excluded algorithm are still called by
dkaufman> test/Makefile. Running "make depend" does not fix this problem. The
dkaufman> test files are all designed to print "No [algorithm] support" if the
dkaufman> algorithm was excluded at configure time. I see two possible fixes.
dkaufman> One would be to alter test/Makefile in the Configure script, so that
dkaufman> it no longer calls the testfiles for excluded algoritihms. With this
dkaufman> solution, "make test" would no longer give the warning that the
dkaufman> algorithms were excluded. The warning seemed like a good safety check
dkaufman> to me. I chose to copy the testfiles for the excluded algorithms to
dkaufman> the test directory.
Hmm, wait, are you saying that such a warning is disturbing to the
eye, or did the test sequence stop with some kind of error? If it's
cosmetic, perhaps you could suggest a better message that doesn't
freak people out (if that's the trouble you anticipate)?
dkaufman> > However, I did ask on openssl-dev, just a moment ago, if the
dkaufman> > automagic 'make depend' should be reenabled. Could you test that
dkaufman> > such an option works properly?
dkaufman>
dkaufman> "Make depend" works on DJGPP.
I assume it solves most problems that you've encountered with disabled
algorithms, or did I misunderstand?
dkaufman>
dkaufman> > > --- openssl-0.9.7/util/mklink.pl.orig Wed Apr 4 15:50:22 2001
dkaufman> > > +++ openssl-0.9.7/util/mklink.pl Thu Apr 18 18:42:26 2002
dkaufman> > > @@ -18,10 +18,10 @@
dkaufman> > > my $from = shift;
dkaufman> > > my @files = @ARGV;
dkaufman> > >
dkaufman> > > -my @from_path = split(/\//, $from);
dkaufman> > > +my @from_path = split(/[\\\/]/, $from);
dkaufman> > > my $pwd = `pwd`;
dkaufman> > > chop($pwd);
dkaufman> > > -my @pwd_path = split(/\//, $pwd);
dkaufman> > > +my @pwd_path = split(/[\\\/]/, $pwd);
dkaufman> > >
dkaufman> > > my @to_path = ();
dkaufman> > >
dkaufman> > > @@ -52,9 +52,18 @@
dkaufman> > > foreach $file (@files) {
dkaufman> > > my $err = "";
dkaufman> > > if ($symlink_exists) {
dkaufman> > > + unlink "$from/$file";
dkaufman> > > symlink("$to/$file", "$from/$file") or $err = " [$!]";
dkaufman> > > } else {
dkaufman> > > - system ("cp", "$file", "$from/$file") and $err = " [$!]";
dkaufman> > > + open (OLD, "<$file") or die "Can't open $file: $!";
dkaufman> > > + open (NEW, ">$from/$file") or die "Can't open $from/$file:
dkaufman> > $!";
dkaufman> > > + binmode(OLD);
dkaufman> > > + binmode(NEW);
dkaufman> > > + while (<OLD>) {
dkaufman> > > + (print NEW $_);
dkaufman> > > + }
dkaufman> > > + close (OLD) or die "Can't close $file: $!";
dkaufman> > > + close (NEW) or die "Can't close $from/$file: $!";
dkaufman> > > }
dkaufman> > > print $file . " => $from/$file$err\n";
dkaufman> > > }
dkaufman> >
dkaufman> > I don't remember our conversation on this, so bear with me: does the
dkaufman> > call to cp not work? If it does, is this really necessary?
dkaufman>
dkaufman> The call to "cp" does work. Unarchiving the tar.gz file can cause zero
dkaufman> byte files to be created. I don't see that with the current snapshot,
dkaufman> but it was a problem with previous releases, which had symbolic links
dkaufman> in the tar.gz file.
I may be confused by what you're saying... it seems like you're
saying that cp may have problems because of zero-length files
generated when untarring the distribution. I'm sure that's a
misunderstanding on my part.
dkaufman> I think it would be safest to include the line to 'unlink
dkaufman> "$from/$file"',
I've no problem with that :-).
dkaufman> and if you want to use a call to "cp" do "cp -f".
Have you encountered cases where -f is needed? I do not believe it's
portable. However, if the unlink statement is moved up (as you
suggest), that problem should be solved.
dkaufman> The one problem I still see is with point.sh. It works for
dkaufman> DJGPP, but won't work for other systems without symbolic
dkaufman> links. I don't know how to test for symbolic links in a
dkaufman> shell script.
Is it '-fR' that you're refering to? I agree... Would it be possible
to reimplement the recursive part in terms of sh (removes the need for
-R), and then use rm to remove each present goal file before it's
copied anew (removed the need for -f)? It would probably be easier to
implement in perl (meaning we get a point.pl and remove point.sh), and
in that case, the arguments could be used properly so tricks like
`cd ../../perlasm;pwd` aren't needed any more (I prefer to have
relative paths, so I can move a tree at will, see).
--
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]
