From: Richard Levitte
> sms>
> http://antinode.info/ftp/openssl/1_0_0d/openssl-1_0_0-stable-SNAP-20110323_s1.zip
>
> Applied to the same three branches. Will show in tomorrow's
> snapshots.
I sucked down an openssl-1_0_0-stable-SNAP-20110329 kit, and looked
at the differences between it an
In message <11032507012111_20200...@antinode.info> on Fri, 25 Mar 2011 07:01:21
-0500 (CDT), "Steven M. Schweda" said:
sms>Ooh. Just moments too soon. I went through the exercise again on an
sms> openssl-1_0_0-stable-SNAP-20110323 kit, probably being a little more
sms> careful. Originals
From: Richard Levitte
> Changes applied, on the main development branch as well as
> 1.0.1-stable and 1.0.0-stable. Tomorrow's snapshots will hold the
> changes.
Ooh. Just moments too soon. I went through the exercise again on an
openssl-1_0_0-stable-SNAP-20110323 kit, probably being a lit
In message <11032315292753_20200...@antinode.info> on Wed, 23 Mar 2011 15:29:27
-0500 (CDT), "Steven M. Schweda" said:
sms> > From: Richard Levitte
sms> >
sms> > > sms>
http://antinode.info/ftp/openssl/1_0_0d/openssl-SNAP-20110321_s1.zip
sms> > >
sms> > > Just to clarify, you used open
In message <11032216192727_20200...@antinode.info> on Tue, 22 Mar 2011 16:19:27
-0500 (CDT), "Steven M. Schweda" said:
sms> http://antinode.info/ftp/openssl/1_0_0d/openssl-SNAP-20110321_s1.zip
Changes applied, on the main development branch as well as
1.0.1-stable and 1.0.0-stable. Tomor
> From: Richard Levitte
>
> > sms>
> > http://antinode.info/ftp/openssl/1_0_0d/openssl-SNAP-20110321_s1.zip
> >
> > Just to clarify, you used openssl-SNAP-20110321.tar.gz for this?
> > That's a different branch than the one 1.0.0d comes from...
>
>Yes. (Or "openssl-SNAP-20110321^.ta
From: Richard Levitte
> sms>
> http://antinode.info/ftp/openssl/1_0_0d/openssl-SNAP-20110321_s1.zip
>
> Just to clarify, you used openssl-SNAP-20110321.tar.gz for this?
> That's a different branch than the one 1.0.0d comes from...
Yes. (Or "openssl-SNAP-20110321^.tar.gz;1", as it's k
In message <11032216192727_20200...@antinode.info> on Tue, 22 Mar 2011 16:19:27
-0500 (CDT), "Steven M. Schweda" said:
sms> > 64 Automatic choice of "64" or "64=ARGV".
sms> > 64=ARGVManual choice of "64=ARGV".
sms> > 64=Manual choice of plain "64".
sms>
sms
In message <11032017084365_20200...@antinode.info> on Sun, 20 Mar 2011 17:08:43
-0500 (CDT), "Steven M. Schweda" said:
sms> From: Richard Levitte
sms>
sms> > [...] tomorrow's snapshot [...]
sms>
sms>Every time I look at the snapshot Web page, I get confused. README
sms> doesn't describe
> 64 Automatic choice of "64" or "64=ARGV".
> 64=ARGVManual choice of "64=ARGV".
> 64=Manual choice of plain "64".
Seems to be done, and the compiler test activity no longer leaves
junk object and/or listing files lying around. Original (*.*_orig) and
chan
From: Richard Levitte
> richard> sms> 64 Automatic choice of "64" or "64=ARGV".
> richard> sms> 64=ARGVManual choice of "64=ARGV".
> richard> sms> 64=NOARGV Manual choice of plain "64".
> richard> sms>
> richard> sms> Easy for the normal victim, flexible enough for
In message <20110320.185103.256442123.rich...@levitte.org> on Sun, 20 Mar 2011
18:51:03 +0100 (CET), Richard Levitte said:
richard> In message <11032010253821_20200...@antinode.info> on Sun, 20 Mar 2011
10:25:38 -0500 (CDT), "Steven M. Schweda" said:
richard>
richard> sms> Perhaps better woul
In message <11032010253821_20200...@antinode.info> on Sun, 20 Mar 2011 10:25:38
-0500 (CDT), "Steven M. Schweda" said:
sms> Perhaps better would be a three-choice scheme:
sms>
sms> 64 Automatic choice of "64" or "64=ARGV".
sms> 64=ARGVManual choice of "64=ARGV".
sms>
From: Richard Levitte
> (we're still talking about the case when the user explicitely asks for
> 64 bit pointers, saying "64" to the build scripts, right?)
Right.
> Hmm, previously, we had a hard case with 64=ARGV when the user gave
> "64", no choice there... Now, the build script adapts to
In message <11032008135776_20200...@antinode.info> on Sun, 20 Mar 2011 08:13:57
-0500 (CDT), "Steven M. Schweda" said:
sms> From: Richard Levitte
sms>
sms> > Naah... this is only needed in makeapps.com, as far as I can tell,
sms> > and it wouldn't be too hard to have a spot in the code simply
From: Richard Levitte
> sms> But all the "64" consumers would need to be changed to deal with the new
> sms> "64A" option.
Or an explicit "64" or "64=ARGV"...
> Naah... this is only needed in makeapps.com, as far as I can tell,
> and it wouldn't be too hard to have a spot in the code simply
In message <11031918194299_20200...@antinode.info> on Sat, 19 Mar 2011 18:19:43
-0500 (CDT), "Steven M. Schweda" said:
sms> > I'll try something out...
sms>
sms>I'd guess that one could (conditionally) 1) declare the real argv[]
sms> as 32-bit pointers, 2) construct a new argv[] made of 64-
From: Richard Levitte
> sms>I'm subscribed to the list, so the extra copy isn't needed.
>
> Plus the extra copy bounces...
Hmmm. I was getting two. Anyway, ...
> However, there's a point here. When /NOPOINTER_SIZE is used ("" was
> specified for size), are the pointers long or short
In message <11031907290331_20200...@antinode.info> on Sat, 19 Mar 2011 07:29:03
-0500 (CDT), "Steven M. Schweda" said:
sms> From: Richard Levitte
sms> To:openssl-dev@openssl.org, sms@antinode-info
sms>
sms>R:
sms>
sms>I'm subscribed to the list, so the extra copy isn't needed.
> Also, it seems that /POINTER_SIZE=64=ARGV isn't supported with HP C
> 7.1. [...]
I can believe that. SYS$HELP:CC073.RELEASE_NOTES puts it under "5.2
Enhancements in V7.1", but SYS$HELP:CC071.RELEASE_NOTES doesn't mention
it. Trust no one, I always say.
>That's depressing. My first im
From: Richard Levitte
To: openssl-dev@openssl.org, sms@antinode-info
R:
I'm subscribed to the list, so the extra copy isn't needed.
> about your latest changes, it seems that it has SSL_LIBCRYPTO32.OLB
> and SSL_LIBSSL32.OLB as default names (when have specified "" for the
> bits para
Hey,
about your latest changes, it seems that it has SSL_LIBCRYPTO32.OLB
and SSL_LIBSSL32.OLB as default names (when have specified "" for the
bits parameter)... is that your intention? I find it a bit
confusing, I'd rather expect something like this:
bits="" => SSL_LIBCRYPTO.OLB, SSL_LIBSSL.OL
In message <11031820281928_20200...@antinode.info> on Fri, 18 Mar 2011 20:28:19
-0500 (CDT), "Steven M. Schweda" said:
sms>More VMS builder mysteries...
sms>
sms>In "makevms.com", I see:
sms>
sms> $! P6, if defined, sets a compiler thread NOT needed on OpenVMS 7.1 (and
up).
sms>
sms>
More VMS builder mysteries...
In "makevms.com", I see:
$! P6, if defined, sets a compiler thread NOT needed on OpenVMS 7.1 (and up).
I find this about as clear as mud. Can anyone explain what "sets a
compiler thread" means? What, exactly, is "NOT needed on OpenVMS 7.1
(and up)"? "A comp
From: Richard Levitte
> Got openssl-1_0_0d_s4.zip and openssl-1_0_0d_s4a.zip couple of days
> ago, it's getting tested right now.
My VAX just finished its run through the latest stuff, and it seems
to be happy. (The Perl build finished, some of its tests passed, and it
seems to work well eno
In message <11031501491312_20200...@antinode.info> on Tue, 15 Mar 2011 01:49:13
-0500 (CDT), "Steven M. Schweda" said:
sms> http://antinode.info/ftp/openssl/1_0_0d/openssl-1_0_0d_s4a.zip
Got openssl-1_0_0d_s4.zip and openssl-1_0_0d_s4a.zip couple of days
ago, it's getting tested right now
> There are probably more such items, lost in the mists of time, but these
> were easy to find in the old-complaint pile.
Going back to 3-APR-2010, for example, I provided a fix for a test
problem involving multi-dot file names on an ODS2 file system. I'll try
again.
[...]
2496048:error:02001
From: Arpadffy Zoltan
> >I'm having a good time, even if no one else cares.
>
> I do care.
> I apologize for being silent, but I have been very busy with less open sour=
> ce issues.
I wasn't complaining about you, but there are still some open
questions on this stuff, and feedback from the
n 14 mars 2011 13:27
To: openssl-dev@openssl.org
Subject: Re: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and
ACCVIO on OpenVMS
New (complete) replacement file kit:
http://antinode.info/ftp/openssl/1_0_0d/openssl-1_0_0d_s4.zip
This includes a "util/libeay.num&q
New (complete) replacement file kit:
http://antinode.info/ftp/openssl/1_0_0d/openssl-1_0_0d_s4.zip
This includes a "util/libeay.num" with OPENSSL_strcasecmp, and updated
builders. Previously, LINK commands in the builders lacked explicit
/[NO]MAP options, so, in batch mode, where the de
> http://antinode.info/ftp/openssl/1_0_0d/openssl-1_0_0d_s3e.zip
>Wheee. Will the fun never end?
Perhaps after I run "VMS/mkshared.com" on a VAX, and notice a few
other careless errors therein.
http://antinode.info/ftp/openssl/1_0_0d/openssl-1_0_0d_s3f.zip
Sigh. No doubt t
>Ooh. So close.
Progress continues. In my never-ending quest for fun, I tried
linking an OPENSSL.EXE using the shared images (SSL_*_SHR*.EXE) instead
of the object libraries (SSL_*.OLB), which is something the normal VMS
builders don't do. Naturally, it didn't work. But it was pretty cl
Ooh. So close.
http://antinode.info/ftp/openssl/1_0_0d/openssl-1_0_0d_s3d.zip
Less buggy editions of:
crypto/install-crypto.com
ssl/install-ssl.com
VMS/mkshared.com
SMS.
__
OpenSSL Project
VMS before V8.3 did not support symlinks, so VMSTAR typically
extracted symlinks as text files containing a message with the link
text. This tended to create useless junk in "./include/openssl/"
instead of useful symlinks to actual header files. The "makevms.com"
procedure worked around this b
Today's project: Restore command-line case preservation for
"openssl.exe" (on modern non-VAX systems, with Parse Style: Extended).
New: "apps/vms_decc_init.c". Modified: "apps/makeapps.com", plus a
bunch of "test/*.com" files which depended on DCL+C command-line
downcasing (or were in danger o
> http://antinode.info/ftp/openssl/1_0_0d/openssl-1_0_0d_s3.zip
>
> Unless I've missed something, [...]
Naturally, that was too good to be true. I now have enough Perl on
my VAX system to run into a test failure:
[...]
---> TEST_CMS
CMS consistency test
CMS => PKCS#7 compatibility test
From: "Dr. Stephen Henson"
> [...] A simple workaround would be to copy
> argv into a malloced copy that is properly NULL terminated if you haven't done
> that already. As all the apps go through main() code in apps/openssl.c you
> should only need to change one place.
http://antinode.info
From: "Dr. Stephen Henson"
> [...] A simple workaround would be to copy
> argv into a malloced copy that is properly NULL terminated if you haven't done
> that already. As all the apps go through main() code in apps/openssl.c you
> should only need to change one place.
That probably makes (mu
On Tue, Mar 08, 2011, Steven M. Schweda wrote:
>There seems to be some evidence that argv[] _should_ be
> NULL-terminated, which would seem to shift the the blame for the
> misbehavior of the "apps/" programs (on Alpha with 64-bit pointers) from
> programs themselves to HP's C compiler team.
>
http://antinode.info/ftp/openssl/1_0_0d/openssl-1_0_0d_s2e.zip
Bad "crypto/crypto-lib.com". (Minor error on VAX.) Trust no one, I
always say. (Especially me.) It'll be a while before the VAX build
gets finished, so stay tuned.
There seems to be some evidence that argv[] _should_ b
From: Arpadffy Zoltan
> I am sorry, I could not test your changes yet - I'll do it, hopefully, duri=
> ng this week.
> ...but to be honest, I am more curious what is Richard's opinion about your=
> changes.
I'm curious about anyone's opinion, but you know as much as I do.
Please let me know
nt: Sunday, March 06, 2011 2:53 AM
To: openssl-dev@openssl.org
Subject: Re: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and
ACCVIO on OpenVMS
I apparently forgot to include the modified/new start-up procedures
("VMS/openssl_startup.com", "VMS/openssl_undo
I apparently forgot to include the modified/new start-up procedures
("VMS/openssl_startup.com", "VMS/openssl_undo.com") in previous update
collections:
http://antinode.info/ftp/openssl/1_0_0d/openssl-1_0_0d_s2c.zip
SMS.
_
>2. The argv-using "apps/*.c" programs need reform to use "argc"
> instead of looking for a NULL terminator at the end of "argv[]".
> (Looking for a NULL makes sense for "envp[]", which is expected to be
> NULL-terminated, but not so much for "argv[]", where it causes bad
> behavior on VMS Alp
> http://antinode.info/ftp/openssl/1_0_0d/openssl-1_0_0d_s2.zip
For an "install.com" which works better (perhaps even properly):
http://antinode.info/ftp/openssl/1_0_0d/openssl-1_0_0d_s2a.zip
> $ pipe show time ; @ install.com ""'p1'" ; show time
That > ""'p1'" < should have
> IT $ type [-]btsi_z.com
> $ pipe show time ; -
>@ makevms.com ALL "" NODEBUG DECC TCPIP "" -
>utility_root:[source.zlib.zlib-1_2_5l] ; -
>show time
> $ pipe show time ; @ [.test]tests.com ; show time
> $ pipe show time ; @ [.vms]mkshared.com -
>utility_root:[source.zlib.zlib-1_2_5
> http://antinode.info/ftp/openssl/1_0_0d/openssl-1_0_0d_s1.zip
A revised, possibly better, replacement file kit ("unzip -V") is now
available:
http://antinode.info/ftp/openssl/1_0_0d/openssl-1_0_0d_s2.zip
The builders should now be able to deal with both 32- and 64-bit
pointer
From: Arpadffy Zoltan
> > I seem to have 1.0.0d builds working on VMS
>
> Great news, I would be happy to try the build with your changes.
> Could you please send some instructions where the patch can be found?
> Or it would be the best to post the diffs here, making available for Richar=
> d to
ank you, Steven.
Best regards,
Z
-Original Message-
From: Steven M. Schweda [mailto:s...@antinode.info]
Sent: den 28 februari 2011 07:28
To: openssl-dev@openssl.org
Subject: Re: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and
ACCVIO on OpenVMS
I seem to have 1.0
I seem to have 1.0.0d builds working on VMS with 32- or 64-bit
pointers, but I'm still waiting for some guidance on how to make some of
the needed changes:
1. I need a macro/typedef for an integer with the same size as a
pointer. On non-VMS systems "intptr_t" might be suitable, but not on
V
From: "Steven M. Schweda"
>On a different point, a closer look at the 64-bit-pointer test
> results shows a problem on Alpha (but not on IA64) somewhere in the "CMS
> => PKCS#7 compatibility test" sequence. Perhaps some file I/O thing?
> The perl script doesn't seem to handle an explosion he
From: "Green, Paul"
> > What seems (to me) to be needed in these cases is some macro or
> > typedef which is an integer whose size is reliably the same as
> > that of a pointer, which size_t is not. =20
>
> Hi Steve, Please take a look at your copy of stdint.h. See if you have
> a definition fo
Steven M. Schweda wrote:
> What seems (to me) to be needed in these cases is some macro or
> typedef which is an integer whose size is reliably the same as
> that of a pointer, which size_t is not.
Hi Steve, Please take a look at your copy of stdint.h. See if you have
a definition for the "int
From: "Arpadffy Zoltan via RT"
> test BN_mont
> Montgomery multiplication test failed!
This seems to be caused by an apparently prevalent belief that the
way to do integer operations on a pointer is to type-cast that pointer
to size_t. Sadly, on VMS, size_t is 32 bits (unsigned int), regardl
#x27;s code and
see how they solved the 64-bit descriptors issue.
Regards,
Z
-Original Message-
From: Steven M. Schweda [mailto:s...@antinode.info]
Sent: den 15 februari 2011 16:14
To: openssl-dev@openssl.org
Subject: Re: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build an
From: Arpadffy Zoltan
> > Why have a build option which doesn't work?
>
> Actually, it works good enough to keep, as we can still use the following o=
> ptions:
> - 32 for build with /POINTER_SIZE=3D32 - that is used often together with o=
> lder applications.
> - "" for build with default /NOPO
From: Steven M. Schweda [mailto:s...@antinode.info]
Sent: den 15 februari 2011 15:40
To: openssl-dev@openssl.org
Subject: Re: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and
ACCVIO on OpenVMS
From: Arpadffy Zoltan
> Then, after all, I think, the best solution would be
From: Arpadffy Zoltan
> Then, after all, I think, the best solution would be to leave as it is and =
> close this (#2449) issue.
>
> We can continue to live with default (/NOPOINTER_SIZE) and optional 32-bit =
> build (/POINTER_SIZE=3D32)
>
> Maybe, it would be useful to change the makevms.com
ead.
What is your opinion?
Regards,
Z
-Original Message-
From: Steven M. Schweda [mailto:s...@antinode.info]
Sent: den 15 februari 2011 14:48
To: openssl-dev@openssl.org
Subject: Re: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and
ACCVIO on OpenVMS
From: Arpadffy Zol
From: Arpadffy Zoltan
> It is interesting that not forcing the /pointer_size=3D64 - the build is OK=
> (by running @makevms all "" nodebug)
Interesting, perhaps, but not really news.
HELP CC /POINTER_SIZE
[...]
Specifying /POINTER_SIZE=32 directs the compiler to assume that all
:52
To: openssl-dev@openssl.org
Subject: Re: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and
ACCVIO on OpenVMS
From: "Arpadffy Zoltan via RT"
> I have tested 1.0.0d release on OpenVMS and found many warnings during th=
> e build with 64bits pointer size that prod
From: "Arpadffy Zoltan via RT"
> I have tested 1.0.0d release on OpenVMS and found many warnings during th=
> e build with 64bits pointer size that produced many annoying warning mess=
> ages during linking against the library - like:
>
> Building The BNTEST Test Program.
> %ILINK-W-COMPWARN, co
62 matches
Mail list logo
