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]
