Alon Bar-Lev | 1 Nov 2008 20:18
Picon
Gravatar

Re: [PATCH] aespipe - fix build issues

On Saturday 01 November 2008, Jari Ruusu wrote:
> Jari Ruusu wrote:
> > Alon Bar-Lev wrote:
> > > So if you don't like to add automake, will you consider accepting
> > > another patch that adds install-strip target?
> > 
> > Yes, send a patch.
> 
> I added that already. I had to drop that aespipe dependency from install and
> install-strip targets. Because this didn't work OK:
> 
>     make x86
>     make install
> 
> Your version insisted on rebuilding C language versions of aes.c and md5.c
> 

For the install-strip, I think it is incorrect as it won't work using a cross compile and if other make is used.
Please consider the following patch.

I also added some more quotes and use the AC_GNU_SOURCE AC_SYS_LARGEFILE autoconf macros.

I did not know that you should make x86 for optimize x86, will you consider a patch to autoconf
so that it will detect this automatically?

Alon.

---

diff -urNp aespipe-v2.3d/configure.ac aespipe-v2.3d.new/configure.ac
(Continue reading)

Alon Bar-Lev | 1 Nov 2008 21:28
Picon
Gravatar

Re: [PATCH] aespipe - fix build issues

On Saturday 01 November 2008, Jari Ruusu wrote:
> > I did not know that you should make x86 for optimize x86, will you
> > consider a patch to autoconf so that it will detect this automatically?
> 
> At least I will seriously look at it.
> 
> Long time ago I came to conclusion that doing that portably is very
> difficult. So, I left that decision to whoever calls make.

OK... here it is.

It uses AC_CANONICAL_HOST and as you don't use automake you must
manually copy the config.guess and config.sub files from gnuconfig to the
source tree.

You can find latest versions at [1] git repository, or at your distribution at
/usr/share/gnuconfig or similar.

You should also touch install-sh at source directory, as it is automatically pulled
but we don't use it.

automake has still few advantages ("make dist", "make distcheck", be able to use
BSD compliant install and installing all required dependencies in tarball).

I still think that a automake package is preferable in this case.

Alon.

[1] http://savannah.gnu.org/projects/config

(Continue reading)

Jari Ruusu | 2 Nov 2008 10:17
Picon

Re: [PATCH] aespipe - fix build issues

Jari Ruusu wrote:
> My current version is below. This patch does not include changes to
> generated ./configure script, so anyone applying this patch must also run
> autoconf command afterwards.

New version below. I fixed some portability issues.

-- 
Jari Ruusu  1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9  DB 1D EB E3 24 0E A9 DD

--- ../aespipe-v2.3e/Makefile.in	2007-02-18 11:26:23.000000000 +0200
+++ ./Makefile.in	2008-11-02 10:35:46.000000000 +0200
 <at>  <at>  -1,16 +1,19  <at>  <at> 
 #
 #  Makefile.in
 #
-#  Written by Jari Ruusu, February 18 2007
+#  Written by Jari Ruusu, November 2 2008
 #
-#  Copyright 2002-2007 by Jari Ruusu.
+#  Copyright 2002-2008 by Jari Ruusu.
 #  Redistribution of this file is permitted under the GNU Public License.
 #

-CC =  <at> CC <at>   <at> CFLAGS <at>   <at> DEFS <at>  -D_GNU_SOURCE=1 -D_FILE_OFFSET_BITS=64
+CC =  <at> CC <at>   <at> CPPFLAGS <at>   <at> CFLAGS <at>   <at> DEFS <at> 
 LINK =  <at> CC <at>   <at> LDFLAGS <at> 
+STRIP =  <at> STRIP <at> 
 prefix =  <at> prefix <at> 
 exec_prefix =  <at> exec_prefix <at> 
(Continue reading)

Alon Bar-Lev | 2 Nov 2008 12:08
Picon
Gravatar

Re: [PATCH] aespipe - fix build issues

Hello,

1. What you are doing with Makefile to remove escape is ugly! and
highly none standard.
2. I lost you... Can you please send full configure.ac and Makefile.in
3. Please don't strip in working directory, as subsequent make install
without strip will be affected.
4. I believe that users (including myself) expect that autoconf
packages will not require special targets to build and install.
"./configure && make install" should be sufficient and perform all
required detection. So extra effort should be invested n order to
detect optimization required. I can test for the assembly success if
you like.
5. I don't want to bother you anymore regarding automake... but it
will make the whole think much simpler.

Thank you,
Alon.

On 11/2/08, Jari Ruusu <jariruusu <at> users.sourceforge.net> wrote:
> Jari Ruusu wrote:
>  > My current version is below. This patch does not include changes to
>  > generated ./configure script, so anyone applying this patch must also run
>  > autoconf command afterwards.
>
>
> New version below. I fixed some portability issues.
>
>
>  --
(Continue reading)

Jari Ruusu | 2 Nov 2008 18:23
Picon

Re: [PATCH] aespipe - fix build issues

Alon Bar-Lev wrote:
> 1. What you are doing with Makefile to remove escape is ugly! and
> highly none standard.

I am not removing escapes, I am changing " " to "\ " in srcdir variable.

When I saw you sprinkling quotes around variables containing path names, I
figured that you are trying to make it work with path names that have spaces
in them. Ok, fine. I actually tested it with srcdir having spaces. Here is
what I learned: configure script created using autoconf-2.61, which is the
default in my workstation, created script that failed with spaces in srcdir.
Installed newer autoconf-2.63, which appears to be the latest released one,
created configure script that runs ok, but make chokes on source
dependencies that have spaces. Thus the ugly "massaging" of Makefile srcdir
variable.

Try building aespipe so that:

"/tmp/ 1 " is the source directory
"/tmp/ 2 " is the build directory
"/tmp/ 3 " is the installation root directory

$ cd "/tmp/ 2 "
$ "/tmp/ 1 /configure" && make install DESTDIR="/tmp/ 3 "
$ make tests

Try that using a "standard" srcdir definition in Makefile.in, as in:

srcdir =  <at> srcdir <at> 

(Continue reading)

Alon Bar-Lev | 3 Nov 2008 07:49
Picon
Gravatar

Re: [PATCH] aespipe - fix build issues


In the mean time, now that I know that I need to build a special target...
There is executable stack issue...
Please consider to fix it.

Thanks!

---

diff -urNp aespipe-v2.3d/aes-amd64.S aespipe-v2.3d.stack/aes-amd64.S
--- aespipe-v2.3d/aes-amd64.S	2004-06-12 17:31:41.000000000 +0300
+++ aespipe-v2.3d.stack/aes-amd64.S	2008-11-03 08:41:56.000000000 +0200
 <at>  <at>  -891,3 +891,7  <at>  <at>  aes_im_tab:
 	im_data5(v3)
 	im_data6(v3)
 	im_data7(v3)
+
+#if defined(__linux__) && defined(__ELF__)
+.section .note.GNU-stack,"",%progbits
+#endif
diff -urNp aespipe-v2.3d/aes-x86.S aespipe-v2.3d.stack/aes-x86.S
--- aespipe-v2.3d/aes-x86.S	2006-02-22 14:22:34.000000000 +0200
+++ aespipe-v2.3d.stack/aes-x86.S	2008-11-03 08:42:01.000000000 +0200
 <at>  <at>  -921,3 +921,7  <at>  <at>  aes_im_tab:
 	im_data5(v3)
 	im_data6(v3)
 	im_data7(v3)
+
+#if defined(__linux__) && defined(__ELF__)
+.section .note.GNU-stack,"",%progbits
(Continue reading)

Jari Ruusu | 3 Nov 2008 17:49
Picon

Re: [PATCH] aespipe - fix build issues

Alon Bar-Lev wrote:
> In the mean time, now that I know that I need to build a special target...
> There is executable stack issue...
> Please consider to fix it.

I merged it. But it choked on older versions of GNU binutils. I modified it
so that it is not enabled on binutils older than 2.17 . Why 2.17? Because
that is what I have on my workstation, and it worked ok there. If you or
someone else cares to figure out what binutils version is oldest one that
doesn't choke on such note.GNU-stack section, then please tell me so I can
adjust the correct version limit.

Diff of my current version against unmodified aespipe-v2.3e is attached.
I didn't include generated ./configure script.

This version autodetects x86/amd64 if running on GNU toolchain.

--

-- 
Jari Ruusu  1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9  DB 1D EB E3 24 0E A9 DD
Attachment (aespipe-v2.3e-20081103.diff.bz2): application/octet-stream, 3581 bytes
Alon Bar-Lev | 3 Nov 2008 20:37
Picon
Gravatar

Re: [PATCH] aespipe - fix build issues

Great!
Thank you for your efforts.
A few comments:

1.
+install-strip:
+	if ! test -f aespipe ; then $(MAKE) all ; fi
+	$(MAKE) INSTALL_STRIP=$(STRIP) install

Why do you need make all here? The make install will do this, right?

2. You cannot use uname at configure, as it won't work with you cross compile.
This is what started this thread... :)
The config.sub, config.guess are efforts just like loop-aes in crypto,
I don't understand why you don't want to use their knowledge.

3. You cannot use as... As it would fail cross compile.

I Also fixed some more autoconf issues, please review.

Alon.

On 11/3/08, Jari Ruusu <jariruusu <at> users.sourceforge.net> wrote:
> Alon Bar-Lev wrote:
>  > In the mean time, now that I know that I need to build a special target...
>  > There is executable stack issue...
>  > Please consider to fix it.
>
>
> I merged it. But it choked on older versions of GNU binutils. I modified it
(Continue reading)

Alon Bar-Lev | 4 Nov 2008 18:46
Picon
Gravatar

Re: [PATCH] aespipe - fix build issues

Opps... Forgot the patch.

On 11/4/08, Alon Bar-Lev <alon.barlev <at> gmail.com> wrote:
> Hello again,
>
>  The attached patch replaces the previous one.
>  I spent some time and backported some of automake stuff including VPATH.
>  I also detect all used progs, including md5* etc.
>  Modified the u_int32_t and u_int64_t detection, BTW: why don't you use stdint.h?
>  Fixed some more autoconf issues when compiling stuff.
>  Well... many autoconf modifications...
>  Including detection of amd64 and i386 assembly using the compiler.
>  Also added template rules to Makefile I think it is now much simpler.
>
>  I am sorry for the large modification... But I think this is about
>  that... All we need is to test it and see if I got it right.
>
>  I checked this using i686-pc-linux-gnu host and x86_64-pc-linux-gnu
>  cross compile.
>
>  Please review,
>
> Alon.
>
>
>  On 11/3/08, Alon Bar-Lev <alon.barlev <at> gmail.com> wrote:
>  > Great!
>  >  Thank you for your efforts.
>  >  A few comments:
>  >
(Continue reading)

Alon Bar-Lev | 4 Nov 2008 20:36
Picon
Gravatar

Re: [PATCH] aespipe - fix build issues

On 11/4/08, Jari Ruusu <jariruusu <at> users.sourceforge.net> wrote:
>  - These make targets must stay:
>     make aespipe    (always C language regardless of auto-detection)
>     make x86        (always x86 asm regardless of auto-detection)
>     make amd64      (always amd64 asm regardless of auto-detection)

OK, I will make them available again once all the other is setup.
The problem is that it always link the project if you make x86...
Can the aespipe be converted to generic so we have sane rules?
I took another approach please have a look at build6.

>  - Your Makefile is shorter, but it is less hackable. When coding and
>   debugging problems, I change compile options for each file individually.
>   Some get -S or -DFOO options and such, and then I look at generated code.
>   Having all sources under one or two "generic" rules is pure PITA. Remember
>   when I said that I don't like automake with its un-hackable Makefile? You
>   are trying to make it unhackable. Not good, IMO.

I disagree... The shorter makefile is much clearer... If there is a
need for customization a special rule may be written.
But it is your project... :)
As you merged the build4, it is difficult to know in which state you are.
The attached is since your last snapshot.
I hope it is more appropriate. I changed the "aespipe" to "generic" so
that the rules will be consistant.

>  - Other improvements look ok. I will look at it more closely tomorrow.

Thank you,
Alon.
(Continue reading)


Gmane