Autoconf #575

magnumripper · 2014-05-02T06:45:49Z

In progress by @jfoug (and me). Topic branch autoconf

Tests to add/use:

Most or all of the above should default to be used if available, but have --disable-feature options.

Other options (configure):

JOHN_SYSTEMWIDE option (--with-systemwide[=directory], see params.h)
CPU_FALLBACK options (--with-cpu-fallback, see params.h)
OMP_FALLBACK option (--with-omp-fallback, see params.h) - or should we always build it?
tuning option (set things like MD5_SSE_PARA)
X32 as an option for linux-x86-64 targets.

X32 is more or less a cross compile. Either we support it specifically using --with-X32 or something, or you'll have to say CFLAGS=-mx32 ASFLAGS=-mx32 LDFLAGS=-mx32 ./configure (which should already be supported)

New targets (Makefile)

default target
install target
debug target (using -DDEBUG -O0. For -g see next comment)
possibly we could add packaging targets too

Things to do within configure instead of make:

Plugin enumeration
john_build_rules.h file (may need extra coding for cross compiles, etc)
Enumerate bash-completion target directory

The text was updated successfully, but these errors were encountered:

magnumripper · 2014-05-02T07:15:40Z

We should always build with -g (debug) and not -s (strip), and then we'll strip within the install target. This will be a great enhancement for developers.

magnumripper · 2014-05-02T11:10:11Z

Here's a list of what is used today:

$ grep -Eho '\bOS_[^ \)=]+' *.[ch] | awk '{print $1}' | sort -u

OS_FLOCK
OS_FORK
OS_TIMER

$ grep -Eho 'HAVE_[^ \)=]+' *.[ch] | awk '{print $1}' | sort -u

DONE: These are all in autoconfig.h. They 'still' are in os.h. We may need a little work there. I do include autoconfig.h, but probably should be VERY careful about setting these. Probably ONLY systems without autoconfig (VC) should use the defines in OS.h.

magnumripper · 2014-05-02T11:14:37Z

We also have these, enumerated by current "make generic" (results shown for OSX/amd64)

#define ARCH_WORD                       long
#define ARCH_SIZE                       8
#define ARCH_BITS                       64
#define ARCH_BITS_LOG                   6
#define ARCH_BITS_STR                   "64"
#define ARCH_LITTLE_ENDIAN              1
#define ARCH_INT_GT_32                  0
#define ARCH_ALLOWS_UNALIGNED           1
#define ARCH_INDEX(x)                   ((unsigned int)(unsigned char)(x))

Edit: All but the last one are autoconf now.

magnumripper · 2014-05-02T11:46:41Z

Error handling:
If we don't have optional stuff like libgmp, we build without it. But what if we lack openssl? I guess configure should bail out and explain the problem. We could also opt to build everything we can without OpenSSL, I think there's not much things really depending on it.

Summary:
configure could end with listing what was enabled and what was not (so user sees that eg. installing librexgen would enhance JtR).

@jfoug edit:
Right now, several libs will cause ./configure to bail with a message. oSSL is one of them. There simply is too many issues. Also libm and libz cause this. These were all from 'default' LDFLAGS from old makefile. We probably want to look at some of them.

Things like lack of libgmp will issue a mesage on screen, during the ./configure. I would love to accumulate a summary message, but have not figured that out yet. But at least there is 'some' message telling a user they might want an enhanced lib, and why.

jfoug · 2014-05-02T16:44:29Z

Added HAVE_CRYPT --> HAVE_LIBCRYPT. This was a larger change.

I had to patch john.c and loader.c to use the new define. I then had to add a include "autoconfig.h" to c3_fmt.c as a wrapper, add the c3_fmt.o to the 'normal' objects, remove it from all rules, and remove -lcrypt from all rules. Now c3 will 'always' be build. It will be disabled if the lib it NOT found.

This is GOOD stuff. I now get fmt_crypt for my cygwin (IF I have installed libcrypt). Yea. We have needed an autoconf process for SOOOOOO long. It will be a long ugly process, mostly removing all the existing crap. But when done, I think this should be so much better.

magnumripper · 2014-05-02T18:02:32Z

Is there some standard unix way to globally edit all data, safely replacing one string with another?
Example would be: HAVE_GMP -> HAVE_LIBGMP (note that one is already done)

Using git, I'd do it like this (safest with pwd == base dir but in this case src/ should be fine):

$ git grep -l HAVE_GMP | xargs sed -ri s/HAVE_GMP/HAVE_LIBGMP/g

The git grep is about the same as grep <all files under git's control> (but only from current directory and down)

jfoug · 2014-05-02T18:35:59Z

What should we CHECK IN. I have added a distclean target to makefile. That does a clean, then removes these:

Makefile
autoconfig.h
config.status
config.cache
config.log

I 'think' a simple ./configure will rebuild all of those, so they likely SHOULD NOT be there. But I am not 100% sure yet.

magnumripper · 2014-05-02T18:55:02Z

@jfoug please commit your changes to the autoconf branch (if you remember how to do it 😉) I'd like to follow progress and perhaps wedge in some fixes.

Failing that, just send me a patch 😎

Edit:

What should we CHECK IN

If you pull the minor commits I did to that branch, the .gitignorewill take care of it.

jfoug · 2014-05-02T19:27:23Z

working on a patch right now. I notice that you did not put any of the Makefile.orig files in there. Was that by design? I think those should stay there, at the bare minimun as a reference. I have actually had to use one (have not figured out problem, though). The luks2john fails to link. It can not find the BIO_* functions, which are found in the libcrypto (ossl stuff). But the -lcrypto is on the command line. I have fought with it, and have not figured it out. So at this time, that target is commented out of Makefile.in (in ./src) until I get that done.

I have also added new makefile targets One of them is distclean. This is what I think we should do, prior to diffs or checking anything in.

We need to add all the cache crap into .gitignore. Some is there (I added more), but there is still stuff missing.

Jim.

jfoug · 2014-05-02T21:09:18Z

$ git grep -l HAVE_GMP | xargs sed -ri s/HAVE_GMP/HAVE_LIBGMP/g

I can also do this from command line. NOTE, many times, it is more complex than this, so I really think it takes grep to find the files, and hand editing, and often editing OTHER files where this is not even defined. The 'easy' ones, (such as if a header is there), already should be done. We will also need to look HARD at things like #ifdef _MSC_VER, #if CYGWIN etc. Some of those should be removed (possibly A LOT of them).

jfoug · 2014-05-02T21:14:04Z

magnumripper · 2014-05-02T22:11:04Z

I notice that you did not put any of the Makefile.orig files in there. Was that by design?

Oh, that was a mistake. I bet *.orig is in .gitignore

jfoug · 2014-05-02T22:24:37Z

If you have not checked in #2 yet, hold up. I am doing #3 against the current git tree

magnumripper · 2014-05-02T22:26:46Z

I just committed but that's no problem, this is a topic branch. I'll just force commit patch 3 upon patch 1.

claudioandre-br · 2014-05-03T01:28:07Z

Hi. Below a POC patch that will avoid a few warnings I'm seeing here!


diff --git a/src/SIPdump.c b/src/SIPdump.c
index 1bc0519..a6e5c42 100644
--- a/src/SIPdump.c
+++ b/src/SIPdump.c
@@ -8,9 +8,10 @@
  * gcc -Wall SIPdump.c -o SIPdump -lpcap */

 #include "autoconfig.h"
+#include <stdio.h>
+
 #if HAVE_PCAP_H

-#include <stdio.h>
 #include <string.h>
 #include <stdlib.h>
 #include <unistd.h>
diff --git a/src/vncpcap2john.c b/src/vncpcap2john.c
index aca1f0b..333fc16 100644
--- a/src/vncpcap2john.c
+++ b/src/vncpcap2john.c
@@ -30,12 +30,13 @@
  */

 #include "autoconfig.h"
+#include <stdio.h>
+
 #if HAVE_NETINET_IF_ETHER_H && HAVE_PCAP_H

 #define _BSD_SOURCE
 #define _GNU_SOURCE
 #include <stdbool.h>
-#include <stdio.h>
 #include <stdlib.h>
 #include <string.h>
 #include <unistd.h>

magnumripper · 2014-05-03T08:57:43Z

Thanks, I'm not sure we should keep the printf() in the end. Do we actually get a SIPdump but it only prints "sorry"? I don't quite like that.

jfoug · 2014-05-03T12:02:05Z

The problem is, this is in the makefile for now. Having 40 targets done the way the fat makefile is done, will have to also be addressed. Several of them on not simply ln -s of john, but full builds. These 2 are a pair of them, that are fat, full exe files. For the time being, I needed something that would address this. The compile knows there will be no pcap lib, so nothing with pcap can be used. But without that, the entire exe file is moot.

Btw, I am getting horrible failures on cygwin with my last patch. I am going to make sure that the v1 (last patch I am calling v3) works. If that works, then likely it was some change between v1 and v3 (os.h, stripping down makefile, etc), that is the problem. A -test=0 runs fine until it hits dyna-70. That is the first format using SHA2 64 bit functions. All of a sudden, it is listed as using openssl code, the format fails, and a crash happens. If I build x86-any, then it crashes sooner (but in dyna). I need to make sure that patch-1 is working (I was pretty sure it was). Most of patch-3 was simply trying to start using the results from ./configure and not things like os.h, and also adding more headers, and more lib checks into configure. But I am 100% sure that I will have to get something changed.

magnumripper · 2014-05-03T12:36:14Z

Actually in this branch we could ditch all build targets already, and re-start from scratch. Just start with one "all" target (that is also default). If we try to fix the current targets, I think we'll solve problems that are only temporary anyway.

jfoug · 2014-05-03T13:21:25Z

I do not feel confident starting from scratch.

Right now, on my laptop, the v3 builds a garbage file. It cores all over the place. But that version on a 64 bit ubuntu VM (both at my office and at home), works fine. To make matters worse, the v3 works fine on my office cygwin install. I think it is #defines having gotten scrambled, OR how ossl is installed, or something. But this is the type of problem I am worried about. Where it 'works on my machine',, but then fails at other places. Those type issues are a nitemare to figure out. I think starting clean might make it worse (it might make it better, i do not know). I am still 'learning' autoconf. I only know a couple of baby steps.

I think next thing, is to try to add some --with-SSE2i type things (to control the (-64i vs -64 and sse2 vs sse2i). Once I figure out things like this, then I need to start learning variables, and changing lib path and allowing user to provide optional lib/header path, etc. But one thing at a time. I would like to get ALL of the libs that are there now, to use 'real' functions, instead of main() when using main(), it simply links a int main() {return 1;} type file with the lib. If a file is produced, it says the lib is there. That does work, at least the linker found the lib. But a better test is to have something like int main() { __gmpz_init; return 1; } That way, the linker will be forced to link against an actual function FROM the lib. If the lib does not provide that linkage, the build will fail, and configure script will mark that lib as not being found. Sometimes this is not suitable, if a lib may have different externals, depending upon what type OS built it, if static or dynamic, etc, etc. GMP would be a good example. I 'think' I have it done, but I am not 100% sure. GMP has a header that maps all the real functions, to the documented external things using macros. I think the one I have chosen (listed above), works, but there might be versions of GMP, where that is NOT the 'real' naming convention (since they use a #define to hide the 'common name'). The common name for that function is mpz_init But who is to say that version 4.1.3 does not use _gmpz_init, or that the static lib on 4.1.3 does that. I really do not know yet. Each of these, will have to be researched. One way to 'research' is to look at other more stable GNU packages, and dissect their configure.in files, looking for things like this.

Harder issues will be where it is not just a library, BUT also compiler command line switches. And where the command line switches vary. OMP is a prime example. But I am not sure that we need to do that. I think we 'might' be able to get by, without the command line switch, but I am not fully sure.

But for now, I need to research WHY my laptop is having problems, on the v3 build (but not the v1 autoconf code). And only for cygwin. grrr. I may not get to this for a couple days. I am moving large items today (have 3 strong young men to help). So I will NOT be playing with computer much today. Work, work, work.

---- magnum notifications@github.com wrote:

Actually in this branch we could ditch all build targets already, and re-start from scratch. Just start with one "all" target (that is also default). If we try to fix the current targets, I think we'll solve problems that are only temporary anyway.

Reply to this email directly or view it on GitHub:
#575 (comment)

magnumripper · 2014-05-03T14:46:12Z

Obviously you don't actually have to delete the legacy targets. Just create a new one that is NOT bound to any specific platform. It will not use any hard-coded stuff, just the autoconf input. Actually this should be a lot safer than first running autoconf and then getting hardcoded stuff (which might conflict) passed within the build target.

The problems are very likely some mismatch between SSE_PARA or the like.

jfoug · 2014-05-03T23:38:44Z

I have a 'start' on NSS. There are ways to do the pkg-cfg.. I do not know how to 'use' the information yet, but it is getting there:

This is configure.in:

check packages:

PKG_CHECK_MODULES([nss], [nss])
AM_CFLAGS = $(nss_CFLAGS)
LIBS += $(nss_LIBS)

Now, the AM_CFLAGS autoconf does not know about. I think that is automake. I have started down that path, but I do not have a step by step guide to idiots guide to automake like I found for autoconf.

When I ran autoconf, i see this:

checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for nss... yes
./configure: line 5582: nss_CFLAGS: command not found
./configure: line 5582: AM_CFLAGS: command not found
./configure: line 5583: nss_LIBS: command not found
./configure: line 5583: LIBS: command not found

So I know I am on to something. I just have to figure it out. It would be nice to do this for oSSL, and some others also, AS LONG AS pkg-config is standard enough. It might be that if we get down to where we find missing libs by themselves, we try pkg-config to see if the user put the crap in non standard locations.

Well, I am beat. Did 4 pickup loads, and 2 trailer loads of stuff today. I am beat.

---- magnum notifications@github.com wrote:

Obviously you don't actually have to delete the legacy targets. Just create a new one that is NOT bound to any specific platform. It will not use any hard-coded stuff, just the autoconf input. Actually this should be a lot safer than first running autoconf and then getting stuff passed within the build target.

The problems are very likely some mismatch between SSE_PARA or the like.

Reply to this email directly or view it on GitHub:
#575 (comment)

magnumripper · 2014-05-04T09:48:21Z

We also need something like "PROJ += file.c" (in some file or stage). In old Makefile we have PROJ, PROJ_PCAP, CUDA_OBJS and OCL_OBJS. For mozilla_fmt.c there are defines so we always have Mozilla in PROJ. But for CUDA et. al., we need something like

if (LIBCUDA)
    PROJ += CUDA_OBJS

This is crucial for not having separate make targets.

jfoug · 2014-05-04T13:48:58Z

Easy enough to do, using current Makefile standards we have. Configure would just be used to make sure the machine HAS cuda, and that the user did not disable cuda. Same goes for sse2/sse4 and sse2i

I did find this function for OMP. I just have to figure out how to make it work:

http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=blob_plain;f=m4/ax_openmp.m4

I may have that one working. Wow. Now that I see how to do new macros, and have started to learn some M4 coding (and how to quote, quote, quote), I may take a stab at some others things. Good stuff.

Good resource with lots of autoconf macros already done (includeing openmp and MPI)

http://www.gnu.org/software/autoconf-archive/

magnumripper · 2014-05-04T15:10:48Z

Here's one for OpenCL that takes care of that OSX oddity:
http://www.hardtailmaniac.nl/imagemagick/m4/ax_opencl.m4

Wow, M4 was some time ago. I administered SMTP servers using Sendmail back in the 90's.

jfoug · 2014-05-04T15:58:07Z

lib nss is now 100% controlled by autoconf. I need to add a --without-nss however, and figure out how to do that. For nss, this was is:

added to configure.in:
PKG_CHECK_MODULES([NSS], [nss], AC_SUBST(HAVE_NSS,[-DHAVE_NSS]) )

Added to Makefile.in replaced the 3 NSS setup flags with this:
NSS_CFLAGS = @NSS_CFLAGS@
HAVE_NSS = @HAVE_NSS@
NSS_LDFLAGS = @NSS_LIBS@

and the pkg-cfg stuff in Makeifle.in was removed. Works the same as before, does not use pkg_cfg inside the makefile. ./configure does all of that, setting the proper values, and then when it writes the makefile, it replaces the @Val@ with what was computed.

magnumripper · 2014-05-04T19:28:37Z

So IMHO drop the intermediate variables - instead of:

NSS_CFLAGS = @NSS_CFLAGS@
HAVE_NSS = @HAVE_NSS@
NSS_LDFLAGS = @NSS_LIBS@
CFLAGS = -O2 blabla $(HAVE_NSS) $(NSS_CFLAGS)
LDFLAGS = -g -L/usr/local/lib blabla $(NSS_LDFLAGS)

...make it just:

CFLAGS = -O2 blabla @HAVE_NSS@ @NSS_CFLAGS@
LDFLAGS = -g -L/usr/local/lib blabla @NSS_LDFLAGS@

magnumripper · 2014-05-16T18:43:28Z

Magnum, did you add code specific to testing for GNU compliant malloc and realloc?

I can't recall having changed anything lately that should have such side effects but sometimes you just change the position of a variable definition and autoconf avalanches and reorders stuff :)

I take it all is good now after 14ec2d8. Did that little thing have such bad side effects?!

jfoug · 2014-05-16T18:59:47Z

Yes, all is well after that.
The side effects were that ALL c compiling within the configure script from that point on failed, due to gcc complaining that it could not find libregex.so, even though no functions were being used from within that library. gcc had no way of knowing it was 'safe' to not exist.

So configure started thinking all sorts of things were wrong, not installed, or non-compliant.

NOTE, we need to look at how to work around that non-compliant malloc and realloc. If we hit a system that triggers that situation. I think we need to have some functions ready to go (rpl_malloc and rpl_realloc)

claudioandre-br · 2014-05-17T01:09:29Z

Do you now get OpenCL?

No, but I can say what is failing inside configure (I analysed and hand edited Makefile). To offer a patch I have to understand where OpenCL stuff is.

Anyone online to help me finding it?

claudioandre-br · 2014-05-17T01:28:50Z

The patch below fix the problem. I tried to check how bull behaves, but it is failing at git clone. Anyway, it is mandatory here (notice, for a 32 bits system, it is not correct).

diff --git a/src/configure b/src/configure
index 29ca672..c8e8b36 100755
--- a/src/configure
+++ b/src/configure
@@ -3415,7 +3415,7 @@ if test -n "$AMDAPPSDKROOT"; then
       CFLAGS+=" -I$AMDAPPSDKROOT/include"
    fi
    if test -d "$AMDAPPSDKROOT/lib"; then
-      LDFLAGS+=" -L$AMDAPPSDKROOT/lib"
+      LDFLAGS+=" -L$AMDAPPSDKROOT/lib  -L$AMDAPPSDKROOT/lib/x86_64"
    fi
 fi
 if test -n "$ATISTREAMSDKROOT"; then
diff --git a/src/configure.ac b/src/configure.ac
index 56745c0..cd1b3e6 100644
--- a/src/configure.ac
+++ b/src/configure.ac
@@ -98,7 +98,7 @@ if test -n "$AMDAPPSDKROOT"; then
       CFLAGS+=" -I$AMDAPPSDKROOT/include"
    fi
    if test -d "$AMDAPPSDKROOT/lib"; then
-      LDFLAGS+=" -L$AMDAPPSDKROOT/lib"
+      LDFLAGS+=" -L$AMDAPPSDKROOT/lib -L$AMDAPPSDKROOT/lib/x86_64"
    fi
 fi
 if test -n "$ATISTREAMSDKROOT"; then

claudioandre-br · 2014-05-17T01:36:22Z

Why GMP support (below) has no (blank) information?

Configured for building John the Ripper Jumbo:

Target CPU .................................. x86_64 SSE2, 64-bit
Target OS ................................... linux-gnu
Legacy arch header .......................... x86-64.h
OpenMP support .............................. yes
OpenMPI support ............................. no
OpenCL support .............................. yes
CUDA support ................................ no
Rexgen support .............................. no
GMP support (performance).................... 
NSS support (Mozilla format)................. no
AES-NI support .............................. depends on OpenSSL

magnumripper · 2014-05-17T15:00:56Z

The blank GMP is a bug in configure.ac. Not sure when it happens, I'm pretty sure I have seen both yes and no emitted too (yet I too have seen it blank on some host)

magnumripper · 2014-05-17T15:13:55Z

The patch below fix the problem. I tried to check how bull behaves, but it is failing at git clone. Anyway, it is mandatory here (notice, for a 32 bits system, it is not correct).

Thanks, knowing this I'll be able to fix configure.ac (tomorrow). I'll add some logic for 32/64 bit and then run-time checks so we don't add directories that does not exist.

Hmm bull fails at clone? This works for me (read only, I never push from bull):

$ git clone http://github.com/magnumripper/JohnTheRipper -b autoconf testclone

jfoug · 2014-05-17T15:50:42Z

I have this and many other things fixed. When I get tem checked in, I will list.

claudioandre-br · 2014-05-17T16:01:47Z

Hmm bull fails at clone?

Something related to "refused by host" (I mean, seems to be a intermittent error).

jfoug · 2014-05-17T17:30:43Z

These items have been 'fixed' and or changed.

Added a new 'utility' macros file to m4. It contains a macro for testing gcc command line switches (and some other macros). This may end up being the kitchen sink for macros, to keep configure.ac thinner and smoother.

The get cc argument works, but the only problem with it, is it depends upon -Werror being valid (which causes a warning to be treated as an error). We likely need to come up with tests for -Werror not being present, and what other switches to try, or find a way to detect the PROPER switch to do this. Now, testing for these have been moved into using this code: -O2 (we should test -O4, -O3, -O2, -O1, -O until one of them works, and then go with that one), -Wall, -funroll-loops, -finline-functions, -Os, -Wdeclaration-after-statement, and -fomit-frame-pointer. Now CFLAGS, OPT_NORMAL and OPT_INLINE all get set from these tests

Fixed GMP being blank

Fixed --disable-openmp still showing Yes on the status

Moved the include and lib path search code into the 'Generic' macros file.

Added OpenCL lib test for $AMD/lib/x86_64 or $AMD/lib/x86 to happen after we determine 32 or 64 bit (NOTE, I now get OpenCL in cygwin also!!). I think this is usually where the Win32 installs of AMD libs put the libs.

This patch 11f0390 contains all of these changes.

jfoug · 2014-05-17T17:35:43Z

@claudioandre Please try now, and see if a 'raw' configure, with no fixups works properly for you. It should have the -O2 and find openCL properly (I hope).

magnumripper · 2014-05-17T18:12:53Z

Now, testing for these have been moved into using this code: -O2 (we should test -O4, -O3, -O2, -O1, -O until one of them works, and then go with that one)

If you mean we build all of john with the highest -O that works I think that might be inappropriate. Even -O3 seems to do more bad than good (at least last time I tested). I assume we get regressions from code no longer fitting in caches.

jfoug · 2014-05-17T18:22:29Z

I have made no change other than to look for O2 if it works. The comment was just talking out loud

claudioandre-br · 2014-05-17T19:22:27Z

Please try now, and see if a 'raw' configure, with no fixups works properly for you

It is working fine, but I noticed a few glitches:

erros on configure
openMP = no (but it was detected and build properly)

Thanks.

config.status: linking x86-64.h to arch.h
config.status: executing default commands
./configure: line 13363: test: argument expected
./configure: line 13364: x: command not found
./configure: line 13365: x-fopenmp: command not found

Configured for building John the Ripper Jumbo:

Target CPU .................................. x86_64 SSE2, 64-bit
Target OS ................................... linux-gnu
Legacy arch header .......................... x86-64.h
OpenMP support .............................. no
OpenMPI support ............................. no
OpenCL support .............................. yes
CUDA support ................................ no
Rexgen support .............................. no
GMP support (performance).................... no
NSS support (Mozilla format)................. no
AES-NI support .............................. depends on OpenSSL

jfoug · 2014-05-18T03:25:27Z

openmp will likely need work. I added code, so that when you do a --disable-openmp, that it does not show Yes. But when I ran it, without the --disable, it DID show yes. I am sure there is something still not right. Magnum had to add some 'special' code at the bottom of config.ac to figure out when OMP was set, I changed that to try to detect when it is forced off. Likely I am a little aggressive, and need to change it slightly.

I will look at other warnings when I feel up to it. Was moving today, so am very exhausted right now. I think the next time I move, it will be where I have 2 EMT's moving me, and there is a sheet over my head. This really sux.

magnumripper · 2014-05-18T10:16:05Z

The OpenMP output was working for me, with and without --disable on Sparc, Linux and OSX. But I did recognize it as not quite foolproof. Maybe we should be slightly less reluctant to change the imported macro files. We should be reluctant, but sometimes it's better to change it than not to.

jfoug · 2014-05-18T11:38:16Z

These warnings have been fixed. It was bash test logic that was working fine on cygwin, but failed on linux (LOLOLOLOL :) Well, it is fixed, and working fine now. The warnings were all from the if statement computing whether to show 'yes' or 'no' for openmp. But again, we need to test. I used the -a 'and' in the test statement instead of multiple test statements strung together with && Possibly the -a is not as compatible, and I will need to revert. But the important part now, is that the omp logic is working pretty solidly in being set, and this was just a visual probblem within the summary. HOWEVER, if the -a of test is something that should not be used, then I will need to make changes to the LOGIC of the x86_64 vs x86 lib addition logic for OpenCL detection. If those libs are not added, then my cygwin fails to find OpenCL, as @claudioandre also found out.

magnumripper · 2014-05-18T17:23:26Z

I'm pretty sure -a is portable. But last time I tried, I failed to find what syntax to use (for the whole line) - nothing seemed to work so I reverted to test this && test that.

Just now I tried it again and there seems to be no problems at command line:

$ if test 1 -eq $((2/2)) -a string = string ; then echo "yep"; fi
yep

I did not try this in configure.ac this time though (I think I tried that syntax before and it failed?)

magnumripper · 2014-05-18T17:28:59Z

Latest commit (445ad39) works fine on OSX. However, I see you use "==" with 'test'. While it seems to work it's not mentioned in my man page. I presume it's safer to use a single = for string comparisons and -eq for numeric ones.

magnumripper · 2014-05-18T17:53:04Z

af08a8e changes all '==' to '=' and replaces 'test this && test that' with 'test this -a that'. Works fine on OSX and should be more portable.

jfoug · 2014-05-18T18:22:21Z

I have changes also, but not committed. The == to = was one of them. I'm at my daughters graduation today, so my time is not really avail. But I will look also. We are getting very close. If we get a few more alpha testers, we might be able to call it done enough for the masses

magnumripper · 2014-05-18T18:39:09Z

Found a case where a multi-word $CL_LIBS lead to errors because it was not protected with quotes, fixed in c449787. So I ended up unifying the syntax so we use "x$variable" in most places, as opposed to x"$variable" or x${variable}, unprotected.
Also, ax_jtr_utility macros.m4 had DOS linefeeds and lots of bogus whitespace. All fixed in 1759998.

I'll merge this branch to bleeding-jumbo in about 22h from now, after Hash Runner ends (I'll merge contest patches too at the same time).

claudioandre-br · 2014-05-18T23:44:37Z

Everything seems to be ok here.

magnumripper · 2014-05-19T00:17:40Z

I get these ugly warnings. In the end all is right but I wonder why I see those warnings.

checking CL/cl.h usability... yes
checking CL/cl.h presence... no
configure: WARNING: CL/cl.h: accepted by the compiler, rejected by the preprocessor!
configure: WARNING: CL/cl.h: proceeding with the compiler's result
checking for CL/cl.h... yes
checking OpenCL/cl.h usability... no
checking OpenCL/cl.h presence... no
checking for OpenCL/cl.h... no
checking windows.h usability... no
checking windows.h presence... no
checking for windows.h... no
checking for OpenCL library... -lOpenCL
checking cuda.h usability... yes
checking cuda.h presence... no
configure: WARNING: cuda.h: accepted by the compiler, rejected by the preprocessor!
configure: WARNING: cuda.h: proceeding with the compiler's result
checking for cuda.h... yes
checking for cudaGetDeviceCount in -lcudart... yes

Could it be that CPPFLAGS should be filled with the -I/path/oclincludes -I/path/cudaincludes too?

claudioandre-br · 2014-05-19T00:23:30Z

Me too (BTW: it is not new, I'm seeing this for a while).

Since things works, never bother. Anyway, if you want to try this, I can test it for you!

magnumripper · 2014-05-19T00:40:03Z

It was CPPFLAGS. How odd is that, I thought it would be using CFLAGS' -I. Fixed in e3c7c87

magnumripper · 2014-05-19T01:05:38Z

As of 539cb8c bull, well and super configures & builds correctly just from ./configure && make. As does my MBPR.

claudioandre-br · 2014-05-19T01:09:01Z

Everything is Ok here too.

magnumripper · 2014-05-19T02:00:01Z

Let's stop this thread right here. Look at #580 instead, it's auto-updated (and comments can still be added).

magnumripper added this to the 1.8.0-jumbo1 milestone May 2, 2014

magnumripper assigned jfoug May 2, 2014

magnumripper added enhancement labels May 2, 2014

magnumripper closed this as completed May 19, 2014

Autoconf #575

Autoconf #575

Comments

magnumripper commented May 2, 2014

magnumripper commented May 2, 2014

magnumripper commented May 2, 2014

magnumripper commented May 2, 2014

magnumripper commented May 2, 2014

jfoug commented May 2, 2014

magnumripper commented May 2, 2014

jfoug commented May 2, 2014

magnumripper commented May 2, 2014

jfoug commented May 2, 2014

jfoug commented May 2, 2014

jfoug commented May 2, 2014

magnumripper commented May 2, 2014

jfoug commented May 2, 2014

magnumripper commented May 2, 2014

claudioandre-br commented May 3, 2014

magnumripper commented May 3, 2014

jfoug commented May 3, 2014

magnumripper commented May 3, 2014

jfoug commented May 3, 2014

magnumripper commented May 3, 2014

jfoug commented May 3, 2014

check packages:

magnumripper commented May 4, 2014

jfoug commented May 4, 2014

magnumripper commented May 4, 2014

jfoug commented May 4, 2014

magnumripper commented May 4, 2014

magnumripper commented May 16, 2014

jfoug commented May 16, 2014

claudioandre-br commented May 17, 2014

claudioandre-br commented May 17, 2014

claudioandre-br commented May 17, 2014

magnumripper commented May 17, 2014

magnumripper commented May 17, 2014

jfoug commented May 17, 2014

claudioandre-br commented May 17, 2014

jfoug commented May 17, 2014

jfoug commented May 17, 2014

magnumripper commented May 17, 2014

jfoug commented May 17, 2014

claudioandre-br commented May 17, 2014

jfoug commented May 18, 2014

magnumripper commented May 18, 2014

jfoug commented May 18, 2014

magnumripper commented May 18, 2014

magnumripper commented May 18, 2014

magnumripper commented May 18, 2014

jfoug commented May 18, 2014

magnumripper commented May 18, 2014

claudioandre-br commented May 18, 2014

magnumripper commented May 19, 2014

claudioandre-br commented May 19, 2014

magnumripper commented May 19, 2014

magnumripper commented May 19, 2014

claudioandre-br commented May 19, 2014

magnumripper commented May 19, 2014