[openssl.org #1413] v0.9.7l: some comments
I believe all of these things already exist in the current source. If not, please file a new ticket. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #1413] v0.9.7l: some comments
In Debian on Linux / i386, we actually build the shared library 4 times with different optimizations. Once for i386, once for i486, 586, 686/cmov. Does it really help? I can understand i386 for broadest binary compatibility, but the rest can as well be code generated for i486 but optimized for say i686. cmov in particular is bad for P4 performance for example. Also note that assembler codes detect architecture and modify behavior at run-time [though not if you compile for i386]. But do you really support i386? With modern bloatware it would be pretty much really useless. It makes more sense to have separate i386-oriented slim distribution, than target i386 in prime line... The dynamic linker will then pick up the right version depending on the cpu you use. We do the same for alpha for ev4 and ev5, Doesn't it make more sense to tell apart pre-ev6 and ev6, because byte access access instructions were added in ev6? This would actually be noticeable in OpenSSL context. and sparc for v8 and v9. If you care about i386, why not care about sparcv7:-) A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1413] v0.9.7l: some comments
Hello Kurt, [...] I've enclosed it inside an #ifdef checking for the symbol HAVE_POLL_H, which `./Configure' should check for and using select() instead. I thought poll() just used select() internaly in those version of the kernel? oops, I've had a look inside the kernel and you're right. Never the less poll.h doesn't exist, instead sys/poll.h needs to be included, so I've corrected the patch: ### start of diff ### --- openssl-0.9.7l/crypto/rand/rand_unix.c.orig 2006-06-30 10:15:13.0 +0200 +++ openssl-0.9.7l/crypto/rand/rand_unix.c 2006-10-16 11:12:34.0 +0200 @@ -125,7 +125,7 @@ #include unistd.h #include time.h #if defined(OPENSSL_SYS_LINUX) /* should actually be available virtually everyw here */ -# include poll.h +# include sys/poll.h /* added sys/ -- (ThMO) */ #endif #include limits.h #ifndef FD_SETSIZE ### end of diff ### · ./config shared...: a shared library build compiles all files using -fPIC, which is correct for a shared library, but not for a static one, since refer= ences to global variables are encoded more time-consuming, while -fPIC is active, which means that for a static build, the package need to be configured a second time: Yes, if you want both a shared and static lib, the best thing to do is build everything twice, once using -fPIC and once without, and I don't see what you want to change about it? What I would like to see is a single Makefile doing both in one go, which simplies things a lot, e.g. considering the openssl binary, the following procedure is needed: · make -f Makefile.shared · installing the stuff · make -f Makefile.static · cd apps · cp Makefile GNUmakefile · vi GNUmakefile [replacing the ../lib*.a with -l*] · make -C .. · rm GNUmakefile · installing lib*.a and openssl The binary will be reduced in size with the above procedure from 300 kB down to 287 kB, since during the first run it will be compiled with -fPIC too... THX for listening. CU Tom. (Thomas M.Ott) Germany __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1413] v0.9.7l: some comments
Hi, What I would like to see is a single Makefile doing both in one go, which simplies things a lot, e.g. considering the openssl binary, the following procedure is needed: As long as that does not disable the ability to build static libs _with_ -fPIC flag (there are people who want to be able to build shared objects that use a fixed (i.e. static) openssl library, which requires the static lib to have been build with -fPIC on most architectures), why not do such a change? However, I fear that's complicating things more than the saving of 2 or 3% in size is worth. Regards, Stefan __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1413] v0.9.7l: some comments
On Mon, Oct 16, 2006 at 11:47:48AM +0200, ThMO via RT wrote: What I would like to see is a single Makefile doing both in one go, which simplies things a lot, e.g. considering the openssl binary, the following procedure is needed: · make -f Makefile.shared · installing the stuff · make -f Makefile.static · cd apps · cp Makefile GNUmakefile · vi GNUmakefile [replacing the ../lib*.a with -l*] · make -C .. · rm GNUmakefile · installing lib*.a and openssl The binary will be reduced in size with the above procedure from 300 kB down to 287 kB, since during the first run it will be compiled with -fPIC too... In Debian on Linux / i386, we actually build the shared library 4 times with different optimizations. Once for i386, once for i486, 586, 686/cmov. The dynamic linker will then pick up the right version depending on the cpu you use. We do the same for alpha for ev4 and ev5, and sparc for v8 and v9. On i386 with 0.9.8c this results in the following shared objects: -rw-r--r-- 1 root root 1209080 Oct 2 18:55 /usr/lib/i486/libcrypto.so.0.9.8 -rw-r--r-- 1 root root 241664 Oct 2 18:55 /usr/lib/i486/libssl.so.0.9.8 -rw-r--r-- 1 root root 1193080 Oct 2 18:55 /usr/lib/i586/libcrypto.so.0.9.8 -rw-r--r-- 1 root root 236736 Oct 2 18:55 /usr/lib/i586/libssl.so.0.9.8 -rw-r--r-- 1 root root 1270520 Oct 2 18:55 /usr/lib/i686/cmov/libcrypto.so.0.9.8 -rw-r--r-- 1 root root 252640 Oct 2 18:55 /usr/lib/i686/cmov/libssl.so.0.9.8-rw-r--r-- 1 root root 1319672 Oct 2 18:55 /usr/lib/libcrypto.so.0.9.8 -rw-r--r-- 1 root root 252864 Oct 2 18:55 /usr/lib/libssl.so.0.9.8 static: -rw-r--r-- 1 root root 2217720 Oct 2 18:55 /usr/lib/libcrypto.a -rw-r--r-- 1 root root 359702 Oct 2 18:55 /usr/lib/libssl.a And some engines: -rw-r--r-- 1 root root 14704 Oct 2 18:55 /usr/lib/ssl/engines/lib4758cca.so-rw-r--r-- 1 root root 14596 Oct 2 18:55 /usr/lib/ssl/engines/libaep.so -rw-r--r-- 1 root root 11312 Oct 2 18:55 /usr/lib/ssl/engines/libatalla.so -rw-r--r-- 1 root root 19592 Oct 2 18:55 /usr/lib/ssl/engines/libchil.so -rw-r--r-- 1 root root 17560 Oct 2 18:55 /usr/lib/ssl/engines/libcswift.so -rw-r--r-- 1 root root2856 Oct 2 18:55 /usr/lib/ssl/engines/libgmp.so -rw-r--r-- 1 root root9404 Oct 2 18:55 /usr/lib/ssl/engines/libnuron.so -rw-r--r-- 1 root root 19312 Oct 2 18:55 /usr/lib/ssl/engines/libsureware.so -rw-r--r-- 1 root root 15668 Oct 2 18:55 /usr/lib/ssl/engines/libubsec.so Kurt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1413] v0.9.7l: some comments
Hello, I've attached a small unified diff, fixing a problem: · crypto/rand/rand_unix.c: linux kernel v2.0.35 doesn't support the `poll' system call, so this file will only compile with the patch applied. I've enclosed it inside an #ifdef checking for the symbol HAVE_POLL_H, which `./Configure' should check for and using select() instead. · crypto/bf/Makefile: I've changed the references to the assembly file: ``s/586/686/g'', which should be save nowadays... · ./config no-fips: installation produces an error, since the generated Makefile tries to install some fips-container... · ./config no-dso shared: the generated Makefile defines EX_LIBS=-ldl, which isn't needed it that case, instead -lc must be given, in order for ld to encode it into the final library stub (this is a disadvantage of ELF, since for a shared library you could give numerous libraries via -lxxx, although none of them are needed) · ./config shared...: a shared library build compiles all files using -fPIC, which is correct for a shared library, but not for a static one, since refer= ences to global variables are encoded more time-consuming, while -fPIC is active, which means that for a static build, the package need to be configured a second time: library | w/ -fPIC | w/o -fPIC ++-- libcrypto.a | 1538466 b. | 1452632 b. libssl.a| 258772 b. | 243502 b. as you can see, the savings are enormous... THX for listening. CU Tom. (Thomas M.Ott) Germany __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1413] v0.9.7l: some comments
On Sun, Oct 15, 2006 at 08:18:59PM +0200, ThMO via RT wrote: Hello, I've attached a small unified diff, fixing a problem: · crypto/rand/rand_unix.c: linux kernel v2.0.35 doesn't support the `poll' system call, so this file will only compile with the patch applied. I've enclosed it inside an #ifdef checking for the symbol HAVE_POLL_H, which `./Configure' should check for and using select() instead. I thought poll() just used select() internaly in those version of the kernel? · ./config shared...: a shared library build compiles all files using -fPIC, which is correct for a shared library, but not for a static one, since refer= ences to global variables are encoded more time-consuming, while -fPIC is active, which means that for a static build, the package need to be configured a second time: Yes, if you want both a shared and static lib, the best thing to do is build everything twice, once using -fPIC and once without, and I don't see what you want to change about it? Kurt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1413] v0.9.7l: some comments
On Sun, Oct 15, 2006 at 08:18:59PM +0200, ThMO via RT wrote: Hello, I've attached a small unified diff, fixing a problem: · crypto/rand/rand_unix.c: linux kernel v2.0.35 doesn't support the `poll' system call, so this file will only compile with the patch applied. I've enclosed it inside an #ifdef checking for the symbol HAVE_POLL_H, which `./Configure' should check for and using select() instead. I thought poll() just used select() internaly in those version of the kernel? · ./config shared...: a shared library build compiles all files using -fPIC, which is correct for a shared library, but not for a static one, since refer= ences to global variables are encoded more time-consuming, while -fPIC is active, which means that for a static build, the package need to be configured a second time: Yes, if you want both a shared and static lib, the best thing to do is build everything twice, once using -fPIC and once without, and I don't see what you want to change about it? Kurt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
