Re: won't compile on hp ux 11.23 itanium
gryzman.mac wrote: please CC me on reply, ta. ./Configure shared zlib-dynamic hpux64-ia64-cc cc -I../crypto -I.. -I../include +Z -DOPENSSL_PIC -DZLIB_SHARED - DZLIB -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLFCN_H -Ae +DD64 +O3 +Olit=all -z -DB_ENDIAN -D_REENTRANT -DSHA1_ASM -DSHA256_ASM - DSHA512_ASM -DAES_ASM -I /opt/libs/z/include -I /opt/libs/ssl/include -c -o kssl.o kssl.c (Bundled) cc: warning 922: -Ae is unsupported in the bundled compiler, ignored. (Bundled) cc: warning 922: +O3 is unsupported in the bundled compiler, ignored. (Bundled) cc: warning 922: +Olit=all is unsupported in the bundled compiler, ignored. ar r ../libssl.a s2_meth.o s2_srvr.o s2_clnt.o s2_lib.o s2_enc.o s2_pkt.o s3_meth.o s3_srvr.o s3_clnt.o s3_lib.o s3_enc.o s3_pkt.o s3_both.o s23_meth.o s23_srvr.o s23_clnt.o s23_lib.o s23_pkt.o t1_meth.o t1_srvr.o t1_clnt.o t1_lib.o t1_enc.o d1_meth.o d1_srvr.o d1_clnt.o d1_lib.o d1_pkt.o d1_both.o d1_enc.o ssl_lib.o ssl_err2.o ssl_cert.o ssl_sess.o ssl_ciph.o ssl_stat.o ssl_rsa.o ssl_asn1.o ssl_txt.o ssl_algs.o bio_ssl.o ssl_err.o kssl.o ar: creating ../libssl.a /usr/bin/ranlib ../libssl.a || echo Never mind. if [ -n libcrypto.so.0.9.8 libssl.so.0.9.8 ]; then \ (cd ..; gmake libssl.so.0.9.8); \ fi gmake[1]: Entering directory `/tmp/openssl-0.9.8g' gmake[2]: Entering directory `/tmp/openssl-0.9.8g' gmake[3]: Entering directory `/tmp/openssl-0.9.8g' (Bundled) cc: warning 922: -Ae is unsupported in the bundled compiler, ignored. (Bundled) cc: warning 922: +O3 is unsupported in the bundled compiler, ignored. (Bundled) cc: warning 922: +Olit=all is unsupported in the bundled compiler, ignored. (Bundled) cc: warning 922: -b is unsupported in the bundled compiler, ignored. ld: Unknown input file type: ./libcrypto.so Fatal error. chmod: can't access libssl.so.0.9.8 gmake[3]: *** [link_a.hpux] Error 1 gmake[3]: Leaving directory `/tmp/openssl-0.9.8g' gmake[2]: *** [do_hpux-shared] Error 2 gmake[2]: Leaving directory `/tmp/openssl-0.9.8g' gmake[1]: *** [libssl.so.0.9.8] Error 2 gmake[1]: Leaving directory `/tmp/openssl-0.9.8g' gmake: *** [shared] Error 2 *** Error exit code 1 The first would be to obtain and install the unbundled compiler. The bundled compiler is simply there to regen kernels and is unsupported for much of anything else. rick jones ... any ideas, please ? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: valgrind complaints about my network data received through ssl
Bobby Krupczak wrote: Hi! I've written a network app using pthreads, ssl, and xml. I use xml over tcp over ssl and all of that is working fine. Whilest chasing down what I thought was a bug, I started using valgrind on my app. I'm receiving thousands of uninitialized value and conditional jump errors triggered by the data that I receive via SSL_read. [I'm not worried about the alleged valgrind errors within SSL itself due to randomizing, etc.] I've run test programs using pthreads and xml parsing (extracted out of my code) and they do not trigger the errors when used w/o SSL. So, I'm struggling to understand why the data received via sockets from the network and through SSL would trigger these kinds of warnings. Literally, every packet/pdu I receive and parse triggers these errors. The data is valid and the PDUs are correct thus my confusion. Has anyone ever seen this and know how to fix/correct? Just a wild guess, but perhaps if the buffer you are using is larger than the quantity of data returned, valgrind doesn't know you won't be trying to use some of the stuff at the end? rick jones __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Puzzling 50ms delay between SSL_write and poll response
David Lobron wrote: 2007-07-26 20:18:04.375 [3317] GS: Got response from sendDataPending 2007-07-26 20:18:04.376 [3317] GS: Calling poll with timeout 6 2007-07-26 20:18:04.376 [3317] GS: Checking poll results 2007-07-26 20:18:04.376 [3317] GS: calling SSL_write on buffer of length 1281 2007-07-26 20:18:04.376 [3317] GS: done with SSL_write 2007-07-26 20:18:04.376 [3317] Called advanceSendBuffer:len 2007-07-26 20:18:04.377 [3317] GS: Calling poll with timeout 6 2007-07-26 20:18:04.426 [3317] GS: Checking poll results - 50ms delay occurs here 2007-07-26 20:18:04.426 [3317] GS: calling SSL_read 2007-07-26 20:18:04.427 [3317] GS: done with SSL_read, len = 142, text = GET And if you run tcpdump on the TCP packets, does it also agree there is a 50ms delay ? which end is causing the delay ? I ran a session with tcpdump on the server, stepping the client in a debugger, and I am having some trouble interpreting the results. The tcpdump output for a session is as followed (I've filtered to show only TCP transmissions in both directions with the client, and replaced the host names with CLIENT and SERVER): 21:08:30.190534 CLIENT.39044 SERVER.8443: P 844:1025(181) ack 4827 win 65535 nop,nop,timestamp 173778704 299402767 (DF) 21:08:30.199567 SERVER.8443 CLIENT.39044: P 4827:4917(90) ack 1025 win 8576 nop,nop,timestamp 299406197 173778704 (DF) 21:08:30.202752 SERVER.8443 CLIENT.39044: . 4917:6285(1368) ack 1025 win 8576 nop,nop,timestamp 299406200 173778704 (DF) 21:08:30.290932 CLIENT.39044 SERVER.8443: . ack 4917 win 65535 nop,nop,timestamp 173778704 299406197 (DF) 21:08:30.290977 SERVER.8443 CLIENT.39044: P 6285:6483(198) ack 1025 win 8576 nop,nop,timestamp 299406288 173778704 (DF) That does feel like the server TCP was waiting for the Client's ack before sending the 198 bytes of data. However, it isn't a slam-dunk that nagle was involved here since we don't know the MSS (since we don't have the connection establishment) and cannot tell for certain if the previous exchanges would have set the TCP congestion window to a size that would have allowed things anyway. Given the spread of the ACKno (4917) and the SEQno of what the server sends (6285) I'm inclined to think this was a congestion window-induced delay rather than Nagle. Typically for Nagle one sees the ACKno and the subsequent SEQno as the same value. Congestion windows can be in bytes, some stacks count them in terms of segments (packets). Which OSes are involved here again and what revs? 21:08:30.366362 CLIENT.39044 SERVER.8443: . ack 6285 win 65535 nop,nop,timestamp 173778704 299406200 (DF) That this is the ACKno which I would have expcted to shake loose the Nagle delayed data, and since it is fairly far in time from when that data was sent, I'm guessing it was just a plain standalone ACK and not an inadvertant reordering of traffic in the trace. 21:08:30.382245 CLIENT.39044 SERVER.8443: . ack 6483 win 65466 nop,nop,timestamp 173778704 299406288 (DF) The greater the quantity of data you can present to the transport at one time, the better (broad handwaving terms). For example, if the stack is doing congestion windows in units of segments (packets) then you want to get as much into those segments as you can. rickjones __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Puzzling 50ms delay between SSL_write and poll response
50 ms is a common standalone ACK timer, so if one had a second or Nth small send, it might have been waiting (via Nagle) for the remote's standalone ACK before being transmitted. Some folks like to simply switch-off nagle, I prefer to try to get folks to send logically associated data to the transport in one send call. rick jones __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: How to improve the performance of SSL_Read
ghouse mohiddin wrote: Hi Rick, Thanks for your reply. I want to reduce the reading the response time, so that the performance will get improve. I want to read all the bytes at a time. SSL_read API is taking much time to read all the bytes of the response from the server. First time it is going to read 112 bytes, then 1300 bytes,1460 bytes...etc. Instead of this reading the bytes in chunks in while loop, i want to read all the bytes at a time. Could you please suggest me any other API to read all the bytes at a time. Please send me any example code of this scenario where i can read all the bytes at a time. That does presume I suspect you know in advance how many bytes there are going to be. What you need is support for the water marks in the socket layer. Not all sockets implementations actually support them. On those which do, you can tell the stack the socket is not to be considered readable until N bytes are present. That you are getting the data in bits and peices suggests that your receiver is fast enough to stay ahead of the network, which is a good thing. That your code does those reads for 5 to 6 seconds suggests that it is taking 5 to 6 seconds to get the data to your receiver. Even if you read in on one swell foop (one fell swoop) it would still be 5 to 6 seconds. Depending on the specifics of the connection (can youshare details/) perhaps there are some packet losses happening. rick jones Thanks in Advance, Ghouse... On 5/22/07, Rick Jones [EMAIL PROTECTED] wrote: ghouse mohiddin wrote: Hi, How to improve the performance of the SSL Read call?. Is there any call to increase the Buffercapacity. I am able to read around 1300 bytes at a time. It is taking 5 to 6 seconds for reading the whole response (Header and Body)from the server which is very slow. 1300 bytes at a time sounds like one TCP segment at a time. How much data in total are you reading in those 5 to 6 seconds? If there really isn't all that much data, perhaps the sender is having to retransmit some of it. Check the netstat statistics and link-level statistics on both ends and look for drops, errors, retransmissions and the like. rick jones __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: How to improve the performance of SSL_Read
ghouse mohiddin wrote: Hi, How to improve the performance of the SSL Read call?. Is there any call to increase the Buffercapacity. I am able to read around 1300 bytes at a time. It is taking 5 to 6 seconds for reading the whole response (Header and Body)from the server which is very slow. 1300 bytes at a time sounds like one TCP segment at a time. How much data in total are you reading in those 5 to 6 seconds? If there really isn't all that much data, perhaps the sender is having to retransmit some of it. Check the netstat statistics and link-level statistics on both ends and look for drops, errors, retransmissions and the like. rick jones __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Post
Michael Fedor wrote: Thanks do you know who the list maintainer is. I suspect that instructions for contacting the list maintainer could be had via the [EMAIL PROTECTED] email listed in the trailer appended to all emails sent via the list. Sending it a message containing a line that reads help will probably be a decent start. Often, Internet mailing lists will follow a convention of owner-listname or listname-owner for an alias by which the list maintainer can be reached. rick jones __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Some wird OpenSSL perfomance slowdown
Sergey S. Levin wrote: Hello Rick, SW crypto aint cheap. It can consume lots of CPU cycles. If the system was nearly CPU saturated with a plain transfer, then the overhead of the crypto can very definitely take the throughput down considerably. 1. If i use FileZilla and SSL connection - it works on 100% of speed. 2. The processor load is just 5% so, this should not be the crypto problem. I'd next wonder what TCP window size(s) were being used in each case, and if SSL was making full use of the TCP window it had available. That means a bit of tcpdump tracing, including the connection establishment so you can see any window scale values being exchanged. rick jones __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Some wird OpenSSL perfomance slowdown
SW crypto aint cheap. It can consume lots of CPU cycles. If the system was nearly CPU saturated with a plain transfer, then the overhead of the crypto can very definitely take the throughput down considerably. rick jones one of these days I need to make an SSL version of netperf :) __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: SSL Scaling Question
Eric Johnson wrote: Hi. I'm new to this forum and was wondering if I could get some assistance. I have an SSL Acceleration device that is comparable of supporting 50,000 concurrent connections. I would like to put this in my lab here at work and test the upper limit of this device. I'm concerned about the backend web server needed for this test effort. I'm trying to find out what the appropriate number of backend servers needed to test the upper limit of the SSL device. If I understand correctly each backend server is going to have an upper limit of 65535 TCP ports that can be opened (as the Source IP will most likely always be the SSL device). On the surface it looks like the backend server should be enough to handle the upper limit of the SSL device. However, that assumes that every connection is successful and the backend server has enough other resources to handle the load. Does anybody have any practical experience with this? And any recommendations on the number of backend servers at a specific load? Thanks in advance An SSL session is presumably mapped to a TCP connection. A TCP connection is named by the four-tuple of local and remote IP, and local and remote port number. Ignoring holes in the address space, that means there can be 2^32 * 2^32 * 2^16 * 2^16 TCP connections in any one Internet universe. If you have a well known port number used on a server, all the clients connect to that port number. Each of the connections will have the server IP and server port number as part of its name, but the names will be unique because they will also have the client IP and client port number. Multiple connections from one client IP will have different client port numbers, so there will still be unique names. So in theory, a backend server can have _very_ many more than 65535 connections. However, you are correct in that to a well-known port and a single server IP, from a single client IP, there can be no more than 65535 connections at any one time. I suspect that if the SSL device is regenerating TCP connections, _it_ becomes the client, and so it is _its_ limitation on port numbers and its single IP address which comes into play. As for how many servers, that is one of those it depends things - how busy are each of the connections through the SSL device etc etc. If all you are doing is establish the connection, exchange a request and response and then close, that will look to the back-end server or servers rather like the old SPECweb96 benchmark. If connections are persistent and include some dynamic content, it will look to the back-end server rather like the SPECweb99 benchmark. If there is no dymanic content, but connections are persistent it will look different from the two - but a give result would be higher than the corresponding SPECweb96 or SPECweb99 score. If you want to be certain you are measuring the SSL device then you want as many back-end servers as you can muster. Perhaps as many as you have front-end clients driving the load. rick jones There is a crufty old SSLperf benchmark that took the average request/response size from SPECweb9[69] and the SPECweb96 behaviour of connect request response close but did it with SSL using IIRC RSA mumble. It leveraged the curl utility and should still be archived on ftp://ftp.cup.hp.com/dist/networking/benchmarks somewhere . __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: speed test with cavium engine
you may find that the cavium platform is as fast as your CPU - or that the PCI bandwidth is being exhausted etc - however, what you REALLY should be doing is checking your processor load when testing. after all, doing 250m 1024bit keys/s with 1% CPU laod is far far better for a server than 255m 1024bit keys/s with 68% CPU load :-) Unless it saturates the PCI bus and prevents the system from getting sufficient throughput out its NIC's and HBA's :) rick jones __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Performance issues with MIPS 4Kc
David Peat wrote: Hi, I’m trying to build some openssl functionality into a product using a MIPS 4Kc based processor running at 225 mips and coming up against significant performance problems. For example, to generate RSA keys (using the call RSA_generate_key()) takes approx 50 seconds. Based on figures we’ve heard for comparable processors (for example a 350 mips powerpc carries out this task in 6 seconds) we’d expect this to be significantly faster. Nice to see that the myth of mips is alive and well :) So my question is: does anyone know of any particular issues with the MIPS 4Kc architecture which would cause key generation to be an inefficient process? Perhaps by using 'C' versions of routines rather than hand-crafted assembly - or there being no hand-crafted assembly for it ot use? rick jones __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: How do you know you have a full packet
george r smith wrote: All, If I have learned anything from socket code it is that you can never be sure if you get a partial or a full packet. While that is true if you are using a socket associated with say a TCP connection, it is not true if you are using a socket associated with UDP, nor, at least in some modes, SCTP. It depends :) The question isn't whether something is a socket, but what is the protocol beneath the socket. rick jones as for the rest of the question, if the encryption layer didn't in and of itself provide message boundaries, one could I assume start to decrept the possibly partial message and proceded as in the non-encrypted case? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: How to access the IP/Ethernet addresses using OpenSSL
So, from SSL you can find the socket and thence the IP, and in theory you can use things like the ARP ioctls to _try_ to find the MAC (eg Ethernet) address - however that last part only really works when all the systems are in the same broadcast domain. If they are on the other side of a router or routers you will not be able to get the remote system's MAC address - the MAC address is not end-to-end in an internet or intranet, only in a LAN. So, if you are relying on finding the remote's MAC address, you are basically by definition limiting your application to a LAN. rick jones __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Reading random bytes in blocking mode
prakash babu wrote: Hello All, I am working with OpenSSL 0.9.7i on HPUX. If you are on Itanium, probably better to go to 0.9.8a or above, there are some performance improvements there. I have a configure script which performs the following operations 1. Starts the prngd rc script / # /sbin/init.d/prngd.rc start / 2. Creates self signed certificate / # /opt/openssl/bin/openssl req -new -x509 -out /opt/openssl/certs/host.pem -keyout /opt/openssl/private/hostkey.pem -nodes -subj ///C=US/ST=CA/L=City/O=Company/CN=localhost/[EMAIL PROTECTED]// /tmp/hostcert.out 21 / This script executes during system reboot. Some times the creation of the self signed certificate fails due to lack of random bytes. This problem does not occur during manual script execution What can be the reason. Can reading random bytes from prngd in *blocking mode* solve this problem. On which version of HP-UX are you running? If sufficiently contemporary, there may already be /dev/random or /dev/urandom from which one can pull bytes. rick j ones __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: SSL_shutdown and SIGPIPE
Girish Venkatachalam wrote: SIGPIPE is fatal if not handled or ignored and it can come at any time during the TCP session. Which means that none of the solutions suggested by others in the list will work. And it is wrong to rely on OpenSSL for solving a TCP closure at the remote end which is essentially a TCP issue. Not to say that OpenSSL is or is not partially culpable, but things like SIGPIPE/EPIPE are not _solely_ the responsibility of TCP. Connection close handshaking is the joint responsibility of TCP and its user. rick jones __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: SSL_shutdown and SIGPIPE
Gayathri Sundar wrote: Probably you can call the following iRet = SSL_get_shutdown(pSSL); if(iRet = 0) SSL_shutdown(pSSL); This is because, SSL_shutdown writes data on the wire, i.e the closure alerts..and if a FIN was received meanwhile, you will catch a SIGPIPE..this piece of code, actually saves me from this.. Strictly speaking, it isn't that a FIN was received. Receipt of the FIN in and of itself does not mean that the remote TCP endpoint is gone, nor that it is unwilling to accept more data. All a FIN means in and of itself is that the remote TCP and application will be sending no more data our way on the connection. For example, when the remote simply calls shutdown(SHUT_WR). Now, we also receive a FIN when the remote calls close(). In this sitation, while it was unable to communicate that via TCP, the remote is not willing to recieve any more data. The close() has implicitly stated such to the remote TCP, so when the remote TCP recieves our data, it becomes upset/worried/concernec/confused tosses its hands in the air and sends us a RST segment. Receipt of that RST segment puts our end of the TCP connection into an aborted state, and an attempt to write to the socket generates the SIGPIPE. Generally, this will not be seen by us until our _second_ access of the socket - first the write to trigger the RST from the remote, and then some other socket call - typically another write IIRC, but I think it could be a recv. SIGPIPE/EPIPE is our local TCP's way of telling us that we screwed-up in the application-level handshaking between the ends. A variation of the close() scenario is if the remote application is (bogusly IMO) using an abortive close a la SO_LINGER. In that case they emit a RST and go away. Either we receive that RST and go SIGPIPE/EPIPE on the next socket call, or we don't see that RST (it is lost) and we follow a path much like the FIN. The only way to be more or less sure we won't get an EPIPE/SIGPIPE is to preface all our socket calls with something like select() or poll(), and even then there is still a small window of a race condition, and of course the slight matter of the select/poll overhead... rick jones __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Installing OpenSSL on HPUX 10.2
Riewski, Martin Eric wrote: Hi, I'm getting errors when installing OpenSSL on a HPUX 10.2 box. This is info about box: HP-UX i3107spw B.10.20 A 9000/847 I ran ./config and this is output: $ ./config Operating system: 9000/847-hp-hpux1x Configuring for hpux-parisc-cc elif [ 528 -ge 523 ]; then # PA-RISC 1.0 CPU OUT=hpux-parisc-cc-cc target already defined - hpux-parisc-cc (offending arg: elif) Then make These are the errors: $ make making all in crypto... /opt/ansic/bin/cc -I. -I.. -I../include -O -c cryptlib.c cpp: cryptlib.c, line 170: warning 2013: Unknown preprocessing directive. cc: ../include/openssl/stack.h, line 73: warning 5: const will become a keyword. cc: ../include/openssl/stack.h, line 73: error 1000: Unexpected symbol: char. cc: ../include/openssl/stack.h, line 73: warning 5: const will become a keyword. cc: ../include/openssl/stack.h, line 73: warning 5: const will become a keyword. cc: error 2017: Cannot recover from earlier errors, terminating. *** Error exit code 1 Stop. *** Error exit code 1 Stop. $ Does anyone have any ideas? Yes in part at least, the compiler you are using doesn't understand the const directive and that is making it rather confused. It strains the DIMM memory to think back that far, but I seem to recall that being a common problem with HP ANSI C in the 10.20 timeframe. It might work-out with the 10.20 compiler if you #define const to nothingness, say with a -D in the CFLAGS (or would that be -U?). There is some small chance that a later compiler with support for const was supported under HP-UX 10.20. I believe that the 847 may have been supported under 11.0 but that is a bit of a stretch of the DIMM memory as well. It may not have been supported but 11.0 probably worked on the 847 as that was basically the same as a Gsomething I think. There is a better chance that the 11.0 compilers groked const. Or, see about getting a newer system that supports 11.11 or 11.23 where I suspect life would be much happier - in particular since there is an actual HP provided OpenSSL on those releases :) rick jones Thanks, Martin Riewski (719)548-6831 [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: HPUX compile woes
Jeff Fulmer wrote: I'm trying to compile openssl-0.9.8a on HPUX with the following configuration: #!/bin/sh ./config \ --prefix=/usr/local/ssl \ no-asm \ threads \ zlib \ -fPIC It barfs here everytime. I wouldn't think it would go to the assembler with the no-asm: gcc -I.. -I../.. -I../../include -DZLIB -DOPENSSL_THREADS -DDSO_DL -fPIC -D_REENTRANT -march=2.0 -O3 -DB_ENDIAN -D_REENTRANT -c -o b_print.o b_print.c /var/tmp/cc8MBUWc.s: Assembler messages: /var/tmp/cc8MBUWc.s:1242: Error: Unknown opcode: `fneg' make[2]: *** [b_print.o] Error 1 make[2]: Leaving directory `/home/jdfulmer/src/openssl-0.9.8a/crypto/bio' make[1]: *** [subdirs] Error 1 make[1]: Leaving directory `/home/jdfulmer/src/openssl-0.9.8a/crypto' make: *** [build_crypto] Error 1 Any thoughts? First thought, _which_ HPUX revision and platform (PA or IPF)? (I'm guessing PA since it says -march=2.0 but who knows... :) Second, _which_ gcc version? Third, is the /var/tmp/cc8MBUWc.s file an assembly file from openssl, or is it perhaps an assembly file from the compiler and there is a mismatch bewteen the front-end and the back-end? Is gcc using the gnu (?) assembler or the HP assembler? I've no idea which it should use, but do recall there being issues in that area in the past in other places. Fourth - any particular reason you are tossing-out any of the previous good work done for fast assembly versions of some things? rick jones BTW, that reminds me of something I've been meaning to ask - does the --no-asm simply preclude using stuff in a -s file, or will it also disable the use of assembly that is inline in a .c file? I seem to recall that some of the hand-crafted assembly routines for some platforms are in .c files rather than .s files. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: HPUX compile woes
Second, _which_ gcc version? Reading specs from /opt/gcc/lib/gcc-lib/hppa2.0n-hp-hpux11.00/2.95.2/specs gcc version 2.95.2 19991024 (release) Are you still running 11.0? rick jones __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: HPUX compile woes
Jeff Fulmer wrote: On Thu, Jan 26, 2006 at 12:58:21PM -0800, Rick Jones wrote: Second, _which_ gcc version? Reading specs from /opt/gcc/lib/gcc-lib/hppa2.0n-hp-hpux11.00/2.95.2/specs gcc version 2.95.2 19991024 (release) Are you still running 11.0? Yeah, B.11.00 Tick tock... bummer you aren't on a later OS, you could grab the OpenSSL from HP's Internet Express bits. Or if having the HP compiler would have helped you could have used one of the systems at www.testdrive.hp.com (guessing). Do other things compile cleanly with the ancient gcc? _Is_ there any chance of using the HP ANSI C compiler if for no other reason than to be a sanity check? I suppose trying to get a later gcc might be another interesting excercise. rick __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: building openssl0.9.8a fails
Erik Leunissen wrote: L.S. Building openssl0.9.8a on Linux, using the following commands: ./config shared make failed with the following error message: gcc -I.. -I../.. -I../../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -Wall -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DSHA1_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -c -o ui_openssl.o ui_openssl.c In file included from /usr/include/termio.h:6, from ui_openssl.c:224: /usr/include/sys/ioctl.h:42: error: conflicting types for `ioctl' /usr/local/include/unistd.h:72: error: previous declaration of `ioctl' make[2]: *** [ui_openssl.o] Error 1 make[2]: Leaving directory `/usr/local/src/openssl-0.9.8a/crypto/ui' make[1]: *** [subdirs] Error 1 make[1]: Leaving directory `/usr/local/src/openssl-0.9.8a/crypto' make: *** [build_crypto] Error 1 Any idea what's wrong? To my untrained eye it looks like a foul-up with the system include files, or perhaps a change in what is #defined between the inclusion of ioctl.h and of termio.h. rick jones __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: building openssl0.9.8a fails
Erik Leunissen wrote: Rick Jones wrote: To my untrained eye it looks like a foul-up with the system include files, or perhaps a change in what is #defined between the inclusion of ioctl.h and of termio.h. OK. Is there any direction for me to take in order to cure this (I don't know what to look for). I would start by looking at both include files in an editor of your choice, finding the definition for ioctl and then looking at any encompassing #ifdef like statements. rick jones __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
