(__)
       ('')
        \/                

How to compile CVS versions of GnuPG

(with and without TIGER192)

by Mica Mijatovic

 

This is the set of instructions on how to compile GnuPG (Gnu Privacy Guard) in various environments and ways, based on my personal experience and work. This work of mine is, again, based entirely and exclusively on instructions given by Tom Pegios and on his own scripts. If some of these scripts are modified a bit here and there, these modifications are entirely insignificant, changing nothing in their original functionality, and consisting actually of just commented lines I have added myself to recall what I actually am doing, what a file/script serves for and similar, and such lines begin with a "# <>o<>".

This documentation is created for two main reasons. One is my gratitude for the all Tom's time dedicated to build the very software in the way I needed it, and for after that even the knowledge he was very generously willing to share with me, making me thus able to build myself this very software and being thus independent of the time and presence of others, and the other one is Tom's wish and a request he made of me (and of others taught, at the time, by him how to compile GnuPG this way) to pass on the knowledge and to help anybody asking me how to compile the source code, with or without TIGER192, a wish and attitude I entirely feel as my own.

Besides, there are two "sub-reasons" too. I anyway found that I would have to make such a documentation, for myself, if I ever forget a part or two of the procedures, so I would have to remind myself alone, and the other one is that the knowledge given in such a form will be always present and at disposal, regardless whether I am present and/or my time permits me to be involved `directly'.

 

 

Content:

1. Compiling in MSYS/MinGW32

1.1. Installation of the needed files, programs and environment (The Foreplay)
   1.1.1. MinGW32
      1.1.1.1. MinGW32: The files we need
      1.1.1.2. MinGW32: Installation
   1.1.2. MSYS
      1.1.2.1. MSYS: The files we need
      1.1.2.2. MSYS: Installation
1.2. Compiling ................................................................................... (The Action)
   1.2.1. Compiling a release version of GnuPG
   1.2.2. Compiling a CVS version of GnuPG
      1.2.2.1. The software we need
      1.2.2.2. Compiling
   1.2.3. Compiling a CVS version of GnuPG with added TIGER192 algorithm
      1.2.3.1. The software we need and the files
      1.2.3.2. Compiling

2. Compiling in Cygwin/MinGW32

2.1. Installation of the needed files, programs and environment (The Foreplay)
   2.1.1. Cygwin
      2.1.1.1. Cygwin: The files we need
      2.1.1.2. Cygwin: Installation
2.2. Compiling ................................................................................... (The Action)
   2.2.1. Compiling a release version of GnuPG
   2.2.2. Compiling a CVS version of GnuPG
      2.2.2.1. The software we need
      2.2.2.2. Compiling
   2.2.3. Compiling a CVS version of GnuPG with added TIGER192 algorithm
      2.2.3.1. The software we need and the files
      2.2.3.2. Compiling

3. Compiling in Linux

 

 

 

 

 

<>o<>
 

1. Compiling in MSYS/MinGW32

 

1.1. Installation of the needed files, programs and environment (The Foreplay)

Firstly, we have to prepare the environment we shall work in on making GnuPG.

For this, we need these main ingredients:

  • one piece of a standard Windows;
  • MinGW32;
  • MSYS.
    The "standard" Windows means here a Windows "out of box", or a "full installation", that is not modified in any (or not in any significant) way. I will explain this. I usually work in Windows XP Micro Lite Professional system, modified by Micro Lite technology, which means that some OS components are removed, some replaced, some modified or re-installed in a different way etc.

    It is good for my usual way I use Windows but is not necessarily good for the compiling, the thing I had discovered quite quickly at the very beginning of compiling the CVS builds of GnuPG, since some components, for some reasons, couldn't be found from MSYS environment then.

    Since I had no time to closely investigate what exactly was the cause of the errors reported, and thus possibly re-configure "on the fly" the OS, I simply did a fresh "standard", or "full" installation of XP Professional, and this and such is the OS environment I worked in then on.

    This information should serve as a warning to others who are possibly using a modified Windows, and to save their time and wondering "what happens" "in the case of coyote/error[s]".

    -

    The other two ingredients will be explained now...

     

    1.1.1. MinGW32

    What is it...

    MinGW is a collection of programs, various libraries, support files and helper applications we need to do the compiling and to generate a given program, in this case GnuPG. More about it can be found here <http://www.mingw.org/mingwfaq.shtml>.  

     

    1.1.1.1. MinGW32: The files we need

    The files we need to install MinGW32 are these...

    a) binutils-2.16.91-20060119-1.tar.gz
    b) mingw-runtime-3.9.tar.gz
    c) w32api-3.6.tar.gz
    d) mingw-utils-0.3.tar.gz
    e) bzip2-1.0.3-1-bin.zip
    f) bzip2-1.0.3-1-lib.zip
    g) gettext-0.14.4-bin.zip
    h) gettext-0.14.4-dep.zip
    i) gettext-0.14.4-lib.zip
    j) libiconv-1.9.2-1-bin.zip
    k) libiconv-1.9.2-1-lib.zip
    l) readline-5.0-bin.zip *)
    m) readline-5.0-lib.zip *)
    ...and these...
    n) coreutils-5.2.1.bin.zip **)
    o) CURL_EXTERNAL-MINGW.zip *)
    p) GCC-3.4.6_FINAL_V3_COMPILER-1.zip
    q) msgmerge_files_install_last_overwrite_existing.zip
    r) GCC-3.4.6_FINAL_V3_COMPILER-2.zip (this is documentation only and is not needed for compiling GnuPG)
    The first group of files, from a) to m), we download from here...

    <http://sourceforge.net/project/showfiles.php?group_id=2435>

    ...or from here...

    <http://gnuwin32.sourceforge.net/>

    ...and the second group of files, from n) to r), we download from here.

    (This second group of files is prepared/modified by Tom Pegios. Do not take anything else, since other files I am not familiar with and cannot guarantee then successfulness of the instructions given here!)
    _______________________

    *) These files are required for dynamic build only and not for the official static build.
    **) These files are also available from: <http://sourceforge.net/project/showfiles.php?group_id=2435>. Do not choose coreutils-5.3.0.bin.zip because the checks/tests could fail. Use version coreutils-5.2.1-1-bin.zip, extract only \bin\dd.exe and place it in your \mingw\bin\ folder.  

     

    1.1.1.2. MinGW32: Installation

    Now, on the partition the OS you work with now is installed (we shall assume now on it is the drive C:\), make a folder \mingw.

    Unpack all the listed files into this folder, leaving the q) to be unzipped last.

    If some files already exist in \mingw folder, then overwrite them only if they are older. The only exception are files from q) package and they must overwrite all other ones.

    Now we go to install MSYS...

     

    1.1.2. MSYS

    What is it...

    MSYS is the working environment that supports BASH and POSIX commands, we need here. More about it can be found here <http://www.mingw.org/mingwfaq.shtml>.  

     

    1.1.2.1. MSYS: The files we need

    The files we need to install MSYS and work with it are these...

    s) MSYS-1.0.10.exe (or MSYS-1.0.11.exe)
    t) msysDTK-1.0.1.exe
    ...and these...

    u) MSYS_Autoconf-2.59.zip
    v) MSYS-AutoMake-1.9.6.zip
    w) notepad2.zip (It is a Win32 editor that works with Unix files, and is free.)
    The first group of files, from s) to t), we download from here...

    <http://sourceforge.net/project/showfiles.php?group_id=2435>

    ...or from here...

    <http://www.mingw.org/>

    ...and the second group of files, from u) to w), we download from here and here.

     

    1.1.2.2. MSYS: Installation

    Run the file MSYS-1.0.10.exe and install MSYS on the same partition you have installed MinGW32.

    (When you are asked for the location of your \mingw folder, enter the info in a Unix format, that is a "c:/mingw" and not a "c:\mingw"!)

    Now, after we have the installation finished, we run MSYS (Start | Programs | MinGW32 | MSYS | msys) and MINGW32 console will appear. We then type in this...

    gcc -v
    
    ...and hit the [enter] button. Something like this should appear...

    14:14:11 user-name@computer-name ~
    $ gcc -v
    Reading specs from c:/mingw/bin/../lib/gcc/mingw32/3.4.6/specs
    Configured with: ../gcc-3.4.6/configure --with-gcc --with-gnu-ld --with-gnu-as --prefix=/mingw --enable-threads --disable-nls --enable-languages=c --disable-win32-registry --disable-shared --enable-sjlj-exceptions --disable-libgcj --disable-java-awt --without-x --enable-hash-synchronization --with-arch=i386 --with-tune=i386 --host=mingw32 --target=mingw32
    Thread model: win32
    gcc version 3.4.6
    14:14:11 user-name@computer-name ~
    $  

     

     

    ...and then it means that our installation was successful.

    Now run the command...

    cp /mingw/bin/libiconv2.dll /mingw/bin/iconv.dll
    

    ...then install t) msysDTK-1.0.1.exe...

    ...delete these files...

    c:\MSYS\1.0\bin\autoopts-config
    c:\MSYS\1.0\share\aclocal\autoopts.m4.
    
    ...unzip u) and v) into the MSYS\1.0 folder - and we go now to compile the Thing!

     

    1.2. Compiling (The Action)

    There are two build/compiling methods: static and dynamic.

    "Static" means that all libraries (except iconv.dll) are included in the *.exe files, and such is for instance the GnuPG for Win32 we get from GnuPG.org.

    "Dynamic" means that GnuPG for Unix, for instance, uses external files rather (they are equivalent to the libraries in Win32) which are stored in various system folders (for instance the file readline, gettext and many other dynamic files). Such programs are a bit (or a bit more) smaller, but they are dependent on those external files and cannot work without them (if by a chance, for instance, the operative system has not these files installed).

    Besides, both these static and dynamic builds might be full and minimal, and being that the official build from GnuPG is a blend between minimal and full one, and is static, this will be the way of compiling we shall cover here, making it just like the `official build', except that we'll add after that the TIGER192 and some other confectioneries.

    Now we go to make it...

     

    1.2.1. Compiling a release version of GnuPG

    Firstly, we shall explain meanings of two terms, `home' and `$home'. The `home' is the name of the folder (or of the directory, as it is named in DOS and some other environments) in our \MSYS path.

    In this `home' folder, there is a folder created the first time we have started MSYS and is named after our Windows login (or user) name. This login-name folder we shell refer to as the `$home folder'. We can always change to this folder from anywhere by typing this...

    cd $home
    
    ...or this...
    cd ~
    

    --

    We shall start now by compiling an `official release' of GnuPG, and we'll take the actual version 1.4.3 to start with.

    For this we have to download the source code for GnuPG v1.4.3 from: <http://www.gnupg.org/(en)/download/mirrors.html>.

    In Windows, create a folder in the $home directory, name it `143' and place the source files there, so it looks like this...

    c:\msys\1.0\msys\home\login-name\143\
    

    ...and this \143 folder we shall call now on `build folder'.

    Since we shall make a Win32 version of GnuPG which will create data files (ASCII-Armor Signature) with a DOS End Of Line (EOL) sequence (ASCII 13 / ASCII 10), we must modify one file or the tests will fail.

    The file we have to modify is \143\checks\seat.test...

    The original seat.test file

    #!/bin/sh
    # <>o<> Original \checks\seat.test file
    # <>o<> from the release source of GnuPG. Use any editor.
    
    . $srcdir/defs.inc || exit 3
    
    for i in $plain_files ; do
        echo "$usrpass1" | $GPG --passphrase-fd 0 --always-trust -seat \
                            -r two -o x --yes $i
        $GPG -o y --yes x
        cmp $i y || error "$i: mismatch"
    done
    

    ...and we do that this way (using any editor): the part...

        $GPG -o y --yes x
        cmp $i y || error "$i: mismatch"
    done
    
    ...we change to be...

        $GPG -o y --yes x
        unix2dos -c 7bit $i
        cmp $i y || error "$i: mismatch"
        dos2unix -c 7bit $i
    done
    
    ...so the modified file looks like this...

    The modified seat.test file

    #!/bin/sh
    # <>o<> Modified \checks\seat.test file
    # <>o<> for the work in MSYS/MinGW32 environment.
    
    . $srcdir/defs.inc || exit 3
    
    for i in $plain_files ; do
        echo "$usrpass1" | $GPG --passphrase-fd 0 --always-trust -seat \
                            -r two -o x --yes $i
        $GPG -o y --yes x
        unix2dos -c 7bit $i
        cmp $i y || error "$i: mismatch"
        dos2unix -c 7bit $i
    done
    

    ...and then we save it happily and go further.

    Now we have to create a file `build_gpg.sh', in order to compile GnuPG as close as possible to the official release.

    Copy and paste the script given below, and save it in the folder \143.

    The script file `build_gpg.sh'

    #!/bin/sh
    # <>o<> The script file `build_gpg.sh'. It builds the Thing. Just
    # <>o<> to remind myself if I make a mess with the file names.
    # <>o<> The script for the work in MSYS/MinGW32 environment.

    make distclean

    ./configure CFLAGS='-g -O2 -march=i386 -mfpmath=387' LDFLAGS='-s -static' --prefix=/home/gpg-static-143

    make

    make install

    make check

    Then start MSYS and type...

    cd 143
    
    ...push the [enter] button, then type...
    ./build_gpg.sh
    
    ...push the [enter] again and that's it. The compiling process will start, and, if we have done everything well, will finish happily with all GnuPG executables dwelling in the folders...
    c:\msys\1.0\home\gpg-static-143\bin\
    
    ...and...
    c:\msys\1.0\home\gpg-static-143\libexec\
    
    We may now copy them into the folder we have installed our GnuPG in, and use them as we usually do.

    --

    Now, if we need this, we can add even IDEA to this build, so that the idea.dll is not needed to be used anymore.

    In this case, we download `idea.c.gz' file from here...

    <ftp://ftp.gnupg.dk/pub/contrib-dk/idea.c.gz>

    ...unzip `idea.c' and place it in the \143\cipher folder.

    Then we run the `build_gpg.sh' script again, and that's it.

    Since IDEA will now be built-in into the EXE files, they will be a bit bigger but not much.

    ____________
    Optionally, before we run again the `build_gpg.sh' script, we can modify it a bit, if we want to keep our previous v1.4.3 build (the one without IDEA built in) too. In this case the part...
     --prefix=/home/gpg-static-143
    
    ...we change to be as something like this...
     --prefix=/home/gpg-static-143-idea
    
    ...so the new build with IDEA will be placed in this new folder, after the compiling process is over, and the content of our existing folder \gpg-static-143 will not be overwritten.
    With this, we have compiling of a release version of GnuPG finished, and now we go to do something a bit more complex and nicer...  

     

    1.2.2. Compiling a CVS version of GnuPG

    Well, just to appease some elementary curiosity, we shall say that the "CVS" stands for "Concurrent Version System", and "SVN" for "SubVersion", for those are pretty complex and ample systems we absolutely have no any practical need to get here and now much into, except perhaps just to say that these systems make possible to us to get newest source files created in the time between two release versions (in the course of the work of all the programmers involved) of a given program, in this case of GnuPG. For those needing more informations good place for start is here: <http://www.cs.utah.edu/dept/old/texinfo/cvs/cvs_toc.html>.  

     

    1.2.2.1. The software we need

    Download TortoiseSVN from <http://tortoisesvn.tigris.org/>.

    Install it and reboot computer.

    Create a folder where you will receive the SVN files. Here we'll name this folder "svn", and will assume it is on C partition, that is a "C:\svn".

    Then, right click on the \svn folder, select TortoiseSVN -> Settings, and in the General section check the `Set filedates to the "last commit time"'. Click [OK].

    Right click again on the \svn folder, and select "SVN Checkout". For "URL of repository" type in "svn://cvs.gnupg.org/gnupg/trunk" (at the beginning of August 2006 this address changed to "svn://cvs.gnupg.org/gnupg/branches/STABLE-BRANCH-1-4"!), and for the "Checkout directory" should already stay there a "C:\SVN". The Revision should be set to "HEAD Revision". When you click the [OK], the files will start to download.

    It will take longer only the first time, for from now on you will not do the "SVN Checkout" but a "SVN Update" instead, downloading, now and then, just updated source files.

    Now, and this is important, we'll not use the files from this \svn folder, but will create instead an other folder for this. Here, we'll name this folder "gpg_source".

    Then, right click on the \svn folder, select TortoiseSVN -> Export, then browse to the \gpg_source folder, and select it. Check both the "Export universioned files too" and the "Omit externals" boxes.

    Now we have in the \gpg_source folder just the SVN source files without all the extra files created by TortoiseSVN for the purpose of administration of all the changes.

    If we wish/need this, we can also add idea.c in the cipher folder, that is in the \gpg_source\svn\cipher.

    Now we go to build the Thing...  

     

    1.2.2.2. Compiling

    Firstly, we shall make a `build folder' for our CVS build. Since the current SVN sequence number in the time of writing this documentation is/was 4136, we'll name this folder "4136". We create it in our $HOME folder in MSYS, that is...

    c:\msys\1.0\home\user-name\4136\
    
    ...and we place our CVS files (from \gpg_source\svn\, not from \gpg_source\, thus excluding the \svn folder) in it.

    Now, we have to create two more scripts, prep.sh and reset.sh.

    The prep.sh should look like this...

    The prep.sh script

    #!/bin/sh
    # <>o<> The `prep.sh' script, dwelling in the `build folder',
    # <>o<> for instance \msys\1.0\home\user-name\4136\prep.sh
    # <>o<> The script for the work in MSYS/MinGW32 environment.
    
    # reset.sh brings everything back to CVS state ( bare bones )
    ./reset.sh
    
    ./scripts/autogen.sh
    
    ./configure LDFLAGS='-s' --enable-maintainer-mode
    

    ...and you may simply copy and paste the content above and save it in your \4136 folder.  

     

    The other file, reset.sh, should look like this...

    The reset.sh script

    #!/bin/sh
    # reset.sh rev 1.1
    # added rm -f ./mpi/*.S
    # <>o<> The `reset.sh' script, dwelling in the `build folder',
    # <>o<> for instance \msys\1.0\home\user-name\4136\reset.sh
    
    make distclean
    rm -f ./configure
    rm -f ./makefile
    rm -f ./makefile.in
    rm -f ./config.log
    rm -f ./config.h.in
    rm -f ./aclocal.m4
    rm -f ./config.log
    rm -f ./g10defs.h
    rm -f ./stamp-h1
    rm -f ./config.h
    rm -f ./config.status
    rm -f ./confdefs.h
    rm -f ./*.bak
    rm -f ./autom4te.cache/*
    rmdir ./autom4te.cache
    rm -f ./checks/*.bak
    rm -f ./checks/makefile
    rm -f ./checks/makefile.in
    rm -f ./checks/*.log
    rm -f ./checks/x
    rm -f ./checks/y
    rm -f ./checks/z
    rm -f ./checks/random_seed
    rm -f ./checks/*.gpg
    rm -f ./checks/*.?kr
    rm -f ./checks/plain-1
    rm -f ./checks/plain-2
    rm -f ./checks/plain-3
    rm -f ./checks/plain-large
    rm -f ./checks/prepared.stamp
    rm -f ./checks/data*
    rm -f ./checks/gpg_dearmor
    rm -f ./cipher/.deps/*
    rmdir ./cipher/.deps
    rm -f ./cipher/makefile
    rm -f ./cipher/makefile.in
    rm -f ./cipher/libcipher.a
    rm -f ./cipher/*.o
    rm -f ./doc/FAQ
    rm -f ./doc/faq.html
    rm -f ./doc/gpg.1
    rm -f ./doc/gpg.info
    rm -f ./doc/gpg.info-1
    rm -f ./doc/gpg.ru.1
    rm -f ./doc/gpgv.1
    rm -f ./doc/gpgv.info
    rm -f ./doc/makefile
    rm -f ./doc/makefile.in
    rm -f ./g10/.deps/*
    rmdir ./g10/.deps
    rm -f ./g10/makefile
    rm -f ./g10/makefile.in
    rm -f ./g10/*.o
    rm -f ./g10/*.exe
    rm -f ./intl/makefile
    rm -f ./keyserver/.deps/*
    rmdir ./keyserver/.deps
    rm -f ./keyserver/gpgkeys_mailto
    rm -f ./keyserver/gpgkeys_test
    rm -f ./keyserver/makefile
    rm -f ./keyserver/makefile.in
    rm -f ./keyserver/*.o
    rm -f ./keyserver/*.exe
    rm -f ./m4/makefile
    rm -f ./m4/makefile.in
    rm -f ./mpi/.deps/*
    rmdir ./mpi/.deps
    rm -f ./mpi/sysdep.h
    rm -f ./mpi/asm-syntax.h
    rm -f ./mpi/*.lnk
    rm -f ./mpi/*.s
    rm -f ./mpi/*.S
    rm -f ./mpi/mpi-asm-defs.h
    rm -f ./mpi/makefile
    rm -f ./mpi/makefile.in
    rm -f ./mpi/*.o
    rm -f ./mpi/libmpi.a
    rm -f ./po/makefile
    rm -f ./po/POTFILES
    rm -f ./po/makefile.in
    rm -f ./tools/.deps/*
    rmdir ./tools/.deps
    rm -f ./tools/gpg-zip
    rm -f ./tools/makefile
    rm -f ./tools/makefile.in
    rm -f ./tools/*.o
    rm -f ./tools/*.exe
    rm -f ./util/.deps/*
    rmdir ./util/.deps
    rm -f ./util/makefile
    rm -f ./util/makefile.in
    rm -f ./util/libutil.a
    rm -f ./util/*.o
    rm -f ./util/*.exe
    rm -f ./zlib/.deps/*
    rmdir ./zlib/.deps
    rm -f ./zlib/makefile
    rm -f ./zlib/makefile.in
    

    ...and you again copy and paste the content in your editor and save it as "reset.sh" in your \4136 folder, so we happily proceed further.  

     

    Now we have to modiify one already known file. It is the scrypt build_gpg.sh, we already have used in compiling the release version, 1.4.3, of GnuPG.

    Would be actually best to simply copy this file from your \143 folder into the \4136 and then to modify it a bit.

    We shell change just the "--prefix=" instruction, so the part...

     --prefix=/home/gpg-static-143
    
    ...will be then...

     --prefix=/home/gpg-static-4136
    
    ...and the modified file will then look like this...

    The modified build_gpg.sh file

    #!/bin/sh
    # <>o<> The script file `build_gpg.sh'. It builds the Thing. Just
    # <>o<> to remind myself if I make a mess with the file names.
    # <>o<> The script for the work in MSYS/MinGW32 environment.
    # <>o<> Here, it is modified for a CVS build and dwells in _CVS_
    # <>o<> `build folder'.

    make distclean

    ./configure CFLAGS='-g -O2 -march=i386 -mfpmath=387' LDFLAGS='-s -static' --prefix=/home/gpg-static-4136

    make

    make install

    make check

    ...so we save it happily and go further.

    ____________
    The purpose of this modification is nothing more than to just make a new folder, \gpg-static-4136, for our CVS build, so that the our previous release 1.4.3 build will not be (happily) overwritten.
     

    Now we shall explain how to modify the script configure.ac to reflect the current SVN number, and the build environment.

    Open the file...

    c:\msys\1.0\home\login-name\4136\configure.ac 
    
    ...find these two lines...

    m4_define([svn_revision], m4_esyscmd([echo -n $((svn info 2>/dev/null \
              || echo 'Revision: 0')|sed -n '/^Revision:/ s/[^0-9]//gp'|head -1)]))

    ..."comment out" them, by putting the "#" sign at the very beggining of these lines, so it looks like this...

    #m4_define([svn_revision], m4_esyscmd([echo -n $((svn info 2>/dev/null \
    #          || echo 'Revision: 0')|sed -n '/^Revision:/ s/[^0-9]//gp'|head -1)]))

    ...then add this line, right above these two...

    m4_define([svn_revision], [-4136])

    ...so that it looks like this...

    m4_define([svn_revision], [-4136])
    #m4_define([svn_revision], m4_esyscmd([echo -n $((svn info 2>/dev/null \
    #          || echo 'Revision: 0')|sed -n '/^Revision:/ s/[^0-9]//gp'|head -1)]))

    ...and then we save it happily and go further.

    _____________
    After the compiling is over, the finished gpg.exe will, when evoked by the command "gpg --version" (at a command line), display a line like this related to version number...
    gpg (GnuPG) 1.4.4-svn-4136
    
    ...and you, and others, will know exactly what GnuPG version you are using.

    --

    Now, if you are building GnuPG in both MSYS/MinGW32 and Cygwin/MinGW32 environment, then is good to make yet another modification in the configure.ac file, so that will be known which method/environment is used in the process of compiling, and you will know then better where to search for a "fix" if needed, in a case of coyote/a 'bug'/an error/destroyed (love|sexual) life/the end of the world, and similar trivial, prosaic, banal and ephemeral events, or simply if instead of the "Good signature from" you see that appears a "Mmm...what a nice signature from", which would mean that someone did play with the source codes in your absence. Well, so it is when they are open...

    Okay, get serious now, open configure.ac, find this line...

            PRINTABLE_OS_NAME="MingW32"
    
    ...and before the `MingW32' add a `MSYS/', so that it looks like this...
            PRINTABLE_OS_NAME="MSYS/MinGW32"
    
    ...which will give us additional information about the piece of the jewel we shall be using soon (and will fix en passant the typo "Ming" denoting rather the name of the dynasty, than the "Minimal GNU"). The usual version line...
    Version: GnuPG v1.4.3 (MingW32)
    
    ...will now look like this...
    Version: GnuPG v1.4.4-svn-4136 (MSYS/MinGW32)
    
    ...and we are ready for the compiling.  

     

    So, we kick the cat out, start MSYS and type in this...

    cd 4136
    
    ...strike the [enter] button, and then type this...
    ./prep.sh
    
    ...strike the [enter] button, and let the script do its job. After it's finished, you type in...
    ./build_gpg.sh
    
    ...hit the [enter] again and that's it. After some quite bearable time, you will have a fresh new and hot, still smoking, GnuPG v1.4.4-svn-4136 in your \gpg-static-4136 folder.
    _____________
    Also, you can combine both the commands together, so you don't have to wait until the work of the first one is finished. You link them by "&&", like this...
    ./prep.sh && ./build_gpg.sh
    
    ...and you go to do something else, namely if you are not transfixed by watching the rain of the codes raining upward.

    --

    Besides, if you would indeed rather to leave the machine (alone) and go to do something else in the meantime, then is not bad idea to edit the file...

    c:\msys\1.0\etc\profile 
    
    ...finding the line...
    \033[32m\]\u@\h \[\033[33m\w\033[0m\] 
    
    ...and adding a "\t " before the "\u@", so it looks like this...
    \033[32m\]\t \u@\h \[\033[33m\w\033[0m\] 
    
    ...for it will give you a "timestamp" in the "prompt line", before your user-name, something like this...
    23:06:49 user-name@computer-name ~/4136
    $ 
    
    ...so you will know then when the compiling process had been finished.
     

    The role of the script prep.sh is to add the missing files to CVS distribution to turn it into a release distribution.

    The role of the script reset.sh is to remove all the object code and .exe files, and all the files added by prep.sh. The sript reset.sh is called by the script prep.sh.

     

    With this, we have compiling of a CVS/SVN version of GnuPG finished, and now we go to do something even a bit more complex and beautiful...  

     

    1.2.3. Compiling a CVS version of GnuPG with added TIGER192 algorithm

     

    1.2.3.1. The software we need and the files

    Back up your SVN 4132 source code (from the folder the output is done using TortoiseSVN, that is from the \gpg_source), and put this backup somewhere aside (where you would like to find it once you need it again).

    Make two new nice fresh folders, one of them naming "gpg-original" and the other one "gpg-modified".

    Place the source files from TortoiseSVN output folder (the \gpg_source) into the \gpg-original.

    Download the archive "GnuPG_SVN_4132_SOURCE.zip" from here...

    <https://tronogi.tripod.com/GpgCompilingFilesByTom/MsysMingwFilesForCvsBuild/>

    ...and unzip all the files into the folder \gpg-modified.

    Those are the files modified/needed for TIGER192 we are going to deal with now.

    ____________
    In the folder \checks\cygwin, you can find the Cygwin version of the file `seat.test' too. It is intended for those compiling in Cygwin/MinGW32 environment, so you can delete this \cygwin folder safely, if you want, since we do not need it now. (Actually, we need it as we would need a cat playing with...keyboard, although the said folder makes no harm.)

    -·-

    Download WinMerge, from here...

    <http://sourceforge.net/project/showfiles.php?group_id=13216&package_id=11248>

    ...choosing the highest stable version you can find.

    Install WinMerge and reboot the machine.

    Go to Edit | Options | Categories | General, and under "Enable multiple compare windows for" check all the boxes in there.

    Under category "Compare", check "Ignore carriage return differences (DOS/UNIX/MAC)" and "Enable moved block detection".

    Under category "System", check "Add to explorer context menu" and "Enable advanced menu".

    Close WinMerge.

     

    1.2.3.2. Compiling

    Now, in the archive "GnuPG_SVN_4132_SOURCE.zip" there are 14 (fourteen) files. Two of them are these...

    \cipher\idea.c
    \cipher\tiger.c
    
    ...of which `idea.c' you can delete if you don't need it (at all, or as a feature built-in into the EXE files, so you don't need the external idea.dll anymore), while the `tiger.c' should never need to be changed. Both the files are never included in the CVS updates, so they can simply be copied, from the said archive, as they are, into our `build folder'.

    Of the remaining 12 (twelve) files, one, the `seat.test', is duplicated, with one version for MSYS and the one for Cygwin (placed in \checks\cygwin\ folder -- and this one we don't need now), so we shall count that there is a total number of 11 (eleventh) remaining files which might, and probably at some point will be updated during the updates we do by TortoiseSVN. Those are therefore these files...

    \configure.ac
    \checks\seat.test
    \checks\mds.test
    \cipher\makefile.am
    \cipher\md.c
    \cipher\algorithms.h
    \g10\armor.c
    \g10\gpg.c
    \g10\keygen.c
    \g10\options.h
    \include\cipher.h
    
    ...we have to check for changes, possibly coming with any new TortoiseSVN update, so we could modify them then, by inserting the modifications we need for TIGER192.  

     

    Firstly we shall explain how to check for the changes using WinMerge, and how to modify the files if needed.

    Open Windows Explorer (or some other file manager, I use Total Commander), browse to and right click on this file...

    \gpg-original\configure.ac
    
    ...and then left click on "Compare To".

    Then go to the file...

    \gpg-modified\configure.ac
    
    ...right click on it and then left click on "Compare".

    The WinMerge will start, and in the left pane will be the original source code file, while modified one will be in the right one.

    We have now to take modifications for TIGER192, given in the right pane, and copy them to the left pane.

    (Kick the cat out or close the Winpenguins. Your choice.)

    Now, if you have the option (Edit | Option | General) "Automatically scroll to first difference" checked, then the mammal's cursor will be at the first difference, otherwise it will be at the begining of the file[s]. If it is at the beginning, then use Merge | Next Difference, or the icon Next Diff (with the yellow arrow pointing downward), or the keys Alt+Down, which will bring you to the first next difference in the files.

    On the right will be a highlighted block beginning with "# TIGER192". Click the icon "Copy Left" (the one with the black arrow pointing to the left), or use keys Alt+Left, to copy the block from the right pane to the left one.

    Then click the icon Next Diff, or use keys Alt+Down, to go to the next difference.

    Again, the next block beginning with "# TIGER192" will be highlighted, and we copy it from the right pane to the left one using the same procedure.

    We have to repeat this until there are no more the highlighted "TIGER192" blocks on the right.

    At this point we save the left file happily and exit WinMerge.

    This procedure must be repeated for every file with TIGER192 modifications (those 11, to remind us), any time they are updated (via TortoiseSVN or any other way).

    Now, a word of caution, "just in case": add the TIGER192 modification to original files, not the other way around.

    Also, as you update each the file, copy it back from \gpg-original to \gpg-modified folder -- since this file is now the most up to date TIGER192 modified file.

    When all the files have been updated, copy happilly \gpg-original to your `build folder', which in this documentation is \4136.  

     

    Then go to the "build folder" and edit `configure.ac' to reflect the current build/SVN number, as it is already described earlier, when we were building "ordinary" CVS/SVN version of GnuPG, without TIGER192 added. Wouldn't be bad too, to add a "description" of this build, so that you and others using this particular GnuPG could know if it is TIGER192 enabled or not, who is responsible for the build (in the case of adoration/tomatoation), so the related line in `configure.ac' could look as something like this...

    m4_define([svn_revision], [-4136 my-build tiger192])

    ...or like this...

    m4_define([svn_revision], [-4136 Joe t-192])

    ...or after whatever you find appropriate/useful/informative to give it a shape.

    Also, if you use both MSYS and Cygwin environment to build GnuPG, don't forget to modify the line...

    PRINTABLE_OS_NAME="MinGW32"

    ...in `configure.ac' file into the...

    PRINTABLE_OS_NAME="MSYS/MinGW32"

    ...so you can know later what environment/procedure had been used in the compilation process, in a case of a bug or whatever else.  

     

    In your `build_gpg.sh' file you also should edit the instruction...

     --prefix=/home/gpg-static-4136
    

    ...to point to a new folder...

     --prefix=/home/gpg-static-with-tiger-4136
    

    ...where the EXE files of this modified version of GnuPG, suporting TIGER192, will be placed, once the compilation process is finished, so that your previous build will not be overwritten and you will know easier what is inside the folder.

    Also, you have now to add some new instructions, telling to the scripts to add the TIGER192 into EXE files...

     --enable-tiger
    
    ...and, if you want/need it, the instrunction for building support for creation of large keys...
     --enable-key-cache=8192 --enable-large-key
    
    ...so the whole `build_gpg.sh' script looks like this now...

    The modified build_gpg.sh file for TIGER192

    #!/bin/sh
    # <>o<> The script file `build_gpg.sh'. It builds the Thing. Just
    # <>o<> to remind myself if I make a mess with the file names.
    # <>o<> The script for the work in MSYS/MinGW32 environment.
    # <>o<> Here, it is modified for a CVS build with added TIGER192
    # <>o<> and Large-Key support, and dwells in _CVS_
    # <>o<> `build folder'.

    make distclean

    ./configure CFLAGS='-g -O2 -march=i386 -mfpmath=387' LDFLAGS='-s -static' --prefix=/home/gpg-static-4136 --enable-key-cache=8192 --enable-tiger --enable-large-key

    make

    make install

    make check

    ...where the parameter

     --enable-tiger
    
    ...enables the TIGER192 hash algorithm to be compiled into the executable code, since without this parameter all the TIGER192 modifications, although now present in the source code files, will be ignored and thus not compiled.

    The parameter...

     --enable-large-key
    
    ...enables generation of an RSA key up to 8192 bits rather than the default of 4096 bits. Without this parameter the original routine of generation of the key is used, and the modified routine is ignored and thus not compiled.

    The parameter...

     --enable-key-cache=8192
    
    ...relates neither to TIGER192 nor Large-Key Support, but is changing the default key cache size from 4092 bytes to 8192 bytes. With a large(r) key-ring this makes possible faster access to the keys.  

     

    At this point, with having all of the mentioned done fine, we are ready for compiling, so we start MSYS, type in...

    cd 4169
    

    ...then...

    ./prep.sh && ./build_gpg.sh
    

    ...and the compiling process starts.

     

     

     

     

    How to compile CVS versions of GnuPG, with and without TIGER192
    1. Compiling in MSYS/MinGW32
    Page 1 of 3
     

     

    <>o<>
     

    2. Compiling in Cygwin/MinGW32

     

    2.1. Installation of the needed files, programs and environment (The Foreplay)

    Firstly, we have to prepare the environment we shall work in on making GnuPG.

    For this, we need these main ingredients:

  • one piece of a Windows (I use[d] Windows XP Professional);
  • Cygwin, one piece.

    In addition, and optionally, those who are fond of a romance may light a candle or two.

    Those who are easily excited {sh|c}ould keep a glass of fresh water handy and some sugar.

     

    2.1.1. Cygwin

    What is Cygwin...

    Cygwin is a Linux-like environment which can work under Windows. More about it can be found here <http://www.cygwin.com/>.  

     

    2.1.1.1. Cygwin: The files we need

    1. Development Category

    autoconf 2.5
    automake 1.9
    binutils
    curl-devel
    gcc-core
    cgg-mingw-core
    gettext
    gettext-devel
    libiconv
    libusb-win32
    make
    mingw-runtime
    minires-devel
    openssl-devel
    readline
    2. Libs Category (may already be checked, by the default download/setup)
    gettext
    libbz2_1
    libcurl3
    libgettextpo0
    libiconv
    libiconv2
    libintl
    libintl1
    libintl2
    libintl3
    libopenldap2_2_7
    libreadline6
    libusb-win32
    mingw-runtime
    minires
    minires-devel
    openldap
    openldap-devel
    openssl
    openssl-devel
    openssl097
    readline
    w32api
    zlib

    3. MinGW Category

    Everything, that is...

    mingw-bzip2-1.0.3.1
    mingw-libbz2_1-1.0.3-1
    mingw-zlib-1.2.2-2

    4. The following is also needed for Win32 builds:
    bzip2-1.0.3-1-bin.zip - from <http://gnuwin32.sourceforge.net/>
    bzip2-1.0.3-1-lib.zip - from <http://gnuwin32.sourceforge.net/>
    CURL_EXTERNAL-MINGW.zip - from here (these files are same as in MSYS).
    5. Cygwin setup program

    This one we find here <http://www.cygwin.com/>.  

     

    2.1.1.2. Cygwin: Installation

    Download setup program from here <http://www.cygwin.com/> and run it. It will install Cygwin.

    After the default installation is complete, using setup program again check if all the files listed in 1), 2) and 3) are present.

    Take then the files listed in 4) and unzip them in /usr/local/ directory. (For bzip2 files it is needed because those coming with Cygwin setup program are not fully compatible with a Win32 build, so that we have to use those from sourceforge.net.)

    Now we have Cygwin installed fine.  

     

    2.2. Compiling (The Action)

    There are two build/compiling methods: static and dynamic.

    "Static" means that all libraries (except iconv.dll) are included in the *.exe files, and such is for instance the GnuPG for Win32 we get from GnuPG.org: <http://www.gnupg.org>.

    "Dynamic" means that GnuPG for Unix, for instance, uses external files rather (they are equivalent to the libraries in Win32) which are stored in various system folders (for instance the file readline, gettext and many other dynamic files). Such programs are a bit (or a bit more) smaller, but they are dependent on those external files and cannot work without them (if by a chance, for instance, the operative system has not these files installed).

    Besides, both these static and dynamic builds might be full and minimal, and being that the official build from GnuPG is a blend between minimal and full one, and is static, this will be the way of compiling we shall cover here, making it just like the `official build', except that we'll add after that the TIGER192 and some other confectioneries.

    Now we go to make it...  

     

    2.2.1. Compiling a release version of GnuPG

    Firstly, we shall explain meanings of two terms, `home' and `$home'. The `home' is the name of the folder (or of the directory, as it is named in DOS and some other environments) in our \CYGWIN path.

    In this `home' folder, there is a folder created the first time we have started CYGWIN and is named after our Windows login (or user) name. This login-name folder we shell refer to as the `$home folder'. We can always change to this folder from anywhere by typing this...

    cd $home
    
    ...or this...
    cd ~
    

    --

    We shall start now by compiling an `official release' of GnuPG, and we'll take the actual version 1.4.3 to start with.

    For this we have to download the source code for GnuPG v1.4.3 from: <http://www.gnupg.org/(en)/download/mirrors.html>.

    In Windows, create a folder in the \usr\src directory, name it `143' and place the source files there, so it looks like this...

    c:\cygwin\usr\src\143\
    

    ...and this \143 folder we shall call now on `build folder'.

    Since we shall make a Win32 version of GnuPG which will create data files (ASCII-Armor Signature) with a DOS End Of Line (EOL) sequence (ASCII 13 / ASCII 10), we must modify one file or the tests will fail.

    Important! Now on, for every file we edit/modify for the work in Cygwin/MinGW32 we should use the said Notepad2. It is a Win32 editor that works with Unix files, is free, and you can find it here. The important part is that every such file should be saved with Unix line endings (LF) -- File | Line Endings | Unix (LF) -- or we could have problems in compiling later on.

    The file we have to modify is \checks\seat.test...

    The original seat.test file

    #!/bin/sh
    # <>o<> Original \checks\seat.test file
    # <>o<> from the release source of GnuPG.
    
    . $srcdir/defs.inc || exit 3
    
    for i in $plain_files ; do
        echo "$usrpass1" | $GPG --passphrase-fd 0 --always-trust -seat \
                            -r two -o x --yes $i
        $GPG -o y --yes x
        cmp $i y || error "$i: mismatch"
    done
    

    ...and we do that this way: we open it in Notepad2, and the part...

        $GPG -o y --yes x
        cmp $i y || error "$i: mismatch"
    done
    
    ...we change to be...

        $GPG -o y --yes x
    	unix2dos --force $i
        cmp $i y || error "$i: mismatch"
        	dos2unix --force $i 
    done
    
    ...so the modified file looks like this...

    The modified seat.test file

    #!/bin/sh
    # <>o<> Modified \checks\seat.test file
    # <>o<> for the work in Cygwin/MinGW32 environment.
    # <>o<> Edit it in Notepad2 and be sure the Line Endings are set
    # <>o<> to UNIX (LF)!
    
    . $srcdir/defs.inc || exit 3
    
    for i in $plain_files ; do
        echo "$usrpass1" | $GPG --passphrase-fd 0 --always-trust -seat \
                            -r two -o x --yes $i
        $GPG -o y --yes x
    	unix2dos --force $i
        cmp $i y || error "$i: mismatch"
        	dos2unix --force $i 
    done
    

    ...then we check if Line Endings are set to Unix (LF) and then we save it happily and go further.  

     

    Now we have to create a file `build_gpg.sh', in order to compile GnuPG as close as possible to the official release.

    Copy and paste, into Notepad2, the script given below, check if Line Endings are set to Unix (LF), and save it in the folder \143.

    The script file `build_gpg.sh'

    #!/bin/sh
    # <>o<> The script file `build_gpg.sh'. It builds the Thing. Just
    # <>o<> to remind myself if I make a mess with the file names.
    # <>o<> This one is for Cygwin/MinGW32 environment!
    # <>o<> Edit it in Notepad2 and be sure the Line Endings are set
    # <>o<> to UNIX (LF)!
    export CC="gcc -mno-cygwin"
    export RANLIB="ranlib"

    make distclean

    ./configure CFLAGS='-g -O2 -march=i386 -mfpmath=387 ' LDFLAGS='-s -static' --prefix=/home/gpg-static-143 --with-included-gettext --host=i686-pc-mingw32 --with-bzip2=/usr/local/

    make

    make install

    make check

    Then start Cygwin and type...

    cd /usr/src/143
    
    ...push the [enter] button, then type...
    ./build_gpg.sh
    
    ...push the [enter] again and that's it. The compiling process will start, and, if we have done everything well, will finish happily with all GnuPG executables dwelling in the folders...
    c:\cygwin\home\login-name\gpg-static-143\bin\
    
    ...and...
    c:\cygwin\home\login-name\gpg-static-143\libexec\
    
    We may now copy them into the folder we have installed our GnuPG in, and use them as we usually do.

    --

    Now, if we need this, we can add even IDEA to this build, so that the idea.dll is not needed to be used anymore.

    In this case, we download `idea.c.gz' file from here...

    <ftp://ftp.gnupg.dk/pub/contrib-dk/idea.c.gz>

    ...unzip `idea.c' and place it in the \143\cipher folder.

    Then we run the `build_gpg.sh' script again, and that's it.

    Since IDEA will now be built-in into the EXE files, they will be a bit bigger but not much.

    ____________
    Optionally, before we run again the `build_gpg.sh' script, we can modify it a bit, if we want to keep our previous v1.4.3 build (the one without IDEA built in) too. In this case the part...
     --prefix=/home/gpg-static-143
    
    ...we change to be as something like this...
     --prefix=/home/gpg-static-143-idea
    
    ...so the new build with IDEA will be placed in this new folder, after the compiling process is over, and the content of our existing folder \gpg-static-143 will not be overwritten.
    With this, we have compiling of a release version of GnuPG finished, and now we go to do something a bit more complex and nicer...  

     

    2.2.2. Compiling a CVS version of GnuPG

    Well, just to appease some elementary curiosity, we shall say that the "CVS" stands for "Concurrent Version System", and "SVN" for "SubVersion", for those are pretty complex and ample systems we absolutely have no any practical need to get here and now much into, except perhaps just to say that these systems make possible to us to get newest source files created in the time between two release versions (in the course of the work of all the programmers involved) of a given program, in this case of GnuPG. For those needing more informations good place for start is here: <http://www.cs.utah.edu/dept/old/texinfo/cvs/cvs_toc.html>.  

     

    2.2.2.1. The software we need

    Download TortoiseSVN from <http://tortoisesvn.tigris.org/>.

    Install it and reboot computer.

    Create a folder where you will receive the SVN files. Here we'll name this folder "svn", and will assume it is on C partition, that is a "C:\svn".

    Then, right click on the \svn folder, select TortoiseSVN -> Settings, and in the General section check the `Set filedates to the "last commit time"'. Click [OK].

    Right click again on the \svn folder, and select "SVN Checkout". For "URL of repository" type in "svn://cvs.gnupg.org/gnupg/trunk" (at the beginning of August 2006 this address changed to "svn://cvs.gnupg.org/gnupg/branches/STABLE-BRANCH-1-4"!), and for the "Checkout directory" should already stay there a "C:\SVN". The Revision should be set to "HEAD Revision". When you click the [OK], the files will start to download.

    It will take longer only the first time, for from now on you will not do the "SVN Checkout" but a "SVN Update" instead, downloading, now and then, just updated source files.

    Now, and this is important, we'll not use the files from this \svn folder, but will create instead an other folder for this. Here, we'll name this folder "gpg_source".

    Then, right click on the \svn folder, select TortoiseSVN -> Export, then browse to the \gpg_source folder, and select it. Check both the "Export universioned files too" and the "Omit externals" boxes.

    Now we have in the \gpg_source folder just the SVN source files without all the extra files created by TortoiseSVN for the purpose of administration of all the changes.

    If we wish/need this, we can also add idea.c in the cipher folder, that is in the \gpg_source\svn\cipher.

    Now we go to build the Thing...  

     

    2.2.2.2. Compiling

    Firstly, we shall make a `build folder' for our CVS build. Since the current SVN sequence number in the time of writing this documentation is/was 4136, we'll name this folder "4136". We create it in our \usr\src folder in Cygwin, that is...

    c:\cygwin\usr\src\4136\
    
    ...and we place our CVS files (from \gpg_source\svn\, not from \gpg_source\, thus excluding the \svn folder) in it.

    Now, we have to create two more scripts, prep.sh and reset.sh.

    The prep.sh should look like this...

    The prep.sh script

    #!/bin/sh
    # <>o<> The `prep.sh' script, dwelling in the `build folder',
    # <>o<> for instance \cygwin\usr\src\4136\prep.sh
    # <>o<> For the work in Cygwin/MinGW32 environment!
    # <>o<> Edit it in Notepad2 and be sure the Line Endings are set
    # <>o<> to UNIX (LF)!
    export CC="gcc -mno-cygwin"
    export RANLIB="ranlib"

    # reset.sh brings everyting back to CVS state ( bare bones )
    ./reset.sh

    ./scripts/autogen.sh

    ./configure LDFLAGS='-s -static' --enable-maintainer-mode --host=i686-pc-mingw32

    ...and you may simply copy and paste the content above, into Notepad2, then check if Line Endings are set to Unix (LF), and save it in your \4136 folder.  

     

    The other file, reset.sh, should look like this...

    The reset.sh script

    #!/bin/sh
    # reset.sh rev 1.1
    # added rm -f ./mpi/*.S
    # <>o<> The `reset.sh' script, dwelling in the `build folder',
    # <>o<> for instance \cygwin\usr\src\4136\reset.sh
    # <>o<> when we work in Cygwin/MinGW32 environment.
    # <>o<> Edit it in Notepad2 and be sure the Line Endings are set
    # <>o<> to UNIX (LF)!
    
    make distclean
    rm -f ./configure
    rm -f ./makefile
    rm -f ./makefile.in
    rm -f ./config.log
    rm -f ./config.h.in
    rm -f ./aclocal.m4
    rm -f ./config.log
    rm -f ./g10defs.h
    rm -f ./stamp-h1
    rm -f ./config.h
    rm -f ./config.status
    rm -f ./confdefs.h
    rm -f ./*.bak
    rm -f ./autom4te.cache/*
    rmdir ./autom4te.cache
    rm -f ./checks/*.bak
    rm -f ./checks/makefile
    rm -f ./checks/makefile.in
    rm -f ./checks/*.log
    rm -f ./checks/x
    rm -f ./checks/y
    rm -f ./checks/z
    rm -f ./checks/random_seed
    rm -f ./checks/*.gpg
    rm -f ./checks/*.?kr
    rm -f ./checks/plain-1
    rm -f ./checks/plain-2
    rm -f ./checks/plain-3
    rm -f ./checks/plain-large
    rm -f ./checks/prepared.stamp
    rm -f ./checks/data*
    rm -f ./checks/gpg_dearmor
    rm -f ./cipher/.deps/*
    rmdir ./cipher/.deps
    rm -f ./cipher/makefile
    rm -f ./cipher/makefile.in
    rm -f ./cipher/libcipher.a
    rm -f ./cipher/*.o
    rm -f ./doc/FAQ
    rm -f ./doc/faq.html
    rm -f ./doc/gpg.1
    rm -f ./doc/gpg.info
    rm -f ./doc/gpg.info-1
    rm -f ./doc/gpg.ru.1
    rm -f ./doc/gpgv.1
    rm -f ./doc/gpgv.info
    rm -f ./doc/makefile
    rm -f ./doc/makefile.in
    rm -f ./g10/.deps/*
    rmdir ./g10/.deps
    rm -f ./g10/makefile
    rm -f ./g10/makefile.in
    rm -f ./g10/*.o
    rm -f ./g10/*.exe
    rm -f ./intl/makefile
    rm -f ./keyserver/.deps/*
    rmdir ./keyserver/.deps
    rm -f ./keyserver/gpgkeys_mailto
    rm -f ./keyserver/gpgkeys_test
    rm -f ./keyserver/makefile
    rm -f ./keyserver/makefile.in
    rm -f ./keyserver/*.o
    rm -f ./keyserver/*.exe
    rm -f ./m4/makefile
    rm -f ./m4/makefile.in
    rm -f ./mpi/.deps/*
    rmdir ./mpi/.deps
    rm -f ./mpi/sysdep.h
    rm -f ./mpi/asm-syntax.h
    rm -f ./mpi/*.lnk
    rm -f ./mpi/*.s
    rm -f ./mpi/*.S
    rm -f ./mpi/mpi-asm-defs.h
    rm -f ./mpi/makefile
    rm -f ./mpi/makefile.in
    rm -f ./mpi/*.o
    rm -f ./mpi/libmpi.a
    rm -f ./po/makefile
    rm -f ./po/POTFILES
    rm -f ./po/makefile.in
    rm -f ./tools/.deps/*
    rmdir ./tools/.deps
    rm -f ./tools/gpg-zip
    rm -f ./tools/makefile
    rm -f ./tools/makefile.in
    rm -f ./tools/*.o
    rm -f ./tools/*.exe
    rm -f ./util/.deps/*
    rmdir ./util/.deps
    rm -f ./util/makefile
    rm -f ./util/makefile.in
    rm -f ./util/libutil.a
    rm -f ./util/*.o
    rm -f ./util/*.exe
    rm -f ./zlib/.deps/*
    rmdir ./zlib/.deps
    rm -f ./zlib/makefile
    rm -f ./zlib/makefile.in
    

    ...and you again copy and paste the content in your Notepad2, check if Line Endings are set to Unix (LF), then save it as "reset.sh" in your \4136 folder, so we happily proceed further.  

     

    Now we have to modiify one already known file. It is the scrypt build_gpg.sh, we already have used in compiling the release version, 1.4.3, of GnuPG.

    Would be actually best to simply copy this file from your \143 folder into the \4136 and then to modify it a bit, using Notepad2.

    We shell change just the "--prefix=" instruction, so the part...

     --prefix=/home/gpg-static-143
    
    ...will be then...

     --prefix=/home/gpg-static-4136
    
    ...and the modified file will then look like this...

    The modified build_gpg.sh file

    #!/bin/sh
    # <>o<> The script file `build_gpg.sh'. It builds the Thing. Just
    # <>o<> to remind myself if I make a mess with the file names.
    # <>o<> This one is for Cygwin/MinGW32 environment!
    # <>o<> Edit it in Notepad2 and be sure the Line Endings are set
    # <>o<> to UNIX (LF)!
    export CC="gcc -mno-cygwin"
    export RANLIB="ranlib"

    make distclean

    ./configure CFLAGS='-g -O2 -march=i386 -mfpmath=387 ' LDFLAGS='-s -static' --prefix=/home/gpg-static-4136 --with-included-gettext --host=i686-pc-mingw32 --with-bzip2=/usr/local/

    make

    make install

    make check

    ...so we save it happily, checking firstly if we have set the Line Endings to Unix (LF), and go further.

    ____________
    The purpose of this modification is nothing more than to just make a new folder, \gpg-static-4136, for our CVS build, so that the our previous release 1.4.3 build will not be (happily) overwritten.
     

    Now we shall explain how to modify the script configure.ac to reflect the current SVN number, and the build environment.

    Using Notepad2, open the file...

    c:\cygwin\usr\src\4136\configure.ac 
    
    ...find these two lines...

    m4_define([svn_revision], m4_esyscmd([echo -n $((svn info 2>/dev/null \
              || echo 'Revision: 0')|sed -n '/^Revision:/ s/[^0-9]//gp'|head -1)]))

    ..."comment out" them, by putting the "#" sign at the very beggining of these lines, so it looks like this...

    #m4_define([svn_revision], m4_esyscmd([echo -n $((svn info 2>/dev/null \
    #          || echo 'Revision: 0')|sed -n '/^Revision:/ s/[^0-9]//gp'|head -1)]))

    ...then add this line, right above these two...

    m4_define([svn_revision], [-4136])

    ...so that it looks like this...

    m4_define([svn_revision], [-4136])
    #m4_define([svn_revision], m4_esyscmd([echo -n $((svn info 2>/dev/null \
    #          || echo 'Revision: 0')|sed -n '/^Revision:/ s/[^0-9]//gp'|head -1)]))

    ...and then we save it happily, checking first if the Line Endings are set to Unix (LF), and go further.

    _____________
    After the compiling is over, the finished gpg.exe will, when evoked by the command "gpg --version" (at a command line), display a line like this related to version number...
    gpg (GnuPG) 1.4.4-svn-4136
    
    ...and you, and others, will know exactly what GnuPG version you are using.

    --

    Now, if you are building GnuPG in both MSYS/MinGW32 and Cygwin/MinGW32 environment, then is good to make yet another modification in the configure.ac file, so that will be known which method/environment is used in the process of compiling, and you will know then better where to search for a "fix" if needed, in a case of coyote/a 'bug'/an error/destroyed (love|sexual) life/the end of the world, and similar trivial, prosaic, banal and ephemeral events, or simply if instead of the "Good signature from" you see that appears a "Mmm...what a nice signature from", which would mean that someone did play with the source codes in your absence. Well, so it is when they are open...

    Okay, get serious now, open configure.ac, find this line...

            PRINTABLE_OS_NAME="MingW32"
    
    ...and before the `MingW32' add a `Cygwin/', so that it looks like this...
            PRINTABLE_OS_NAME="Cygwin/MinGW32"
    
    ...which will give us additional information about the piece of the jewel we shall be using soon (and will fix en passant the typo "Ming" denoting rather the name of the dynasty, than the "Minimal GNU"). The usual version line...
    Version: GnuPG v1.4.3 (MingW32)
    
    ...will now look like this...
    Version: GnuPG v1.4.4-svn-4136 (Cygwin/MinGW32)
    
    ...and we are ready for the compiling.  

     

    So, we kick the cat out, start Cygwin and type in this...

    cd /usr/src/4136
    
    ...strike the [enter] button, and then type in this...
    ./prep.sh
    
    ...strike the [enter] again, and let the script do its job. After it's finished, you type in...
    ./build_gpg.sh
    
    ...hit the [enter] again and that's it. After some quite bearable time, you will have a fresh new and hot, still smoking, GnuPG v1.4.4-svn-4136 in your \gpg-static-4136 folder.
    _____________
    Also, you can combine both the commands together, so you don't have to wait until the work of the first one is finished. You link them by "&&", like this...
    ./prep.sh && ./build_gpg.sh
    
    ...and you go to do something else, namely if you are not transfixed by watching the rain of the codes raining upward.

    --

    Besides, if you would indeed rather to leave the machine (alone) and go to do something else in the meantime, then is not bad idea to edit the file...

    c:\cygwin\etc\profile 
    
    ...finding the line...

    PS1='\[\e]0;\w\a\]\n\[\e[32m\]\u@\h \[\e[33m\]\w\[\e[0m\]\n\$ '

    ...and adding a "\t " before the "\u@", so it looks like this...

    PS1='\[\e]0;\w\a\]\n\[\e[32m\]\t \u@\h \[\e[33m\]\w\[\e[0m\]\n\$ '

    ...for it will give you a "timestamp" in the "prompt line", before your user-name, something like this...

     15:16:51 user-name@computer-name /usr/src/4136 
     $                                              
    
    ...so you will know then when the compiling process had been finished (if it is something important to you, in the given moment of your life).
     

    The role of the script prep.sh is to add the missing files to CVS distribution to turn it into a release distribution.

    The role of the script reset.sh is to remove all the object code and .exe files, and all the files added by prep.sh. The sript reset.sh is called by the script prep.sh.

     

    With this, we have compiling of a CVS/SVN version of GnuPG finished, and now we go to do something even a bit more complex and delic{ate|ious}...  

     

    2.2.3. Compiling a CVS version of GnuPG with added TIGER192 algorithm

     

    2.2.3.1. The software we need and the files

    Back up your SVN 4132 source code (from the folder the output is done using TortoiseSVN, that is from the \gpg_source), and put this backup somewhere aside (where you would like to find it once you need it again).

    Make two new nice fresh folders, one of them naming "gpg-original" and the other one "gpg-modified".

    Place the source files from TortoiseSVN output folder (the \gpg_source) into the \gpg-original.

    Download the archive "GnuPG_SVN_4132_SOURCE.zip" from here...

    <https://tronogi.tripod.com/GpgCompilingFilesByTom/MsysMingwFilesForCvsBuild/>

    ...and unzip all the files into the folder \gpg-modified.

    Those are the files modified/needed for TIGER192 we are going to deal with now.

    ____________
    In the folder \checks\cygwin, you can find the Cygwin version of the file `seat.test' too. It is intended for those compiling in Cygwin/MinGW32 environment, exactly what we do right now, so you take this \cygwin\seat.test file and copy it into \checks folder, over the other one (which is used for compiling in MSYS/MinGW32 environment we do not need nor do now).

    -·-

    Download WinMerge, from here...

    <http://sourceforge.net/project/showfiles.php?group_id=13216&package_id=11248>

    ...choosing the highest stable version you can find.

    Install WinMerge and reboot the machine.

    Go to Edit | Options | Categories | General, and under "Enable multiple compare windows for" check all the boxes in there.

    Under category "Compare", check "Ignore carriage return differences (DOS/UNIX/MAC)" and "Enable moved block detection".

    Under category "System", check "Add to explorer context menu" and "Enable advanced menu".

    Close WinMerge.  

     

    2.2.3.2. Compiling

    Now, in the archive "GnuPG_SVN_4132_SOURCE.zip" there are 14 (fourteen) files. Two of them are these...

    \cipher\idea.c
    \cipher\tiger.c
    
    ...of which `idea.c' you can delete if you don't need it (at all, or as a feature built-in into the EXE files, so you don't need the external idea.dll anymore), while the `tiger.c' should never need to be changed. Both the files are never included in the CVS updates, so they can simply be copied, from the said archive, as they are, into our `build folder'.

    Of the remaining 12 (twelve) files, one, the `seat.test', is duplicated, with one version for MSYS and the one for Cygwin (placed in \checks\cygwin\ folder -- and this one we need now), so we shall count that there is a total number of 11 (eleventh) remaining files which might, and probably at some point will be updated during the updates we do by TortoiseSVN. Those are therefore these files...

    \configure.ac
    \checks\seat.test
    \checks\mds.test
    \cipher\makefile.am
    \cipher\md.c
    \cipher\algorithms.h
    \g10\armor.c
    \g10\gpg.c
    \g10\keygen.c
    \g10\options.h
    \include\cipher.h
    
    ...we have to check for changes, possibly coming with any new TortoiseSVN update, so we could modify them then, by inserting the modifications we need for TIGER192.  

     

    Firstly we shall explain how to check for the changes using WinMerge, and how to modify the files if needed.

    Open Windows Explorer (or some other file manager, I use Total Commander), browse to and right click on this file...

    \gpg-original\configure.ac
    
    ...and then left click on "Compare To".

    Then go to the file...

    \gpg-modified\configure.ac
    
    ...right click on it and then left click on "Compare".

    The WinMerge will start, and in the left pane will be the original source code file, while modified one will be in the right one.

    We have now to take modifications for TIGER192, given in the right pane, and copy them to the left pane.

    Now, if you have the option (Edit | Option | General) "Automatically scroll to first difference" checked, then the mammal's cursor will be at the first difference, otherwise it will be at the begining of the file[s]. If it is at the beginning, then use Merge | Next Difference, or the icon Next Diff (with the yellow arrow pointing downward), or the keys Alt+Down, which will bring you to the first next difference in the files.

    On the right will be a highlighted block beginning with "# TIGER192". Click the icon "Copy Left" (the one with the black arrow pointing to the left), or use keys Alt+Left, to copy the block from the right pane to the left one.

    Then click the icon Next Diff, or use keys Alt+Down, to go to the next difference.

    Again, the next block beginning with "# TIGER192" will be highlighted, and we copy it from the right pane to the left one using the same procedure.

    We have to repeat this until there are no more the highlighted "TIGER192" blocks on the right.

    At this point we save the left file happily and exit WinMerge.

    This procedure must be repeated for every file with TIGER192 modifications (those 11, to remind us), any time they are updated (via TortoiseSVN or any other way).

    Now, a word of caution, "just in case": add the TIGER192 modification to original files, not the other way around.

    Also, as you update each the file, copy it back from \gpg-original to \gpg-modified folder -- since this file is now the most up to date TIGER192 modified file.

    When all the files have been updated, copy happilly \gpg-original to your `build folder', which in this documentation is \4136.  

     

    Then go to the "build folder" and edit `configure.ac' to reflect the current build/SVN number, as it is already described earlier, when we were building "ordinary" CVS/SVN version of GnuPG, without TIGER192 added. Wouldn't be bad too, to add a "description" of this build, so that you and others using this particular GnuPG could know if it is TIGER192 enabled or not, who is responsible for the build (in the case of adoration/tomatoation), so the related line in `configure.ac' could look as something like this...

    m4_define([svn_revision], [-4136 my-build tiger192])

    ...or like this...

    m4_define([svn_revision], [-4136 Joe t-192])

    ...or after whatever you find appropriate/useful/informative to give it a shape.

    Also, if you use both MSYS and Cygwin environment to build GnuPG, don't forget to modify the line...

    PRINTABLE_OS_NAME="MinGW32"

    ...in `configure.ac' file into the...

    PRINTABLE_OS_NAME="Cygwin/MinGW32"

    ...so you can know later what environment/procedure had been used in the compilation process, in a case of a bug or whatever else.  

     

    In your `build_gpg.sh' file you also should edit the instruction...

     --prefix=/home/gpg-static-4136
    

    ...to point to a new folder...

     --prefix=/home/gpg-static-with-tiger-4136
    

    ...where the EXE files of this modified version of GnuPG, suporting TIGER192, will be placed, once the compilation process is finished, so that your previous build will not be overwritten and you will know easier what is inside the folder.

    Also, you have now to add some new instructions, telling to the scripts to add the TIGER192 into EXE files...

     --enable-tiger
    
    ...and, if you want/need it, the instrunction for building support for creation of large keys...
     --enable-key-cache=8192 --enable-large-key
    
    ...so the whole `build_gpg.sh' script looks like this now...

    The modified build_gpg.sh file for TIGER192

    #!/bin/sh
    # <>o<> The script file `build_gpg.sh'. It builds the Thing. Just
    # <>o<> to remind myself if I make a mess with the file names.
    # <>o<> The script for the work in Cygwin/MinGW32 environment.
    # <>o<> Here, it is modified for a CVS build with added TIGER192
    # <>o<> and Large-Key support, and dwells in _CVS_
    # <>o<> `build folder'.
    # <>o<> Edit/Copy it in Notepad2 and be sure the Line Endings are
    # <>o<> set to UNIX (LF)!
    export CC="gcc -mno-cygwin"
    export RANLIB="ranlib"

    make distclean

    ./configure CFLAGS='-g -O2 -march=i386 -mfpmath=387 ' LDFLAGS='-s -static' --prefix=/home/gpg-static-with-tiger-4136 --with-included-gettext --host=i686-pc-mingw32 --with-bzip2=/usr/local/ --enable-tiger --enable-key-cache=8192 --enable-large-key

    make

    make install

    make check

    ...and you may freely copy and paste it into Notepad2, where you will see, if you have "word wrap" function disabled, that the string beginning with "./configure" consists of just one line, as it should be, and where all the parameters are separated by one single space.

    Then be sure that Line Endings are set to UNIX (LF), and save it happily in your `build folder'.

    Here, the parameter...

     --enable-tiger
    
    ...enables the TIGER192 hash algorithm to be compiled into the executable code, since without this parameter all the TIGER192 modifications, although now present in the source code files, will be ignored and thus not compiled.

    The parameter...

     --enable-large-key
    
    ...enables generation of an RSA key up to 8192 bits rather than the default of 4096 bits. Without this parameter the original routine of generation of the key is used, and the modified routine is ignored and thus not compiled.

    The parameter...

     --enable-key-cache=8192
    
    ...relates neither to TIGER192 nor Large-Key Support, but is changing the default key cache size from 4092 bytes to 8192 bytes. With a large(r) key-ring this makes possible faster access to the keys.  

     

    At this point, with having all of the mentioned done fine, we are ready for compiling, so we start Cygwin, type in...

    cd /usr/src/4136
    

    ...then...

    ./prep.sh && ./build_gpg.sh
    

    ...and the compiling process starts.  

     

     

     

     

     

    How to compile CVS versions of GnuPG, with and without TIGER192
    2. Compiling in Cygwin/MinGW32
    Page 2 of 3
  • pgp-signed-html.gif, 2.586 B

     
    -- 
    The Blueness [\gpgcvs\index.html]
    Maintained by
    ~blueness~
    
    
    060731