Hello again.

Wondering if anyone can give me some guidance/direction on compiling applications for Linux since there doesn't seem to be much in the way of recent builds available. I had a look around the repository recently and experimented with the _autosetup and configure scripts but without much success. There doesn't seem to be much in the way of documentation (I could just be missing it) and can only guess what the directory structure means.

I understand not everything may work for Linux given the focus on Windows builds but I do know petri33 had managed to get compilation working for his own system, so it's definitely possible.

Edit:
Specifically, I'm looking for the following builds on x64 kernel:

• AstroPulse for ATI/AMD
  
• AstroPulse for NV
  
• AstroPulse for CPU (SSE4.1 or under)
  
• MultiBeam for ATI/AMD
  
• MultiBeam for NV (x41zc build for Fermi/cuda42)
  
• MultiBeam for CPU (one build for SSE4.1 or under, one for AVX)
  

---

Soli Deo Gloria

Hello, Multibeam for x41zc (CUDA) on Linux x64 [after cuda toolkit gymnastics[ should be straightforward normal autotools sequence, though I'd recommend liasing with petri33 if you want some trial faster chirps.

[Others here can likely give dedicated command lines]

The svn repository location IIRC is presented in the readmes for x41zc.

If you need to know more about *nix Autotools setup, we can probably help there too. Always bear in mind that here X stands for 'eXperimental', and that piling on constructive suggestions is welcome.

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

Hi,
I will help if I can.

1) I did get the source using svn from the ".....branches/sah_v7_opt"

2) I have gcc 3.8

3) I have made "Configure.cmd" files for MB, MB GPU, AP and AP GPU to pass all needed configuration parameters

4) cd sah_v7_opt/

Then I think (for Nvidia) ...

5) directory AP is for AP GPU and CPU

6) directory AKv8 is atleast for MB CPU

7) directory Xbranch is for MB GPU

There are those examples of configure lines that can be easily modified to working script files, i.e. in AP/client I have:

linux1 client # cat ConfigureGPU.cmd
#!/bin/bash

./configure  --enable-bitness=64 --build=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-boinc-platform=x86_64-pc-linux-gnu --enable-static --enable-static-client --enable-avx --disable-shared --disable-graphics --enable-intrinsics CXXFLAGS=" -O3 -Ofast -march=corei7-avx  -mtune=corei7-avx -msse -msse2 --param inline-unit-growth=3000" CPPFLAGS="-DTWIN_FFA -DUSE_FFTW -DUSE_AVX -DUSE_I386_XEON_OPTIMIZATIONS -DUSE_CONVERSION_OPT -DUSE_INCREASED_PRECISION -DSMALL_CHIRP_TABLE  -DPCHIRP -DUSE_OPENCL -DOPENCL_WRITE -DCOMBINED_DECHIRP_KERNEL -DOCL_ZERO_COPY -DAP_CLIENT -DUSE_OPENCL_NV  -I/usr/local/cuda-5.5/include "  LIBS=" -L/usr/lib64 -lOpenCL " LDFLAGS=" -static-libgcc -static-libstdc++" BOINCDIR=" ../../../boinc" SETI_BOINC_DIR=" ../../AKv8"

and

linux1 client # cat ConfigureCPU.cmd

./configure --enable-bitness=64 --build=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-boinc-platform=x86_64-pc-linux-gnu --enable-static --enable-static-client --enable-sse2 --disable-shared --disable-graphics --enable-intrinsics CXXFLAGS=" -O3 -march=corei7-avx -mtune=corei7-avx -msse2 --param inline-unit-growth=3000 " CPPFLAGS=" -march=corei7-avx -O3 -Ofast -frerun-cse-after-loop -fgcse -fgcse-after-reload -fgcse-lm -fgcse-las -fgcse-sm -faggressive-loop-optimizations -fexpensive-optimizations -fschedule-insns -fschedule-insns2 -fmove-loop-invariants -fselective-scheduling -fvect-cost-model -fsection-anchors -fsched-stalled-insns-dep -fsched-stalled-insns -fsched-spec-load -fsched-spec -fsched-pressure -freorder-functions -freorder-blocks -frename-registers -fregmove -fprefetch-loop-arrays -fpredictive-commoning -fpeephole -foptimize-register-move -fomit-frame-pointer -DUSE_FFTW -DUSE_CONVERSION_OPT -DUSE_INCREASED_PRECISION -DSMALL_CHIRP_TABLE -DUSE_AVX -DAP_CLIENT" LIBS=" -L/usr/lib64 " LDFLAGS=" -static-libgcc -static-libstdc++" BOINCDIR=" ~petri/boinc" SETI_BOINC_DIR=" ../../AKv8"

and for MB in AKv8 I have

linux1 AKv8 # cat Configure.cmd
#For a Linux 64bit sse2-app use for example :

./configure --disable-server --disable-graphics --disable-shared --enable-bitness=64 --enable-client --enable-static-client --enable-dependency-tracking --enable-static --enable-avx --enable-comoptions --enable-intrinsics --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --with-boinc-platform=x86_64-pc-linux-gnu CXXFLAGS="-Ofast -O3 -fexceptions -fno-rounding-math -fno-signaling-nans -frerun-cse-after-loop -fgcse -fgcse-after-reload -fgcse-lm -fgcse-las -fgcse-sm -faggressive-loop-optimizations -fexpensive-optimizations -fschedule-insns -fschedule-insns2 -fmove-loop-invariants -fselective-scheduling -fvect-cost-model -fsection-anchors -fsched-stalled-insns-dep -fsched-stalled-insns -fsched-spec-load -fsched-spec -fsched-pressure -freorder-functions -freorder-blocks -frename-registers -fregmove -fprefetch-loop-arrays -fpredictive-commoning -fpeephole -foptimize-register-move -fomit-frame-pointer -fcx-limited-range -fno-math-errno  -fno-trapping-math -march=corei7-avx  -funroll-loops -mtune=corei7-avx -mpreferred-stack-boundary=8 --param inline-unit-growth=3000  -fprofile-generate -fprofile-correction " CPPFLAGS=" -DUSE_JSPF -DUSE_FFTW -DUSE_I386_OPTIMIZATIONS -DUSE_TRANSPOSED_POT -DFFTOUT -DNDEBUG -DUSE_PALIGNED_PULSE -DSETI7 -DUSE_AVX " LDFLAGS=" -L/usr/lib64 -static -static-libgcc -static-libstdc++" BOINCDIR=" ../../../boinc" 

and in Xbranch I have

 
linux1 Xbranch # cat Configure55.cmd
!/bin/sh
#export CFLAGS=-msse2
./configure BOINCDIR=/home/petri/boinc CFLAGS='-O3 -march=corei7-avx -Ofast -funroll-loops -mtune=corei7-avx -mpreferred-stack-boundary=8 -fexceptions -fno-rounding-math -fno-signaling-nans -frerun-cse-after-loop -fgcse -fgcse-after-reload -fgcse-lm -fgcse-las -fgcse-sm -faggressive-loop-optimizations -fexpensive-optimizations -fschedule-insns -fschedule-insns2 -fmove-loop-invariants -fselective-scheduling -fvect-cost-model -fsection-anchors -fsched-stalled-insns-dep -fsched-stalled-insns -fsched-spec-load -fsched-spec -fsched-pressure -freorder-functions -freorder-blocks -frename-registers -fregmove -fprefetch-loop-arrays -fpredictive-commoning -fpeephole -foptimize-register-move -fomit-frame-pointer -fcx-limited-range -fno-math-errno  -fno-trapping-math --param inline-unit-growth=3000 -DPINNED -DNDEBUG -DHAVE_STRCASECMP -DSETI7 -DUSE_I386_OPTIMIZATIONS -DUSE_CUDA -fpeel-loops -funroll-loops -fweb -I/usr/local/cuda-5.5/include -L/lib/x86_64-linux-gnu/ ' LIBS="/lib/x86_64-linux-gnu/libm.so.6 /usr/lib/x86_64-linux-gnu/libc.so /usr/local/cuda-6.0/lib64/libcufftw.so /usr/local/cuda-6.0/lib64/libcufft.so /usr/lib/x86_64-linux-gnu/libpthread.so /usr/lib/gcc/x86_64-linux-gnu/4.6/libstdc++.so /lib/x86_64-linux-gnu/libm.so.6" 

But ... A general warning: I think there are more suitable versions available. These files have evolved with my machine and differ a lot from their original counterparts. These may not be optimal or even correct although they work for me.

Please ask if you need help and I or anybody else with some experience will answer. I think I live in the oppsite side of the globe so we may not be on line simultaneously. Messaging will be slow. I'll check the computer regularly.

When you get compilation errors you could post them here and I'm sure someone can help.

--
Petri

---

To overcome Heisenbergs:
"You can't always get what you want / but if you try sometimes you just might find / you get what you need." -- Rolling Stones

Thank you both.

[after cuda toolkit gymnastics[

Oh dear, that sounds painful. At the moment I see nvidia-cuda-dev and nvidia-cuda-toolkit packages available - I'll give them a try when I'm back home.

If you need to know more about *nix Autotools setup, we can probably help there too.

I think I'd appreciate help here. Are these autotools specific to this project or are they a general Linux thing? I did a bit of Unix-based development in university, but the vast majority of development in my work has been in Windows environments so there's obviously plenty I need to learn.

6) directory AKv8 is atleast for MB CPU

7) directory Xbranch is for MB GPU

Yep, I had another look and it seems AKv8/ is for CPU and GPU/OpenCL, while Xbranch is for CUDA.

There are those examples of configure lines that can be easily modified to working script files

Thanks for these, this is the sort of starting point I was looking for. I'll experiment with them after work.

A general warning: I think there are more suitable versions available.

I know English isn't your native language, but what do you mean by more suitable? I realise what works for you may not be what's best for me, hence my need to experiment.

Thanks again.

---

Soli Deo Gloria

More suitable = better, shorter, with no experimental stuff, no hard coded paths, ...

---

To overcome Heisenbergs:
"You can't always get what you want / but if you try sometimes you just might find / you get what you need." -- Rolling Stones

Yeah the 'Gymnastics' just refers to the usual Cuda toolkit install procedure, from driver install through building samples to test your environment.

The 'autotools stuff' I'm referring to is the pretty 'standard' *nix+GPL sequence. usually performed after checking out/extracting code, similar (but never idetical to):
./_autosetup
sh .configure [ lots of options ] --> sometimes executable without specifying sh
make clean
make

IIRC I made most of the 'weird' configure options fairly standard widely compatible defaults, so you might get away with far fewer specialised options (as I gather Perti33 was hinting)

x64 should really be autodetected, so if appropriate Cuda toolkit links are setup, boinc repository clone's in 'someplace, probably just a configure line with as few options as --enable-sse2 BOINCDIR=/your/boinc/checkout, and possibly a Cuda version override should be usable

for tweakage, .configure --help , IIRC should show an extensive list of basic and more esoteric options, though for our non-Leet get it going purposes most won't be relevant simply because the vast majority of the code runs on GPU, as opposed to CPU [Other apps vary in that regard]

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

Let me know if you're successful, Guy - maybe you can warn me about any potential pitfalls I need to watch out for.

Thanks, petri, I see some of the compiler switches being redundant, but maybe that's because you're using gcc 3.8 whereas my distribution is offering 4.8.

Thanks, jason, I wasn't aware of the autotools convention, I only remember learning about makefiles at uni. I suppose I'm spoilt by modern graphical IDEs, although I'm no stranger to the command line interface. At least I know I was on the right track before with the _autosetup and configure scripts.

Edit: I installed nvidia-cuda-toolkit which was quite large so hopefully that's all that's needed. I'm focusing on the non-CUDA builds for the time being.

I'm making progress - I didn't realise last time that I only had gcc installed when g++ was necessary as well. I also have a copy of the boinc source on the system that's doing the building now (had a copy already but wasn't in a suitable location). My current blocker is the configure script's complaint about a 'sed that does not truncate output'. There's a sed package already installed, but not the kind the script wants, it seems. I can't find any hint as to what sed is needed, looking at the script code.

checking for sed... /bin/sed
./configure: line 6345: AC_LIBTOOL_DLOPEN: command not found
./configure: line 6346: AC_LIBTOOL_WIN32_DLL: command not found
./configure: line 6353: LTOPTIONS_VERSION: command not found
./configure: line 6354: LTSUGAR_VERSION: command not found
./configure: line 6355: LTVERSION_VERSION: command not found
./configure: line 6356: LTOBSOLETE_VERSION: command not found
checking for a sed that does not truncate output... (cached) /bin/sed
./configure: line 6431: syntax error near unexpected token `lt_decl_varnames,'
./configure: line 6431: `lt_if_append_uniq(lt_decl_varnames, SED, , ,'

Sorry for being such a newbie and I appreciate everyone's efforts - both in development and in helping me get through the compilation process!

---

Soli Deo Gloria

Is that the generic toolkit from NV directly? I see the system requirements stating Fedora 19 specifically as well, but I'm using the package from my distribution which is only for CUDA 5.5.

Well, hope you get through it!

---

Soli Deo Gloria

Is that the generic toolkit from NV directly? I see the system requirements stating Fedora 19 specifically as well, but I'm using the package from my distribution which is only for CUDA 5.5.

Well, hope you get through it!

5.5 will do fine for now ;) most of our code is fairly low level so using generic Cuda, which even newer 750tis etc will cause the code to rebuild in the drivers on first run (cuda compiler gencode options are specified for SM arch 3.x PTX, and are forward compatible).


Some Cuda 6 Runtime features will come into play once some heavy driver latency issues are mastered, and by then I'd expect both the very recent Linux and Mac OSX Mavericks situations to have radically improved (a bit of a weird state right now IMO).

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

Some Cuda 6 Runtime features will come into play once some heavy driver latency issues are mastered, and by then I'd expect both the very recent Linux and Mac OSX Mavericks situations to have radically improved (a bit of a weird state right now IMO).

What time frame do you thing we're looking at here?
12, 24, 36 months?

---

Grant
Darwin NT

Some Cuda 6 Runtime features will come into play once some heavy driver latency issues are mastered, and by then I'd expect both the very recent Linux and Mac OSX Mavericks situations to have radically improved (a bit of a weird state right now IMO).

What time frame do you thing we're looking at here?
12, 24, 36 months?

Going by prior patterns, my guess is with Cuda 6.5 and full-sized Maxwell releases or a bit before. Not basing that guess on anything more tangible than history though. NV are routinely tightlipped backstage for sure.

750ti having been apparently pretty successful as a test for the architecture and (Cuda 6) software tools, so I'd further guess timelines would depend on the silicon fabs 20nM chip capacity/yields.

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

750ti having been apparently pretty successful as a test for the architecture and (Cuda 6) software tools, so I'd further guess timelines would depend on the silicon fabs 20nM chip capacity/yields.

So we're probably looking at 6-12 months at this stage, if things go well.

TSMC are having continuing yield/production issues with their 20nM process. AMD & Nvidia were meant to be releasing 20nM products this Dec but TSMC's production problems have appeared to force Nvidia to re-design the higher end Maxwell hardware to use the existing 28nM process. Given the specs of the very highend cards, they may not even be possible using the current process- or if done using the current process their performance will be considerably crippled due to power/thermal issues.
Unless Nvidia makes use of Intel's 20nM production availability & can do so quickly, 20nM AMD/Nvidia products probably won't appear till mid next year, maybe.


EDIT- considering how little power my 28Nm GTX 750Ti's use, the 20nM based hardware will have down right amazing performance per watt figures.

---

Grant
Darwin NT

I only mentioned mine was 5.5 because Guy said he was having trouble with 6.

So the original topic doesn't get lost - can anyone help me with the following error messages, please?

checking for sed... /bin/sed
./configure: line 6345: AC_LIBTOOL_DLOPEN: command not found
./configure: line 6346: AC_LIBTOOL_WIN32_DLL: command not found
./configure: line 6353: LTOPTIONS_VERSION: command not found
./configure: line 6354: LTSUGAR_VERSION: command not found
./configure: line 6355: LTVERSION_VERSION: command not found
./configure: line 6356: LTOBSOLETE_VERSION: command not found
checking for a sed that does not truncate output... (cached) /bin/sed
./configure: line 6431: syntax error near unexpected token `lt_decl_varnames,'
./configure: line 6431: `lt_if_append_uniq(lt_decl_varnames, SED, , ,'

---

Soli Deo Gloria

I thought I'd be able to bully my way through the compilation process with stubborn persistence, but I find myself getting stuck. Still stuck in the configure stage for AP, but I got to the compilation stage for MB with the following errors:

MB CPU/OCL:

/usr/bin/ld: cannot find -lboinc_api
/usr/bin/ld: cannot find -lboinc
collect2: error: ld returned 1 exit status
make[2]: *** [seti_boinc] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

All I can tell is this is something to do with the BOINC API - I have boinc and sah_v7_opt source directories at the same directory level. Am I supposed to compile or point to BOINC libraries manually?

MB CUDA:

analyzeFuncs.cpp:101:33: note: #pragma message: ----ooura----
 #pragma message ("----ooura----")
                                 ^
analyzeFuncs.cpp: In function ‘void initCudaDevice()’:
analyzeFuncs.cpp:345:13: error: ‘sleep’ was not declared in this scope
      sleep(5);
             ^
analyzeFuncs.cpp: In function ‘int seti_analyze(ANALYSIS_STATE&)’:
analyzeFuncs.cpp:819:13: error: ‘sleep’ was not declared in this scope
      sleep(5);
             ^
In file included from analyzeFuncs.cpp:73:0:
cuda/cudaAcc_utilities.h:89:66: error: ‘cudaAcc_SafeCall_No_Sync_wExit’ cannot be used as a function
   cudaAcc_SafeCall_No_Sync_wExit( err, #_call, __FILE__, __LINE__);     \
                                                                  ^
analyzeFuncs.cpp:978:6: note: in expansion of macro ‘CUDA_ACC_SAFE_CALL’
      CUDA_ACC_SAFE_CALL((CUDASYNC),true); // Wait for first chirp to finish now that cufft plans are done
      ^
make[2]: *** [seti_cuda-analyzeFuncs.o] Error 1
make[2]: Leaving directory `/home/x/sah_v7_opt/Xbranch/client'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/x/sah_v7_opt/Xbranch'
make: *** [all] Error 2

I'm... not really sure what's going on here at all. For the sleep() error, I read that gcc stopped including unistd.h with gcc 4.7, so I tried to define HAVE_UNISTD_H but the error still crops up. I really don't have any idea why the CUDA macro expansion is failing either.

---

Soli Deo Gloria

yep for the CPU app boincapi part, you'll likely need to go into the boinc repository checkout you made (?), do its _autsetup, .configure, make clean, make. Options you'll need will include --disable-server --disable-client and probably --enable-shared-libs, [ or something like that, though I've forgotten whether after that for the Cuda variant I used static or shared libs, so you can make both]

For the sleep issue inside the Cuda build it looks like my thread safe exit handling might be active (?) . Needs reexamination after whatever configure's choking on about autotools is resolved. Part of Autosetup/confogure's job is usually to locate sleep() somewhere on the system, and fix up makefiles as appropriate.

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

Thanks for that. Hmm, more compilation. I tried doing so for the boinc source and looks like something is not getting generated properly:

make[2]: Entering directory `/home/x/boinc/api'
  CXX      boinc_api.lo
cc1plus: fatal error: .libs/boinc_api.d: No such file or directory
compilation terminated.
make[2]: *** [boinc_api.lo] Error 1
make[2]: Leaving directory `/home/x/boinc/api'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/x/boinc'
make: *** [all] Error 2

Regarding the sleep() issue for MB CUDA, configure seemed to complete okay - this is the compilation stage that's complaining. I had a look at the configure script and couldn't find anything relating to sleep calls or header includes.

---

Soli Deo Gloria

Thanks for that. Hmm, more compilation. I tried doing so for the boinc source and looks like something is not getting generated properly:

make[2]: Entering directory `/home/x/boinc/api'
  CXX      boinc_api.lo
cc1plus: fatal error: .libs/boinc_api.d: No such file or directory
compilation terminated.
make[2]: *** [boinc_api.lo] Error 1
make[2]: Leaving directory `/home/x/boinc/api'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/x/boinc'
make: *** [all] Error 2

Regarding the sleep() issue for MB CUDA, configure seemed to complete okay - this is the compilation stage that's complaining. I had a look at the configure script and couldn't find anything relating to sleep calls or header includes.

Alright, got me almost woken up enough to fire up the Linux host a bit later after locating the 680 to put in it. It's under a pile of empty beer cans I think :S. Have to go do some shopping first, and no guarantee I won't be wrestling weird Linux things myself, but could be a lucky evening, who knows.

Once it's up and running I'll have to check which macros/functions are using that aleep(), which are part of the thread-safe exit handling I inserted. If they've been moving functions around then wherever that's defined will likely need to be hooked up properly to autotools macros.

I'll checkout an updated boinc repo as well and see if that's broken. If so I'll just direct you to a version I know works.

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.