In message <11031907290331_20200...@antinode.info> on Sat, 19 Mar 2011 07:29:03 
-0500 (CDT), "Steven M. Schweda" <s...@antinode.info> said:

sms> From: Richard Levitte <rich...@levitte.org>
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.

Plus the extra copy bounces...

sms> > about your latest changes, it seems that it has SSL_LIBCRYPTO32.OLB
sms> > and SSL_LIBSSL32.OLB as default names (when have specified "" for the
sms> > bits parameter)...  is that your intention?  I find it a bit
sms> > confusing, I'd rather expect something like this:
sms> > 
sms> 
sms>    So far as I know, there is no difference between the results you get
sms> from specifying "" and those you get from specifying "32", so I didn't
sms> try to name then differently.  I believe that the default, 
sms> /NOPOINTER_SIZE, and an explict /POINTER_SIZE=32 differ only in that
sms> /POINTER_SIZE=32 enables the use of features like "#pragma
sms> pointer_size", and we use these (even indirectly) only in the
sms> 64-bit-pointer case.  On my VAX (V7.3) system, where there is no
sms> /[NO]POINTER_SIZE option, HP uses the "32" names for the shared images:
sms> 
sms> Directory SYS$COMMON:[SYSLIB]
sms> 
sms> SSL$LIBCRYPTO_SHR32.EXE;1
sms>                          1653   1-APR-2004 11:05:45.08  (RWED,RWED,RE,RE)
sms> SSL$LIBSSL_SHR32.EXE;1
sms>                           381   1-APR-2004 11:06:00.95  (RWED,RWED,RE,RE)
sms> 
sms> On my non-VAX systems (Alpha V8.3 shown here), I see:
sms> 
sms> Directory SYS$COMMON:[SYSLIB]
sms> 
sms> SSL$LIBCRYPTO_SHR.EXE;1
sms>                          3139   9-JUN-2006 09:49:15.55  (RWED,RWED,RE,RE)
sms> SSL$LIBCRYPTO_SHR32.EXE;1
sms>                          3055   9-JUN-2006 09:49:58.37  (RWED,RWED,RE,RE)
sms> SSL$LIBSSL_SHR.EXE;1
sms>                           492   9-JUN-2006 09:49:15.55  (RWED,RWED,RE,RE)
sms> SSL$LIBSSL_SHR32.EXE;1
sms>                           483   9-JUN-2006 09:49:58.82  (RWED,RWED,RE,RE)
sms> 
sms> So, my plan was to follow this scheme, and have a "32" at the end of all
sms> the 32-bit-pointer (.EXE and .OLB) names, and nothing in the
sms> 64-bit-pointer names.  But I'm open to a good argument for any other
sms> reasonable scheme.  (At least, with the "SSL_" prefixes, we can
sms> distinguish the new (no "32") 64-bit stuff from the old (no "32") 32-bit
sms> stuff.  Everything's complicated.)

However, there's a point here.  When /NOPOINTER_SIZE is used ("" was
specified for size), are the pointers long or short by default?  I've
always assumed they are long on Alpha and IA64, which make libraries
built without setting /POINTER_SIZE close to 64 bit, doesn't it?  In
that case, I think it's quite confusing that libraries built like that
should end up being called whatever32.ext...

sms> > Also, it seems that /POINTER_SIZE=64=ARGV isn't supported with HP C
sms> > 7.1.  I get this when trying to build the test programs with your
sms> > latest scripts, once for each file:
sms> > 
sms> > %DCL-W-NOVALU, value not allowed - remove value specification
sms> >  \64=\
sms> > 
sms> > And indeed, I can't find that in the help file either...
sms> > 
sms> > $ cc/ver                    
sms> > HP C V7.1-015 on OpenVMS Alpha V8.3    
sms> 
sms>    That's depressing.  My first impulse is to say that 64-bit pointers
sms> require a newer compiler.  It's possible that the "=ARGV" isn't really
sms> needed, but I thought that that was the cure for the "ACCVIO" in the
sms> subject line of this thread.  I'll go back and check, but I believe that
sms> without the "=ARGV", the libraries and shared images may be ok, but all
sms> the main programs (openssl itself, and some/all of the tests?) will
sms> explode when they start passing 32-bit argv[] pointers around to
sms> consumers who expect 64-bit pointers.  (HP supplies only one
sms> OPENSSL.EXE, and I'd bet that it's a 32-bit-pointer edition.)
sms> 
sms>    If the "=ARGV" really is needed to make the main programs work, then
sms> we can either require a newer compiler, or, perhaps, do more/different
sms> argv[] copying (on VMS) to provide a 64-bit argv[] when the C
sms> environment won't.  (Which doesn't sound to me like much fun.)

I'll try something out...

Cheers,
Richard

-- 
Richard Levitte                         rich...@levitte.org
                                        http://richard.levitte.org/

"Life is a tremendous celebration - and I'm invited!"
-- from a friend's blog, translated from Swedish
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@openssl.org
Automated List Manager                           majord...@openssl.org

Reply via email to