Johnny, >>In the parallel thread with the OpenSSL developers, I have been asked >>whether "NetBSD can donate the netbsd-sparc64 target (patches)" for >>inclusion in the upstream sources. I think this might be a good time >>now, as everything works...
Well, that's not exactly what I actually meant. I'd rather see cooperation on more regular basis than [occasional] "donations." As far as system and hardware specifics go "now, as everything works [in some very particular context]" is not actually very interesting. 0.9.7f is at the door with new modules [for AMD64, IA-64, PowerPC], in development branch there are and will be new modules for UltraSPARC, x86+SSE2, AMD64, IA-64, PowerPC [not to mention new algorithms]... We can engage modules in HEAD more freely counting on somebody to occasionally test it, but we don't have that luxury in 0.9.7-stable. Every line going into the latter has to be explicitly [double-]tested. Testing is what we need help with, as we don't have the variety of platforms to play with in our disposal. > I tried to send a message to openssl-dev@openssl.org, but my mail never > seemed to get through. If you could forward the patch below to the > proper list, I would really appreciate it. openssl-dev is closed list and you have to be subscribed to post. There is an public "shortcut," openssl-bugs, which can be used to report/discuss very particular problems, but I find it more appropriate to have a representative such as yourself on openssl-dev list. > The patch is relative to openssl-0.9.7e, If you're committed to help, then grab openssl-0.9.7-stable-* snapshot at ftp://ftp.openssl.org/snapshot, examine e.g. linux targets and make things work on NetBSD, in first hand on -amd64. It's shouldn't be problem [except maybe PowerPC modules, which were *never* tested on any BSD], but as previosuly mentioned it needs to be explicitly tested. Preferably do same for openssl-SNAP-*, which is a development branch. As for currently suggested changes. 1. Don't hesitate to comment on changes upon submission or even throw in some short comments directly into code. > --- Configure.orig Fri Oct 1 07:34:28 2004 > +++ Configure > +"NetBSD-sparc64", "gcc:-DTERMIOS -DB_ENDIAN -DMD32_REG_T=int -O2 > -Wall::(unknown):ULTRASPARC::SIXTY_FOUR_BIT_LONG DES_INT DES_PTR DES_RISC2 > BF_PTR::::asm/md5-sparcv9.o::::::dlfcn:bsd-gcc-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)", For example it's more than appropriate to explicitly mention that -DMD32_REG_T=int just *happened* to work around a GCC 3.3.3 bug triggered by RIPEMD code. Otherwise it's a performance option and it doesn't actually belong in sparc64 targets. > @@ -832,6 +846,10 @@ PROCESS_ARGS: > { > $libs.=$_." "; > } > + elsif (/^-Wl,(.*)$/) > + { > + $libs.=$_." "; > + } Why is it a problem? I mean I can see it in Interix [what's Interix anyway?] target, but it's appropriate to cross-reference anyway. 2. Why do all the targets have "(unknown)" in $thread_cflag field? Doesn't NetBSD have any support for multi-threaded applications? For the record. Below was properly addressed in 0.9.7 snapshots. > $des_obj=$des_enc unless (!$fips && $des_obj =~ /\.o$/); > my $fips_des_obj='asm/fips-dx86-elf.o'; > -$fips_des_obj=$fips_des_enc unless $processor eq '386'; > -my $fips_sha1_obj='asm/sx86-elf.o' if $processor eq '386'; > +$fips_des_obj=$fips_des_enc unless ($fips && $processor eq '386'); > +my $fips_sha1_obj='asm/sx86-elf.o' if ($fips && $processor eq '386'); And a common inquiry. Something I was wondering for a long time. Is it feasible to have unified targets for all or several BSD flavors? I mean e.g. BSD-sparc64 would apply to NetBSD, OpenBSD as well as FreeBSD? A. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
