Re: parallel make broken
On Wednesday 19 June 2013 07:21:39 Ben Laurie wrote: On 18 June 2013 22:35, Mike Frysinger vap...@gentoo.org wrote: On Tuesday 18 June 2013 07:37:55 Richard Weinberger wrote: While building openssl-1.0.1e I noticed that the parallel build is broken. yes, it's pretty much always been broken I found this patch on the net: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-libs/openssl /fi les/openssl-1.0.1-parallel-build.patch With it applied openssl builds fine in parallel. heh, you've found me! the referenced ticket says it's been merged, but it doesn't seem that way (at least for the latest branch). You are right it hasn't been merged. One problem with it is it doesn't work with BSD make (BSD make doesn't understand | in dependencies). true, but the patch posted to RT didn't include that, and that usage shows up only twice in the current Gentoo patch. plenty of the other parts can be merged now so it's not nearly as terrible. i wonder if the | can be written instead like: lib: $(MAKE) subdirs $(MAKE) $(LIB) @touch lib $(LIB): $(LIBOBJ) ... -mike signature.asc Description: This is a digitally signed message part.
Re: [Patch] ALPN Implementation for OpenSSL
On 21 June 2013 02:29, Thor Lancelot Simon t...@panix.com wrote: On Thu, Jun 20, 2013 at 09:30:32PM +, Jeff Mendoza (MS OPEN TECH) wrote: Yeah, my point was that in the perfect world, you'd support both at runtime (at least on the server-side) and either ALPN or NPN could be used. I want to have a library that supports both, not either-or. Yes, supporting both at runtime would be best. But having a compile-time option now, and defaulting to NPN should keep this from being a blocking issue with the patch, correct? I don't speak for the OpenSSL project, but I'd suggest they should treat it as one. It positively reeks of embrace and extend. After all, the effect is to force all build systems producing system default packages of OpenSSL to pick one way or the other, ensuring that both won't work at the same time. That's not really embrace and extend, but nevertheless it seems like an unacceptable design choice. I suggest you need to figure out how to make both ALPN and NPN work in a single build to have any chance of acceptance at all. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: parallel make broken
On 22 June 2013 19:04, Mike Frysinger vap...@gentoo.org wrote: On Wednesday 19 June 2013 07:21:39 Ben Laurie wrote: On 18 June 2013 22:35, Mike Frysinger vap...@gentoo.org wrote: On Tuesday 18 June 2013 07:37:55 Richard Weinberger wrote: While building openssl-1.0.1e I noticed that the parallel build is broken. yes, it's pretty much always been broken I found this patch on the net: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-libs/openssl /fi les/openssl-1.0.1-parallel-build.patch With it applied openssl builds fine in parallel. heh, you've found me! the referenced ticket says it's been merged, but it doesn't seem that way (at least for the latest branch). You are right it hasn't been merged. One problem with it is it doesn't work with BSD make (BSD make doesn't understand | in dependencies). true, but the patch posted to RT didn't include that, and that usage shows up only twice in the current Gentoo patch. plenty of the other parts can be merged now so it's not nearly as terrible. i wonder if the | can be written instead like: lib: $(MAKE) subdirs $(MAKE) $(LIB) @touch lib $(LIB): $(LIBOBJ) ... I don't know, but FWIW, I've also been working on -j stuff, but using the mk1mf script (see the GitConfigure and GitMake scripts in master and 1.0.2). My version is at least twice as fast as yours - on my machine :-) Possibly the right answer is to simply move to a single makefile... __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3078] Makefile: install rule builds components
From OpenSSL 1.0.1e (https://www.openssl.org/source/openssl-1.0.1e.tar.gz). Makefile.org and Makefile's 'install' rule is: install: all install_docs install_sw The 'all' rule is default and is: all: Makefile build_all openssl.pc libssl.pc libcrypto.pc This should not be a problem from a standard cycle: ./config fips shared ... make depend make make install However, there are a few problems. First, Stallman states (in his GNU Make book) that the 'install' rule should copy the executable and axillary files, and not build objects [1]. This would be a harmless transgression except it breaks install during cross-compilation. Second, 'all' appears to have a dependency that is always out of date (perhaps due to a directory time somewhere). So even if you `make depend` and then `make` (with 'all' being default), targets will still be built during 'install'. Third, the cycle often includes `sudo make install`: ./config fips shared ... make depend make sudo make install `sudo` drops a user's path so cross-compilation path changes are lost. When GCC is re-invoked, the required $(CC) (for example, arm-linuxeabi-gcc) cannot be found. JW [1] GNU Make, p. 91. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3078] Makefile: install rule builds components
Below is a sample from Mac OS X. If this was run for Android, then CC=arm-linuxeabi-gcc and RANLIB=arm-linuxeabi-ranlib. Neither would be found when sudo drops the user's path. $./config shared -no-comp -no-sslv2 -no-sslv3 … $ make depend … $ make ... $ sudo make install Password: making all in crypto... making all in crypto/objects... make[2]: Nothing to be done for `all'. making all in crypto/md4... make[2]: Nothing to be done for `all'. making all in crypto/md5... make[2]: Nothing to be done for `all'. ... making all in crypto/srp... make[2]: Nothing to be done for `all'. making all in crypto/cmac... make[2]: Nothing to be done for `all'. if [ -n libcrypto.1.0.0.dylib libssl.1.0.0.dylib ]; then \ (cd ..; make libcrypto.1.0.0.dylib); \ fi [ -z ] || cc -fPIC -fno-common -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -arch i386 -O3 -fomit-frame-pointer -DL_ENDIAN -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -Iinclude \ -DFINGERPRINT_PREMAIN_DSO_LOAD -o fips_premain_dso \ fips_premain.c fipscanister.o \ libcrypto.a making all in ssl... if [ -n libcrypto.1.0.0.dylib libssl.1.0.0.dylib ]; then \ (cd ..; make libssl.1.0.0.dylib); \ fi [ -z ] || cc -fPIC -fno-common -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -arch i386 -O3 -fomit-frame-pointer -DL_ENDIAN -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -Iinclude \ -DFINGERPRINT_PREMAIN_DSO_LOAD -o fips_premain_dso \ fips_premain.c fipscanister.o \ libcrypto.a making all in engines... ... On Thu, Jun 20, 2013 at 2:22 PM, Jeffrey Walton noloa...@gmail.com wrote: From OpenSSL 1.0.1e (https://www.openssl.org/source/openssl-1.0.1e.tar.gz). Makefile.org and Makefile's 'install' rule is: install: all install_docs install_sw The 'all' rule is default and is: all: Makefile build_all openssl.pc libssl.pc libcrypto.pc This should not be a problem from a standard cycle: ./config fips shared ... make depend make make install However, there are a few problems. First, Stallman states (in his GNU Make book) that the 'install' rule should copy the executable and axillary files, and not build objects [1]. This would be a harmless transgression except it breaks install during cross-compilation. Second, 'all' appears to have a dependency that is always out of date (perhaps due to a directory time somewhere). So even if you `make depend` and then `make` (with 'all' being default), targets will still be built during 'install'. Third, the cycle often includes `sudo make install`: ./config fips shared ... make depend make sudo make install `sudo` drops a user's path so cross-compilation path changes are lost. When GCC is re-invoked, the required $(CC) (for example, arm-linuxeabi-gcc) cannot be found. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3080] Android NEON and CFLAGS options
In reference to https://android.googlesource.com/platform/ndk/+/ics-mr0/docs/STANDALONE-TOOLCHAIN.html. It appears there are some flags that should be present when targeting Neon on Android: CFLAGS='-march=armv7-a -mfloat-abi=softfp -mfpu=neon' __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: parallel make broken
On Saturday 22 June 2013 15:07:49 Ben Laurie wrote: On 22 June 2013 19:04, Mike Frysinger vap...@gentoo.org wrote: On Wednesday 19 June 2013 07:21:39 Ben Laurie wrote: On 18 June 2013 22:35, Mike Frysinger vap...@gentoo.org wrote: On Tuesday 18 June 2013 07:37:55 Richard Weinberger wrote: While building openssl-1.0.1e I noticed that the parallel build is broken. yes, it's pretty much always been broken I found this patch on the net: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-libs/open ssl /fi les/openssl-1.0.1-parallel-build.patch With it applied openssl builds fine in parallel. heh, you've found me! the referenced ticket says it's been merged, but it doesn't seem that way (at least for the latest branch). You are right it hasn't been merged. One problem with it is it doesn't work with BSD make (BSD make doesn't understand | in dependencies). true, but the patch posted to RT didn't include that, and that usage shows up only twice in the current Gentoo patch. plenty of the other parts can be merged now so it's not nearly as terrible. i wonder if the | can be written instead like: lib: $(MAKE) subdirs $(MAKE) $(LIB) @touch lib $(LIB): $(LIBOBJ) ... I don't know, but FWIW, I've also been working on -j stuff, but using the mk1mf script (see the GitConfigure and GitMake scripts in master and 1.0.2). My version is at least twice as fast as yours - on my machine :-) to be fair, i was just trying to make it work rather than rewrite things unfortunately mk1mf is a perl script, and i've been doing my damnedest to make sure perl isn't a requirement to build a base system. we've been able to avoid this so far w/openssl ... Possibly the right answer is to simply move to a single makefile... that might work -mike signature.asc Description: This is a digitally signed message part.
