[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140520090246.BEWK5.248545.imail@fed1rmwml301>
Date: Tue, 20 May 2014 9:02:46 -0400
From: <jfoug@....net>
To: john-users@...ts.openwall.com
Cc: magnum <john.magnum@...hmail.com>
Subject: Re: Jumbo just got autoconf
---- magnum <john.magnum@...hmail.com> wrote:
> For those of you not subscribed to john-dev:
>
> Jim and I have worked with 'autoconf' the last few weeks and now it's
> committed to the bleeding-jumbo branch of GitHub. It seems to be solid
> enough now but there will be need for various little tweaks for sure, at
> least for exotic targets. On the other hand there's likely a lot better
> chance exotic targets build at all.
There will likely be a few growing pains, getting some peoples systems up and running, but actually, it may be less error prone that I am expecting. The probing we do within the configure script is pretty thorough, and finds a LOT of things that simply were NOT being found before.
Take for instance my cygwin builds. I now get numerous formats which were not being used, due to libraries (things like mozilla, crypt(3), skey, etc, opencl, openmp, etc, etc). Yes, I could have continually fuxored with the makefile to try to do this, but then I have a modified makefile, which gets lost every time I pull source. Other benifit I get are now I get XOP on my 'slow' laptop, and this is giving this laptop about 40-80% improvement in speed on many formats. I did not even have any idea this lappy was capable, but with the CPU probing written into configure, it detects it sets the makefile up to build that way, and builds it. All is 'really' good.
I think some of the biggest hurdles we will have, is to get some of the cross compiling done rock solid. It may be that most of that simply is getting some 'how to' examples done and documented. For most 'users' this is a non, issue. They will simply git the code, and do a ./configure && make clean && make and have an optimal jtr. But for repackagers, this may take a little time to get done in a really solid manner.
However, magnum and I both believe this is a huge improvement in the environment of bleeding. It has been a pretty big learning experience for both of us also, since neither of us had any experience in the autoconf environment (magnum had some M4 experience from ages ago). It was also interesting at times where 2 of us were working over the same area of the project. several times we stepped on each others code (and other things), but I think with 2 people researching methods of getting it done, that we ended up with a much more robust end result. There is still work to be done, but so much HAS already been done, that it was time to allow all of the good of this build environment to be used by everyone else.
NOW, if you do have serious issues with the ./configure build, you CAN revert back to the original makefile (the fat makefile), choosing the target that you have always used (from bleeding). This process is:
make -f Makefile.orig whatever-target-you-want
This should still be fully functional. The Makefile.orig should be viewed as being depricated, BUT it is still there, as a fallback for now. There may be some systems which we do not have all of the obsure compiler switches done properly. The testing we have done, was mostly for cygwin (32 and 64), and linux (32/64). We have also build on sparc (32/64 with gcc and with sun studio cc).
For the sparc, things are not 100% perfect, there was still some hand editing of Makefile, and some of those changes have not been put into configure yet, but with some of the changes we have done in the last couple of days, I think we have infrastructure to easily do this now. But in the same line of thought, we have many 'targets' which have unique compiler args which may not be there now. We will work through these with time. But for 99% of folks, the machines they run on will simple 'work' (and work WELL) with just the plain configure command
Jim.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
