Andy Polyakov wrote:
>
> 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 am the pkgsrc maintainer for OpenSSL, and I'm reworking the package
structure to allow for simpler testing of the openssl snapshots. Since
pkgsrc has a reasonably wide number of users/testers on NetBSD as well
as Solaris, Linux, and MacOS X, we should be able to get reasonable
coverage for test results.
> 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.
Having discussed it with several NetBSD developers, I've decided to
subscribe to openssl-dev. Several other developers are subscribed to
the -announce list to watch for new releases, but I'll be on the -dev
list to help with in-between-releases testing and development of OpenSSL
on NetBSD.
> 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.
Okay. That wasn't clear to me from the comments in the code, but I'll
pass that along to the NetBSD/sparc64 team.
>
>> @@ -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.
The above change is GCC-specific and simply allows for passing more
sophisticated options directly to the linker.
> 2. Why do all the targets have "(unknown)" in $thread_cflag field?
> Doesn't NetBSD have any support for multi-threaded applications?
This is something I've yet to test. I'm fairly new to maintaining
OpenSSL in pkgsrc and I simply haven't had time to look over enough of
the code to see what the ramifications of setting $thread_cflag are.
I'll try to test using the native threads on NetBSD>=2.0 in a while.
> 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?
No, this would be nearly impossible to do. The various *BSDs are simply
too different in the libraries they provide, the capabilities the
operating system offers, and even in whether they expect ELF or
a.out-linked code. I speak from the experience of making the OpenSSL
package in pkgsrc work on all of the BSDs -- it's simply too difficult
to do in a way that's shorter than listing out each variation as is
currently done.
Cheers,
-- Johnny Lam <[EMAIL PROTECTED]>
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [EMAIL PROTECTED]
