[[EMAIL PROTECTED] - Mon Oct  7 19:52:13 2002]:

> But before that, after doing some tests, I found out that we need
> to keep some version of RAND_poll (the patch removes it, and then
> the system does not seem to like that; something about unresolved
> symbols and stuff ;-) ).
> A google search returns this message ID with a random device and a
> RAND_poll implementation for VxWorks:
> <adighp$ven$[EMAIL PROTECTED]>
> but I am not sure how portable or how good it is.
> We could also just leave a blank implementation and force the user
> to seed the PRNG themselves.  Your call.

I have no problems with a blank implementation.  VMS had that for 
quite a while.

> > 1. The change in Makefile.org requires GNU make.  Sorry, we can't
> > assume that, so I wonder if you have some different solution to 
get
> > libs only.
> 
> Perhaps something like:
> 
> all: Makefile.ssl sub_libs sub_exec sub_test
> 
> and then have clones of current sub_all target looping through 
their
> respective directories?

OK, that's an idea.  I'll look into that.

> > 2. As far as I can see, splitting up the arguments to makedepend
> > with -- like you do is not necessary, and actually
> > counterproductive, at least according to the manual I have.
> 
> I am not sure why do you think it is counterproductive, since
> without -- makedepend does not work.  The issue comes up when
> there are various options within CFLAGS that start  with -f,
> which is very common when compiling for VxWorks.

I understand the issue.  However, note that I said "like you do", 
and I really meant that.  The line you gave me:

$(MAKEDEPEND) -- $(CFLAG) -- $(INCLUDE) $(DEPFLAG) $(PROGS) $(LIBSRC)

is counterproductive, because makedepend won't see $(INCLUDE) 
properly, as well as $(DEPFLAG).  After the second double dash, only 
source files should follow.  I've no idea how options are treated, 
maybe like missing files?  Anyhow, I just read the source for one 
implementation (coming with OpenMotif, I believe) of makedepend, and 
found that the part between the first and second double dash will be 
treated as options, where only -D, -U, -I and -m are recognised, and 
the rest are simply ignored.  This leads me to believe that the 
proper incantation of makedepend should be:

$(MAKEDEPEND) -- $(CFLAG) $(INCLUDE) $(DEPFLAG) -- $(PROGS) $(LIBSRC)

Now, that's easy enough for 0.9.6, in 0.9.7 we're going through the 
domd script, (which is basically what $(MAKEDEPEND) is defined to), 
which might call gcc, basically ending up trying the following:

gcc -D OPENSSL_DOING_MAKEDEPEND -M -- -Iinclude -- foo.c

I wonder how gcc likes that.  A small test shows it didn't quite 
like the double dashes.  That's even more counterproductive...

I agree that when calling makedepend, the double dashes syntax, my 
variant, should be used.  However, we need to make sure we get it 
right for gcc as well.  I'll ponder this a bit more.

-- 
Richard Levitte
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [EMAIL PROTECTED]
Automated List Manager                           [EMAIL PROTECTED]

Reply via email to