Hmmmm. I see. Well, how 'bout if I just report every one of these as a
bug? Will that help appease legal dudes and, more importantly, the roaming
aliens? Try this:
Bug: Borland builds fail because "-6" isn't on the BCC32 command line.
Pentium Pro instructions are used in this build, and in order for the
compiler for allow the Pentium Pro instructions to compile, -6 must be
present.
Bug: Borland builds fail because the RSAGLUE library target has no
commands, thus no RSAGlue.lib is produced. RSAGlue.lib is, however, used in
a later link statement that fails because there is no RSAGlue.li. For
Borland builds, if RSAGlue.lib is not to be built, then all references to it
should be removed from the makefile.
Bug: Borland builds fail because the command "@" (an empty command) fails
in Borland's 'make.exe', but the dependency "headers : $(HEADER)
$(EXHEADER)" has only an "@" as it's sole commnad, which Borland make
interprets as an empty command that it can't execute, and fails the build.
The dependency and the empty command should be removed.
Bug: Output from Borland build collides with output from other Windows
compilers (like MSVC). The directories "tmp32", "out32", and "inc32" should
be separate for Borland and Microsoft builds, so changing these directories
in the generated bcb.mak file to "tmp32_BC", "out32_BC", and "inc32_BC",
respectively, would prevent the Microsoft/Borland build collisions in shops
where both compilers need to be supported from the same code base.
Bug: "Mkdir" fails and stops Borland builds if the target directory for
"mkdir" already exists. This means that only the first Borland build in a
given directory will succeed. Successive builds will fail. There should be
a macro CHKDIR=@if NOT EXIST defined, and all instances of "$(MKDIR)
$(<var>)" should be replaced with "$(CHKDIR) $(<var>) $(MKDIR) $(<var>)"
This will prevent build
Bug: There are a great many functions that are called without prototypes.
These should be corrected. I would be glad to assist in the correction of
this defect.
Bug: Some compilers wisely warn about constructs such as "if (a = b)" being
a possibly incorrect assignment, assuming that the programmer may have
really meant "if (a == b)". The expression should be changed to "if ((a=b)
!= 0) to indicate to the compiler that the assignment is indeed
intentional. This way the warning can be left "on" to catch legitimate
mistakes, while still getting clean builds. These should be corrected. I
would be glad to assist in the correction of this defect.
Bug: If I build my application using MSVC with Dynamic MSVC libraries and
static OpenSSL libraries, I get about 10 unresolved externals in the
RAND_screen code. The RAND_screen code should be able to be opted out and
replaced with a RAND_poll function like the existing UNIX one in rand_win.c.
A simple -DNO_RAND_SCREEN could control this option to avoid the linker
errors. The affected files would be 'rand_win.c', 'rand.h', and
'app_rand.c'.
Bug: There is a function called ERR_load_CRYPTO_strings in the generated
file "cpt_err.c", and another function called ERR_load_crypto _strings in
"err_all.c". The names differ only in case, and they end up clashing in the
library at TLIB time for libeay32.lib. I don't know what the intention here
is, but the collision in the library can't be correct/intended, can it? This
may be present in all builds - I don't know - but it is brought to one's
attention during Borland builds and should be corrected in whatever way is
appropriate.
Thanks for considering these bug fixes,
Bill Rebey
PS: (Roaming aliens are a pain the butt, cause excessive amounts of typing,
and create a large volume of unnecessary work...) <g>
-----Original Message-----
From: Geoff Thorpe [mailto:[EMAIL PROTECTED]]
Sent: Friday, August 04, 2000 1:22 PM
To: [EMAIL PROTECTED]
Subject: Re: Requests for Build changes
Hi there,
Unfortunately the laws governing exports of software from the US are still
not yet cut-and-dried. If you are sending patches from the US, there's
unfortunately a very real risk of "contamination" of the code base if we
incorporate them. We have been obtaining legal opinion on this issue and
will continue to keep an eye on how things are changing.
Bug reports from the US that lead to fixes are almost certainly no
problem, but specific code submissions probably need to be avoided for
now. I'm sure the others from the development team will pitch in if I've
misrepresented the situation in any way, and as always;
* I'm not a lawyer.
* These are only my opinions.
* They aren't really even *my* opinions but were forced upon me by
roaming aliens.
Cheers,
Geoff
On Fri, 4 Aug 2000, Bill Rebey wrote:
> I'm trying to get Windows builds working "better" (a relative term, of
> course <g>)
>
> I would like to see the following changes if I can get them:
>
> For Borland C++ Builds:
>
> 1) There is a function called ERR_load_CRYPTO_strings in the generated
> file "cpt_err.c", and another function called ERR_load_crypto _strings in
> "err_all.c". The names differ only in case, and they end up clashing in
the
> library at TLIB time for libeay32.lib. I don't know what the intention
here
> is, but the collision in the library can't be correct/intended, can it?
> This may be present in all builds - I don't know - but it is brought to
> one's attention during Borland builds and should be corrected.
>
> 2) I had to make some changes to the makefile 'bcb.mak' to get things
> to build. I have included a 'diff' to illustrate the suggested changes.
> All of these changes we necessary to get OpenSSL to build with Borland's
> "make v5.2", and "bcc 5.4" (the tools that ship with BC Builder 4.0).
Could
> you make the bcb.mak makefile generator generate the makefile with these
> changes in it?
>
> 3) One of the changes in the makefile is to turn off some warnings so
> that build is at least a little cleaner. I'm a kind of a fanatic about
> clean, warningless builds and leaving all warnings turned ON if possible
so
> that legitimate mistakes can be caught by a compiler rather than a
debugger
> or a QA lab. If I took the time to prototype all the "missing prototype"
> functions, parenthesize all the "possibly incorrect assignment"
statements,
> and clean up whatever other warnings I can that BC is spotting for us,
would
> you put the changes in for me or would it be waste of my time?
>
> For all Windows Builds:
>
> I would like to be able to omit the RAND_SCREEN code from builds. I
> have diffs of app_rand.c, rand_win.c, and rand.h that can (if
NO_RAND_SCREEN
> is defined) switch off the RAND_screen stuff and instead supply a method
of
> seeding the PRNG that is extremely similar to the UNIX version of
RAND_poll
> in rand_win.c. Are these valid changes? The reason that I'm asking for
them
> is because I don't ever want to use that RAND_screen seeding method, and
if
> I leave that code in there, I get about 10 "_imp_Xxxx undefined" functions
> when I link with static OpenSSL libraries. Rather than fix the link
trouble,
> I would prefer to just opt out of using this code altogether.
>
> These changes are against the 20000731 Snapshot.
>
> <<app_rand.c_diff>> <<rand_win.c_diff>> <<rand.h_diff>>
<<bcb.mak_diff>>
>
> Thanks for considering these changes for me.
>
> Bill Rebey
>
>
>
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
