bench_elimination.c:5:10: fatal error: 'cpucycles.h' file not found

[Sean Weaver]

I'm trying to install the latest M4RI but getting an error about a missing file. Here is what I'm doing and the error I'm getting. Any help would be appreciated.

What I'm doing:

mkdir -p local
cd local
git clone https://bitbucket.org/malb/m4ri.git
cd m4ri
autoreconf --install
./configure --disable-png --enable-thread-safe --prefix=`pwd`/../
make
make install

The error:

...
libtool: link: ar cru .libs/libm4ri.a  m4ri/brilliantrussian.o m4ri/misc.o m4ri/mzd.o m4ri/graycode.o m4ri/strassen.o m4ri/mzp.o m4ri/triangular.o m4ri/triangular_russian.o m4ri/ple.o m4ri/ple_russian.o m4ri/solve.o m4ri/echelonform.o m4ri/mmc.o m4ri/debug_dump.o m4ri/io.o m4ri/djb.o m4ri/mp.o
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: .libs/libm4ri.a(debug_dump.o) has no symbols
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: .libs/libm4ri.a(mp.o) has no symbols
libtool: link: ranlib .libs/libm4ri.a
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: .libs/libm4ri.a(debug_dump.o) has no symbols
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: .libs/libm4ri.a(mp.o) has no symbols
libtool: link: ( cd ".libs" && rm -f "libm4ri.la" && ln -s "../libm4ri.la" "libm4ri.la" )
Making all in tests
make[3]: Nothing to be done for `all'.
Making all in bench
(if [ . != . ]; then \
        cp -r ./cpucycles-20060326 .; \
            chmod +w -R cpucycles-20060326/; \
         fi; \
         cd cpucycles-20060326; \
         sh do; \
         cp cpucycles.o ..; \
         cp cpucycles.h ..; \
         cd ..; \
     if [ . != . ]; then \
        rm -r cpucycles-20060326; \
         fi)
cp: cpucycles.o: No such file or directory
cp: cpucycles.h: No such file or directory
/Applications/Xcode.app/Contents/Developer/usr/bin/make  all-am
gcc -DHAVE_CONFIG_H -I. -I../m4ri    -I./.. -I./.. -D_XOPEN_SOURCE=600 -g -O2    -g -O2 -MT bench_elimination.o -MD -MP -MF .deps/bench_elimination.Tpo -c -o bench_elimination.o bench_elimination.c
bench_elimination.c:5:10: fatal error: 'cpucycles.h' file not found
#include "cpucycles.h"
         ^
1 error generated.

[Martin Albrecht]

Strange, I can't reproduce this behaviour on two systems (Linux and OS X Yosemite Vagrant).

What is the output of doing "sh do" on your system in the cpucycles-20060326 directory?

[Martin Albrecht]

Mhh, maybe those warnings cause it to fail. Can you try ti replace the line

main()

with

int main()

to see if that fixes the issue?

[Martin Albrecht]

Okay, most of those errors are expected. However,

===== Trying powerpcmacos.c with gcc...
t[0] = -395646954051994
t[1] = -395646954052106
cpucycles_persecond() = -1694967296

is not expected (this goes through on my box). I don't know why that's happening, though, i.e. if that's a problem with the machine or with the code.

[Martin Albrecht]

I've disabled building bench by default. That is, you should be able to build everything else now without errors. Still, it would be good to figure this one out.

[Sean Weaver]

Thanks that is a good workaround for me right now.

In trying to figure out what is going wrong, do you think it could be due to the use of mach_absolute_time? I see long long is being used where the function returns a uint64_t. Really, if cpucycles_powerpcmacos and cpucycles_powerpcmacos_persecond return an unsigned integer of any large enough bit-width, this exact problem would not be happening...but I don't know if this is the correct fix.

I found more info on correct use of mach_absolute_time here: http://stackoverflow.com/questions/23378063/how-can-i-use-mach-absolute-time-without-overflowing

[Martin Albrecht]

That sounds like a plausible explanation (btw. we didn't write this code, Dan Bernstein did), it might make sense to test if this is the issue and then report the bug upstream?

[Sean Weaver]

I am fine with this, but I'm only a user here.

[Charles Bouillaguet]

@malb, what about this one?

[Martin Albrecht]

I think we can close this one.