Re: Build Failure On Digital Unix 4.0D
I got two replies :- Richard Levitte said : Richard Well, it looks like Compaq C will just ignore -fPIC when it compiles, Richard and try to pass it on to ld when linking is going on. However, Richard there's no support for -fPIC anywhere in True64. [ Thanks Richard: I have no idea *what* PIC/pic is about, so I'll just let this slip by me :-( ] Richard If you check the Richard manual for ld, you'll probably find a few lines about '-f fil', where Richard the filling is expected to be a 4-byte hex constant. Well you're quite right; the ld man page says : -f fill Set the fill pattern for "holes" within an output section. The argu- ment fill is a four-byte hexadecimal constant. But what I don't understand is why you're talking about a problem with "-fPIC" when my compilation objected to "-std1" ... Richard My suggestion: don't configure with -fPIC on True64. Anyway, I followed your suggestion, configuring with "./config no-idea", and my compilation completed OK, and "make test" has run OK. Since the "-fPIC" parameter is documented in the MOD_SSL documentation as being required when building OpenSSL if we want to build MOD_SSL as an Apache DSO module, does this mean I can't run Apache/MOD_SSL configured with dynamic shared modules on a Digital Unix platform ? cut == Meanwhile, Michael Barnes emailed me directly to say : Michael try this: Michael Michael cc -o openssl openssl.o verify.o asn1pars.o req.o dgst.o dh.o dhparam.o Michael enc.o passwd.o gendh.o errstr.o ca.o pkcs7.o crl2p7.o crl.o rsa.o dsa.o Michael dsaparam.o x509.o genrsa.o gendsa.o s_server.o s_client.o speed.o s_time.o Michael apps.o s_cb.o s_socket.o app_rand.o version.o sess_id.o ciphers.o nseq.o Michael pkcs12.o pkcs8.o spkac.o smime.o rand.o -L. -L.. -L../.. -L../../.. -lssl Michael -lcrypto Michael Michael apparently Digital unix's cc cannot correctly tell between a link Michael and a compile. The above command should work, but I do not have Michael access to a Digital unix machine right now. Thanks Michael. I tried this command hands-on and it worked. Looking at your cc call, you're supplying all the same input modules as the distro does, but omitting most of the commandline switches including "-fPIC" *and* "-stdl". I guess that will avoid any complaining about either of those options, but what is the effect on the compilation of omitting the other switches (e.g. -DMONOLITH, -DNO_IDEA, -tune, -readonly-strings) ? And should I submit bugs on all this ? (Or is Digital Unix support "experimental" ?) Nick Systems Team, EDS Healthcare, Bristol, UK __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Build Failure On Digital Unix 4.0D
From: "Boyce, Nick" [EMAIL PROTECTED] nick.boyce Richard If you check the manual for ld, you'll probably nick.boyce Richard find a few lines about '-f fil', where the nick.boyce Richard filling is expected to be a 4-byte hex constant. nick.boyce nick.boyce Well you're quite right; the ld man page says : nick.boyce -f fill nick.boyce Set the fill pattern for "holes" within an output section. The argu- nick.boyce ment fill is a four-byte hexadecimal constant. nick.boyce nick.boyce But what I don't understand is why you're talking about a nick.boyce problem with "-fPIC" when my compilation objected to nick.boyce "-std1" ... Ah. Well, I'll do some qualified guesses: suppose that the command line parser in ld is the stupid kind that checks if argv[i][0] is '-' and then just does a switch(argv[i][1]) to process each possible switch, and that for any switch value it will take argv[i+1]. So, it finds your -fPIC, thinks it found -f and tries to use the next argument as fill. That happens to be "-std1" which is very far from a hex value, so it complains... And yes, I've seen that kind of parsing before, especially in pretty old programs. -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Chairman@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 Redakteur@Stacken \ SWEDEN \ or +46-709-50 36 10 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Software Engineer, Celo Communications: http://www.celocom.com/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Build Failure On Digital Unix 4.0D
Richard Levitte wrote : nick.boyce But what I don't understand is why you're talking about a nick.boyce problem with "-fPIC" when my compilation objected to nick.boyce "-std1" ... Ah. Well, I'll do some qualified guesses: suppose that the command line parser in ld is the stupid kind that checks if argv[i][0] is '-' and then just does a switch(argv[i][1]) to process each possible switch, and that for any switch value it will take argv[i+1]. So, it finds your -fPIC, thinks it found -f and tries to use the next argument as fill. That happens to be "-std1" which is very far from a hex value, so it complains... Words fail me ... and this is a commercial big-bucks Unix ... Thanks for the analysis. Erm ... I need to find a way forward on this. Should I submit a bug to Compaq against Digital Unix's linker, or submit a bug against OpenSSL to ask for a workaround to be built in for Digital Unix platforms ? And anyway, if Digital Unix won't support "PIC" (whatever it is) should I give up on building OpenSSL/MOD_SSL/Apache with DSO modules ? (Is this the wrong list to ask that question on ?) I suppose maybe it's just MOD_SSL that can't be shared. Cheers, Nick Boyce Systems Team, EDS Healthcare, Bristol, UK __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Build Failure On Digital Unix 4.0D
Boyce, Nick wrote: Richard Levitte wrote : nick.boyce But what I don't understand is why you're talking about a nick.boyce problem with "-fPIC" when my compilation objected to nick.boyce "-std1" ... Ah. Well, I'll do some qualified guesses: suppose that the command line parser in ld is the stupid kind that checks if argv[i][0] is '-' and then just does a switch(argv[i][1]) to process each possible switch, and that for any switch value it will take argv[i+1]. So, it finds your -fPIC, thinks it found -f and tries to use the next argument as fill. That happens to be "-std1" which is very far from a hex value, so it complains... Richard's spot on here. (he usually is, btw) Always remember anything originating from, named like, "OSF" (my ex-employer) will have "anomolies". (DigUnix=OSF/1) skip -fPIC or -f*** it's not there. Erm ... I need to find a way forward on this. Should I submit a bug to Compaq against Digital Unix's linker, or submit a bug against OpenSSL to ask for a workaround to be built in for Digital Unix platforms ? openssl. might want to test with the ld flags below as well. And anyway, if Digital Unix won't support "PIC" (whatever it is) should I give up on building OpenSSL/MOD_SSL/Apache with DSO modules ? (Is this the wrong list to ask that question on ?) some thoughts and an outcome should be put onto dev, but knowing Richard he'll have this done and cvs committed by 2 or 3 in the morning ;-) I suppose maybe it's just MOD_SSL that can't be shared. no no no no no. Never give up on a challenge - especially when your employer is paying for it. DigUnix can most certainly build shared libraries - it's just that the model is well, sorta different. Check in an old OSF/1 programmer's manual (if u can find one) to see how the global address table (most call it a global offset table - except as i said we were different) works with their linker. standard flags for cc - except drop -fPIC check and try " -shared " and " -expect_unresolved "*" " for ld flags (lookup -expect_unresolved "*" for exact syntax) my OSF/1 manual's at the office ;-) Andrew -- Once an OSF'r always ... __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Build Failure On Digital Unix 4.0D
From: agray [EMAIL PROTECTED] agray Richard's spot on here. (he usually is, btw) *pu* agray Always remember anything originating from, named like, "OSF" agray (my ex-employer) will have "anomolies". (DigUnix=OSF/1) Heh... [...] agray some thoughts and an outcome should be put onto dev, but knowing Richard agray he'll have this done and cvs committed by 2 or 3 in the morning ;-) Uhmmm, there's actually nothing to currently fix in OpenSSL itself on this issue... And oh, 2 or 3 in what timezone? :-) agray standard flags for cc - except drop -fPIC agray check and try " -shared " and " -expect_unresolved "*" " for ld flags agray (lookup -expect_unresolved "*" for exact syntax) my OSF/1 manual's at agray the office ;-) Ah. Having just started to play with True64, I haven't had the time to look at those yet. And in any case, I personally wouldn't trust a shared OpenSL library just yet. There are just too many things that are about to change... It's good to know there's a human resource that knows this well :-). -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Chairman@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 Redakteur@Stacken \ SWEDEN \ or +46-709-50 36 10 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Software Engineer, Celo Communications: http://www.celocom.com/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Build Failure On Digital Unix 4.0D
Many thanks to Richard and Andrew, who explained a DigUnix box's behaviour magnificently, and also to a bunch of other folks who emailed me direct to explain the "-fPIC" stuff (which I now know is not relevant to DigUnix - it generates relocatable code anyway). I'm now pressing ahead on building OpenSSL/Apache/Mod_SSL *with* DSO Apache modules, but without any special build params for OpenSSL. I'll report back if anything noteworthy happens. (Oh, and I'll report that -fPIC isn't needed to the Mod_SSL list - later - I'm not subscribed at the moment). Thanks again. Nick Systems Team, EDS Healthcare, Bristol, UK __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Build Failure On Digital Unix 4.0D
Always watch for -shared and the -expect_unresolved "*" for DigUnix ld options. I was building api libraries against ssleay for Netscape server 1--2.x along time ago (3-5 yrs ago) and as i remember this was necessary. I'm now pressing ahead on building OpenSSL/Apache/Mod_SSL *with* DSO Apache modules, but without any special build params for OpenSSL. I'll report back if anything noteworthy happens. I'd hesitate to guess that a couple modssl devs might be on this list as well ;-) Just remember there ARE more difficult OS's you could be working on. Andrew __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Build Failure On Digital Unix 4.0D
2 or 3 your time of course ;-) And in any case, I personally wouldn't trust a shared OpenSL library just yet. There are just too many things that are about to change... i've seen - i'm playing hell on keeping up on what's going on. You and Geoff on the engine work as well as Steve starting on the asn - he's doing much more of the interim step, while i changed focus, dropped snacc as a compiler and am writing a template driven engine to handle it much as what eric was talking about in frankfurt. Unfortunately It's a MAJOR rewrite and couldn't incorporate without a major version (OpenSSL 2.0.0 maybe more like 200.0.0) I figure if he's doing 20k for ssl-c i should be able to knock off 30 ;-). I do really like the design steve's focusing on right now though with the c2i, i2c implementations - skipping the headers on IMPLICIT decodes and go straight to the content is a good idea. One "Evil hack" down the drain. So who's gonna rework the evp stuff ;-) It's good to know there's a human resource that knows this well :-). I wouldn't go that far-- Andrew __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Build Failure On Digital Unix 4.0D
agray wrote: 2 or 3 your time of course ;-) And in any case, I personally wouldn't trust a shared OpenSL library just yet. There are just too many things that are about to change... i've seen - i'm playing hell on keeping up on what's going on. You and Geoff on the engine work as well as Steve starting on the asn - he's doing much more of the interim step, while i changed focus, dropped snacc as a compiler and am writing a template driven engine to handle it much as what eric was talking about in frankfurt. Unfortunately It's a MAJOR rewrite and couldn't incorporate without a major version (OpenSSL 2.0.0 maybe more like 200.0.0) I figure if he's doing 20k for ssl-c i should be able to knock off 30 ;-). I do really like the design steve's focusing on right now though with the c2i, i2c implementations - skipping the headers on IMPLICIT decodes and go straight to the content is a good idea. One "Evil hack" down the drain. So who's gonna rework the evp stuff ;-) Well FYI the i2c, c2i stuff is only the 'visible' part of something going on behind the scenes. By themselves they cut down on things like the duplication in INTEGER and ENUMERATED but they are needed by some experimental ASN1 template driven stuff I'm working on. Its all very incomplete and buggy as hell but its progressing. I've got the encoder going and it now can do almost anything the current OpenSSL ASN1 can do, and quite a few things it cannot like APPLICATION and PRIVATE tags. It also retains 100% compatibility with the current ASN1 structures behaviour e.g. STACKs for SEQUENCE OF and similar stuff. The decoder is much harder to do but its starting to take shape. I intend to ultimately use SNACC as a compiler but using its template output as the input to a converter to OpenSSL template format. When its settled down and tested a bit it'll be checked in... however its going to take a while to tame this, this is one *seriously* horrible area to work in. Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: [EMAIL PROTECTED] Senior crypto engineer, Celo Communications: http://www.celocom.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: [EMAIL PROTECTED] PGP key: via homepage. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Build Failure On Digital Unix 4.0D
I intend to ultimately use SNACC as a compiler but using its template output as the input to a converter to OpenSSL template format. yea - the one i noticed was the bitstr start. I'm having a hell of a time doing cvs updates recently - very poor connexns from home. have you started this - i.e. snacc template openssl formatted output? structures behaviour e.g. STACKs for SEQUENCE OF hasn't SEQUENCE OF been deprecated? *seriously* horrible area to work in. i believe "serious" is an understatement Andrew __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Build Failure On Digital Unix 4.0D
agray wrote: I intend to ultimately use SNACC as a compiler but using its template output as the input to a converter to OpenSSL template format. yea - the one i noticed was the bitstr start. I'm having a hell of a time doing cvs updates recently - very poor connexns from home. have you started this - i.e. snacc template openssl formatted output? I have started it but its not in the main source tree. I'll commit it when things get a bit more stable. Anyway the converter will happen later on and will convert SNACC template ASN1 to OpenSSL template C. You may notice that there's currently no such thing as an OpenSSL template :-) structures behaviour e.g. STACKs for SEQUENCE OF hasn't SEQUENCE OF been deprecated? If it is no one seems to have noticed, its still widely used. SET OF is discouraged because of the DER encoding overhead though. Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: [EMAIL PROTECTED] Senior crypto engineer, Celo Communications: http://www.celocom.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: [EMAIL PROTECTED] PGP key: via homepage. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Build Failure On Digital Unix 4.0D
From: "Boyce, Nick" [EMAIL PROTECTED] nick.boyce I've just had a go at building OpenSSL 0.9.5a on our nick.boyce Digital Unix box, but the build fails, apparently with a nick.boyce bizarre parameter error in a linker call, thus : nick.boyce === cut nick.boyce nick.boyce nick.boyce cc -DMONOLITH -I../include -DNO_IDEA -fPIC -std1 -tune host -O4 -readonly_strings -c smime.c nick.boyce cc -DMONOLITH -I../include -DNO_IDEA -fPIC -std1 -tune host -O4 -readonly_strings -c rand.c nick.boyce cc -DMONOLITH -I../include -DNO_IDEA -fPIC -std1 -tune host -O4 -readonly_strings -c openssl.c nick.boyce rm -f openssl nick.boyce cc -o openssl -DMONOLITH -I../include -DNO_IDEA -fPIC -std1 -tune host -O4 -readonly_strings openssl.o verify.o asn1pars.o req.o dgst.o dh.o dhparam.o enc.o passwd.o gendh.o errstr.o ca.o pkcs7.o crl2p7.o crl.o rsa.o dsa.o dsaparam.o x509.o genrsa.o gendsa.o s_server.o s_client.o speed.o s_time.o apps.o s_cb.o s_socket.o app_rand.o version.o sess_id.o ciphers.o nseq.o pkcs12.o pkcs8.o spkac.o smime.o rand.o -L. -L.. -L../.. -L../../.. -L.. -lssl -L.. -lcrypto nick.boyce ld: nick.boyce Badly formed hex number: -std1 nick.boyce ld: Usage: ld [options] file [...] nick.boyce *** Exit 1 nick.boyce Stop. nick.boyce *** Exit 1 nick.boyce Stop. nick.boyce === cut Well, it looks like Compaq C will just ignore -fPIC when it compiles, and try to pass it on to ld when linking is going on. However, there's no support for -fPIC anywhere in True64. If you check the manual for ld, you'll probably find a few lines about '-f fil', where the filling is expected to be a 4-byte hex constant. My suggestion: don't configure with -fPIC on True64. EOL -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Chairman@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 Redakteur@Stacken \ SWEDEN \ or +46-709-50 36 10 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Software Engineer, Celo Communications: http://www.celocom.com/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
