a test failed

[alexmyczko]

you'll find all output at http://sid.ethz.ch/debian/form/form_4.2.0-1_i386.build

[tueda]

Issue197, Transform-mulargs_1: the example input is not sutable for 32-bit systems.
Issue154, OutputOptimization_1: may be real bugs.

The log for ParFORM is really strange:

Check /var/www/debian/form/form-4.2.0/sources/parform
ParFORM 4.2.0 (Jul  6 2017, v4.2.0) 32-bits -1 workers  Run: Mon Jul 10 22:04:00 2017

which looks like MPI is not working properly.

[alexmyczko]

thanks for looking into it! i can test build it on amd64, will post results if it asks to...

[alexmyczko]

The build on amd64 just looks fine: https://people.phys.ethz.ch/~myczko/debian/form/form_4.2.0-1_amd64.build

Have you seen the bugs @Debian?
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=835138
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=853404

[tueda]

I was a bit playing with a 32-bit build on a Docker container by i686/ubuntu on my Windows laptop. There I got failures for Issue197, Transform-mulargs_1 and OutputOptimization_1 with FORM and TFORM, but not for Issue154. Valgrind gave me no errors for Issue154 with vorm.

[tueda]

Here is a Valgrind log for the optimization bug

FORM 4.2.0 (Jul 11 2017, v4.2.0-6-g795bb56) 32-bits  Run: Wed Jul 12 08:37:12 2017
    S x;
    L F = x;
    Format O1;
    P;
    .end

Time =       0.09 sec    Generated terms =          1
               F         Terms in output =          1
                         Bytes used      =         18
==8898== Invalid read of size 4
==8898==    at 0x80BC44D: Optimize (optimize.cc:4585)
==8898==    by 0x812AAC2: WriteAll (sch.c:2500)
==8898==    by 0x807E834: DoExecute (execute.c:838)
==8898==    by 0x80967E2: ExecModule (module.c:274)
==8898==    by 0x80FEADE: PreProcessor (pre.c:962)
==8898==    by 0x8139C23: main (startup.c:1605)
==8898==  Address 0x1d4 is not stack'd, malloc'd or (recently) free'd
==8898==
Program terminating at test.frm Line 4 -->

Somehow cbuf is NULL at optimize.cc:4585.

[tueda]

Now all the tests pass in my environment.

[jodavies]

For the record, I managed to build form within Termux (https://github.com/termux) for Android. I cannot build from the git repo (something to do with autotools or such) but I can build v.4.2.0, and the latest commit's files copied into the v4.2.0 directory.

EDIT: I was able to get autoreconf -i working by adding square brackets around FORM_VERSION on configure.ac:74.

I had to modify tools.c to use <sys/time.h>, gettimeofday instead of <sys/timeb.h>, ftime (doesn't exist in Termux, removed in POSIX 2008), and also install boost-dev for unordered_map etc and also zlib1g-dev. Also I had to change the shell location in a few places in configure to /data/data/com.termux/files/usr/bin/bash.

Here are the test log files, with the latest commit Issue154 fails (just a timeout, it seems), as well as ExtComm_1 (strange environment issue, I guess).

check-v4.2.0.txt
check-git.txt

[tueda]

What was the problem when you didn't remove the square brackets around FORM_VERSION? (at configure.ac:70?) I'm not sure why FORM_VERSION is not quoted: maybe it should be expanded before the expansion of AC_INIT, maybe was with an old version of autoconf, maybe I was just wrong.

[jodavies]

It gave AC_INIT should be called with package and version arguments

[tueda]

Yes, I feel the reason why I removed the square brackets was to force the version number to be expanded before being passed into AC_INIT to avoid such an error... Or maybe you got some error during expanding FORM_VERSION? Do you have cat in your environment??

[jodavies]

Yes I have cat, I am not sure why Test_ExtComm_1 fails. Likely not form's fault...

[jodavies]

Maybe it is helpful to provide the full output:

configure.ac:74: error: AC_INIT should be called with package and version arguments
/data/data/com.termux/files/usr/share/aclocal-1.15/init.m4:29: AM_INIT_AUTOMAKE is expanded from...
configure.ac:74: the top level
autom4te: /data/data/com.termux/files/usr/bin/m4 failed with exit status: 1
aclocal: error: echo failed with exit status: 1
autoreconf: aclocal failed with exit status: 1

autoreconf --version is 2.69, m4 --version is 1.4.18.

I am not suggesting that this environment should be supported, I am just reporting in case any of this is real bugs and not strange environment effects.

[tueda]

If it is not a problem with the environment, probably it should be reproducible in other environments somehow. But I haven't succeeded to reproduce it... I'm wondering if esyscmd (calling the shell from m4) is working correctly or not.

[jodavies]

This could be the problem, esyscmd(`echo foo') in m4 returns nothing.

[tueda]

Resolving the esyscmd problem on the specific system may require non-trivial tricks. Probably we can close this issue for now.