The instructions for heterogenous environments only work if they're all running the same architecture. In my case, I want to other machines in my cluster to compile for me, even if they're on different architectures.

For example, I'm running using an x86_64 distro for development, but the most powerful machine in my cluster runs i686. I ran icecc --build-native on the 32-bit machine, and then use it on my 64-bit machine using:

export ICECC_VERSION=/etc/icecc/native.tar.gz,i686:/etc/icecc/i686.tar.gz

This works fine on WebKit, but not with GStreamer. I'm guessing the difference is that WebKit compiles with -m64 and doesn't use autotools.

I'm guessing I'm not doing this right, but there's very little documentation available. How am I supposed to tell 32-bit machines to cross compile?

I guess that the function "log_info" is not async-signal-safe.

The data type of the variable "local" should be "sig_atomic_t" instead of "bool".

I am getting the below error on Ubuntu 10.04

echo docbook-to-man is missing. Install docbook2x package.

I installed docbook2x and docbook-to-man packages but still I get the below error (around 200 of these)
/usr/share/sgml/docbook/docbook-xml-4.2/docbookx.dtd:112:17:E: "X20AC" is not a function name

I guess icecc support clang because icecc-create-env has --clang option.
If user wants to use both gcc and clang, how ICECC_VERSION should be set?
I guess export ICECC_VERSION=gcc_env.tar.gz,clang_env.tar.gz=clang

Currently, icecc-create-env --clang includes only clang, not clang++ while icecc-create-env --gcc includes gcc as well as g++.

Something isn't right in the way configure --without-man generates makefiles: make attempts to enter the .doc directory and then fails. See output below.

./configure --without-man
make
====snip====
CXX safeguard.o
CXXLD icecc
make[2]: Leaving directory /home/hm68841/icecc/master/icecream-master/client' Making all in doc make[2]: Entering directory/home/hm68841/icecc/master/icecream-master/doc'
make[2]: *** No rule to make target icecc.1', needed byall-am'. Stop.
make[2]: Leaving directory /home/hm68841/icecc/master/icecream-master/doc' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory/home/hm68841/icecc/master/icecream-master'
make: *** [all] Error 2

ICECC_VERSION with dot as first character of the tarball name, for example
.icecc-native-i686.tar.gz, drops the connection of all clients from icecc network that receives that tarball file.

i have some powerful nodes with ipv6 network only. iceccd says nothing in its logs about problems.
The clients are not listed in the scheduler-gui.

What can i do?

The Link to the openSuse binaries is not working.

Following option of gcc 4.8 uses objcopy, but icecc-create-env does not handle objcopy
'cflags': ['-gsplit-dwarf'], 'ldflags': ['-Wl,--gdb-index'],

• See more detail for the build option http://gcc.gnu.org/wiki/DebugFission

So compile fails with following build error

[60/10095] CXX obj/third_party/angle/src/compiler/preprocessor/preprocessor.MacroExpander.o
FAILED: c++ -MMD -MF obj/third_party/angle/src/compiler/preprocessor/preprocessor.MacroExpander.o.d -DV8_DEPRECATION_WARNINGS -DBLINK_SCALE_FILTERS_AT_RECORD_TIME '-DANGLE_PRELOADED_D3DCOMPILER_MODULE_NAMES={ TEXT("d3dcompiler_46.dll"), TEXT("d3dcompiler_43.dll") }' -D_FILE_OFFSET_BITS=64 -DDISABLE_NACL -DCHROMIUM_BUILD -DCOMPONENT_BUILD -DTOOLKIT_VIEWS=1 -DUI_COMPOSITOR_IMAGE_TRANSPORT -DUSE_AURA=1 -DUSE_CAIRO=1 -DUSE_GLIB=1 -DUSE_DEFAULT_RENDER_THEME=1 -DUSE_LIBJPEG_TURBO=1 -DUSE_X11=1 -DUSE_CLIPBOARD_AURAX11=1 -DENABLE_ONE_CLICK_SIGNIN -DUSE_XI2_MT=2 -DENABLE_REMOTING=1 -DENABLE_WEBRTC=1 -DUSE_PROPRIETARY_CODECS -DENABLE_PEPPER_CDMS -DENABLE_CONFIGURATION_POLICY -DENABLE_INPUT_SPEECH -DENABLE_NOTIFICATIONS -DUSE_UDEV -DDCHECK_ALWAYS_ON=1 -DENABLE_EGLIMAGE=1 -DENABLE_TASK_MANAGER=1 -DENABLE_EXTENSIONS=1 -DENABLE_PLUGIN_INSTALLATION=1 -DENABLE_PLUGINS=1 -DENABLE_SESSION_SERVICE=1 -DENABLE_THEMES=1 -DENABLE_AUTOFILL_DIALOG=1 -DENABLE_BACKGROUND=1 -DENABLE_AUTOMATION=1 -DENABLE_GOOGLE_NOW=1 -DCLD_VERSION=2 -DENABLE_FULL_PRINTING=1 -DENABLE_PRINTING=1 -DENABLE_SPELLCHECK=1 -DENABLE_CAPTIVE_PORTAL_DETECTION=1 -DENABLE_APP_LIST=1 -DENABLE_SETTINGS_APP=1 -DENABLE_MANAGED_USERS=1 -DENABLE_MDNS=1 -DUSE_NSS=1 -DDYNAMIC_ANNOTATIONS_ENABLED=1 -DWTF_USE_DYNAMIC_ANNOTATIONS=1 -D_DEBUG -D_GLIBCXX_DEBUG=1  -fstack-protector --param=ssp-buffer-size=4 -pthread -fno-exceptions -fno-strict-aliasing -Wno-unused-parameter -Wno-missing-field-initializers -fvisibility=hidden -pipe -fPIC -Wno-unused-local-typedefs -Wno-format -Wno-unused-result -m64 -march=x86-64 -O0 -g -funwind-tables -gsplit-dwarf -fno-rtti -fno-threadsafe-statics -fvisibility-inlines-hidden -Wno-deprecated  -c ../../third_party/angle/src/compiler/preprocessor/MacroExpander.cpp -o obj/third_party/angle/src/compiler/preprocessor/preprocessor.MacroExpander.o
g++: error trying to exec 'objcopy': execvp: No such file or directory
ICECC[9635] 12:16:59: Compiled on 10.237.72.78

If the user is running a build from inside a chroot, connected to a iceccd daemon running on the local system (ie not in the chroot), build that are run on the local system will fail because the environment does not exist. Builds distributed to other systems will work.

Note, if you want to duplicate this, it is necessary to have the path (unix socket) /var/run/icecc/iceccd.socket mounted from outside the chroot into the chroot so that icecc inside the chroot can communicate with the iceccd deamon running on the local system.

Easy to reproduce with the Icecream Monitor:

• Make sure icecc scheduler is offline
• Start the monitor
• Now start the scheduler
• Monitor still thinks we're "offline", i.e. there's no scheduler

Do I have to change something in the monitors polling routine? See IcecreamMonitor::slotCheckScheduler() for reference. I'm unsure if this is a bug on my side or in libicecc (that is, comm.cpp)

Note: Both using master branches of icecream and icemon.
Note: I'm about to finally release the Qt only, Qt5-based version of the monitor, and this is a release blocker.

Thanks

iceccd version 1.0.1 killed abnomally, and had a segmentation fault.

I started iceccd with this command.
/usr/sbin/iceccd --nice 5 -s 10.10.1.9 -n ICECC_Build -b /var/cache/icecc/base -m 16

and the iceccd daemon killed with below logs.

[3998] 15:12:20: handle_transfer_env
[3998] 15:12:20: got pid 19331
/bin/tar: Skipping to next header

gzip: stdin: invalid compressed data--crc error

gzip: stdin: invalid compressed data--length error
/bin/tar: Child died with signal 13
/bin/tar: Error is not recoverable: exiting now
[3998] 15:12:21: write to transfer env pipe failed. Broken pipe
[3998] 15:12:21: handle_transfer_env_done
[3998] 15:12:21: exit code: 129
[3998] 15:12:22: installed_size: 0
[3998] 15:12:22: reannounce_environments
*** Segmentation fault
Register dump:

RAX: 0000000002555c2d RBX: 00007fff1c788a50 RCX: 00007f7debe89738
RDX: 0000000002556f90 RSI: 0000000000000000 RDI: 00007fff1c788a50
RBP: 00000000025566f0 R8 : 0000000000000000 R9 : 0000000000000000
R10: 0000000000004000 R11: 0000000000000206 R12: 00007fff1c788c40
R13: 00007fff1c788e00 R14: 0000000002554130 R15: 00000000025566f0
RSP: 00007fff1c7889c0

RIP: 000000000041e85b EFLAGS: 00010206

CS: 0033 FS: 0000 GS: 0000

Trap: 0000000e Error: 00000004 OldMask: 00000000 CR2: 00000078

FPUCW: 0000037f FPUSW: 00000000 TAG: 00000000
RIP: 00000000 RDP: 00000000

ST(0) 0000 0000000000000000 ST(1) 0000 0000000000000000
ST(2) 0000 0000000000000000 ST(3) 0000 0000000000000000
ST(4) 0000 0000000000000000 ST(5) 0000 0000000000000000
ST(6) 0000 0000000000000000 ST(7) 0000 0000000000000000
mxcsr: 1fa0
XMM0: 000000000000000000000000676b6f61 XMM1: 000000000000000000000000676b6f61
XMM2: 000000000000000000000000676b6f61 XMM3: 000000000000000000000000676b6f61
XMM4: 000000000000000000000000676b6f61 XMM5: 000000000000000000000000676b6f61
XMM6: 000000000000000000000000676b6f61 XMM7: 000000000000000000000000676b6f61
XMM8: 000000000000000000000000676b6f61 XMM9: 000000000000000000000000676b6f61
XMM10: 000000000000000000000000676b6f61 XMM11: 000000000000000000000000676b6f61
XMM12: 000000000000000000000000676b6f61 XMM13: 000000000000000000000000676b6f61
XMM14: 000000000000000000000000676b6f61 XMM15: 000000000000000000000000676b6f61

Backtrace:
/usr/sbin/iceccd[0x41e85b]
/usr/sbin/iceccd[0x40ffcf]
/usr/sbin/iceccd[0x40d83e]
/usr/sbin/iceccd[0x40e485]
/usr/sbin/iceccd[0x40e6f0]
/usr/sbin/iceccd[0x406a7f]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed)[0x7f7debaf276d]
/usr/sbin/iceccd[0x406e59]

Memory map:

00400000-00430000 r-xp 00000000 08:02 577357901 /usr/sbin/iceccd
00630000-00631000 r--p 00030000 08:02 577357901 /usr/sbin/iceccd
00631000-00632000 rw-p 00031000 08:02 577357901 /usr/sbin/iceccd
0254f000-02583000 rw-p 00000000 00:00 0 [heap]
7f7deb090000-7f7deb094000 r-xp 00000000 08:02 39222531 /lib/x86_64-linux-gnu/libSegFault.so
7f7deb094000-7f7deb293000 ---p 00004000 08:02 39222531 /lib/x86_64-linux-gnu/libSegFault.so
7f7deb293000-7f7deb294000 r--p 00003000 08:02 39222531 /lib/x86_64-linux-gnu/libSegFault.so
7f7deb294000-7f7deb295000 rw-p 00004000 08:02 39222531 /lib/x86_64-linux-gnu/libSegFault.so
7f7deb295000-7f7deb2a1000 r-xp 00000000 08:02 39222638 /lib/x86_64-linux-gnu/libnss_files-2.15.so
7f7deb2a1000-7f7deb4a0000 ---p 0000c000 08:02 39222638 /lib/x86_64-linux-gnu/libnss_files-2.15.so
7f7deb4a0000-7f7deb4a1000 r--p 0000b000 08:02 39222638 /lib/x86_64-linux-gnu/libnss_files-2.15.so
7f7deb4a1000-7f7deb4a2000 rw-p 0000c000 08:02 39222638 /lib/x86_64-linux-gnu/libnss_files-2.15.so
7f7deb4a2000-7f7deb4ac000 r-xp 00000000 08:02 39222560 /lib/x86_64-linux-gnu/libnss_nis-2.15.so
7f7deb4ac000-7f7deb6ac000 ---p 0000a000 08:02 39222560 /lib/x86_64-linux-gnu/libnss_nis-2.15.so
7f7deb6ac000-7f7deb6ad000 r--p 0000a000 08:02 39222560 /lib/x86_64-linux-gnu/libnss_nis-2.15.so
7f7deb6ad000-7f7deb6ae000 rw-p 0000b000 08:02 39222560 /lib/x86_64-linux-gnu/libnss_nis-2.15.so
7f7deb6ae000-7f7deb6c5000 r-xp 00000000 08:02 39238614 /lib/x86_64-linux-gnu/libnsl-2.15.so
7f7deb6c5000-7f7deb8c4000 ---p 00017000 08:02 39238614 /lib/x86_64-linux-gnu/libnsl-2.15.so
7f7deb8c4000-7f7deb8c5000 r--p 00016000 08:02 39238614 /lib/x86_64-linux-gnu/libnsl-2.15.so
7f7deb8c5000-7f7deb8c6000 rw-p 00017000 08:02 39238614 /lib/x86_64-linux-gnu/libnsl-2.15.so
7f7deb8c6000-7f7deb8c8000 rw-p 00000000 00:00 0
7f7deb8c8000-7f7deb8d0000 r-xp 00000000 08:02 39222639 /lib/x86_64-linux-gnu/libnss_compat-2.15.so
7f7deb8d0000-7f7debacf000 ---p 00008000 08:02 39222639 /lib/x86_64-linux-gnu/libnss_compat-2.15.so
7f7debacf000-7f7debad0000 r--p 00007000 08:02 39222639 /lib/x86_64-linux-gnu/libnss_compat-2.15.so
7f7debad0000-7f7debad1000 rw-p 00008000 08:02 39222639 /lib/x86_64-linux-gnu/libnss_compat-2.15.so
7f7debad1000-7f7debc86000 r-xp 00000000 08:02 39222530 /lib/x86_64-linux-gnu/libc-2.15.so
7f7debc86000-7f7debe85000 ---p 001b5000 08:02 39222530 /lib/x86_64-linux-gnu/libc-2.15.so
7f7debe85000-7f7debe89000 r--p 001b4000 08:02 39222530 /lib/x86_64-linux-gnu/libc-2.15.so
7f7debe89000-7f7debe8b000 rw-p 001b8000 08:02 39222530 /lib/x86_64-linux-gnu/libc-2.15.so
7f7debe8b000-7f7debe90000 rw-p 00000000 00:00 0
7f7debe90000-7f7debea5000 r-xp 00000000 08:02 39220234 /lib/x86_64-linux-gnu/libgcc_s.so.1
7f7debea5000-7f7dec0a4000 ---p 00015000 08:02 39220234 /lib/x86_64-linux-gnu/libgcc_s.so.1
7f7dec0a4000-7f7dec0a5000 r--p 00014000 08:02 39220234 /lib/x86_64-linux-gnu/libgcc_s.so.1
7f7dec0a5000-7f7dec0a6000 rw-p 00015000 08:02 39220234 /lib/x86_64-linux-gnu/libgcc_s.so.1
7f7dec0a6000-7f7dec1a1000 r-xp 00000000 08:02 39222562 /lib/x86_64-linux-gnu/libm-2.15.so
7f7dec1a1000-7f7dec3a0000 ---p 000fb000 08:02 39222562 /lib/x86_64-linux-gnu/libm-2.15.so
7f7dec3a0000-7f7dec3a1000 r--p 000fa000 08:02 39222562 /lib/x86_64-linux-gnu/libm-2.15.so
7f7dec3a1000-7f7dec3a2000 rw-p 000fb000 08:02 39222562 /lib/x86_64-linux-gnu/libm-2.15.so
7f7dec3a2000-7f7dec484000 r-xp 00000000 08:02 39264899 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16
7f7dec484000-7f7dec683000 ---p 000e2000 08:02 39264899 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16
7f7dec683000-7f7dec68b000 r--p 000e1000 08:02 39264899 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16
7f7dec68b000-7f7dec68d000 rw-p 000e9000 08:02 39264899 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16
7f7dec68d000-7f7dec6a2000 rw-p 00000000 00:00 0
7f7dec6a2000-7f7dec6a4000 r-xp 00000000 08:02 39222529 /lib/x86_64-linux-gnu/libdl-2.15.so
7f7dec6a4000-7f7dec8a4000 ---p 00002000 08:02 39222529 /lib/x86_64-linux-gnu/libdl-2.15.so
7f7dec8a4000-7f7dec8a5000 r--p 00002000 08:02 39222529 /lib/x86_64-linux-gnu/libdl-2.15.so
7f7dec8a5000-7f7dec8a6000 rw-p 00003000 08:02 39222529 /lib/x86_64-linux-gnu/libdl-2.15.so
7f7dec8a6000-7f7dec8c8000 r-xp 00000000 08:02 39222670 /lib/x86_64-linux-gnu/ld-2.15.so
7f7deca0a000-7f7decaad000 rw-p 00000000 00:00 0
7f7decac6000-7f7decac8000 rw-p 00000000 00:00 0
7f7decac8000-7f7decac9000 r--p 00022000 08:02 39222670 /lib/x86_64-linux-gnu/ld-2.15.so
7f7decac9000-7f7decacb000 rw-p 00023000 08:02 39222670 /lib/x86_64-linux-gnu/ld-2.15.so
7fff1c769000-7fff1c78a000 rw-p 00000000 00:00 0 [stack]
7fff1c7ff000-7fff1c800000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
Segmentation fault (core dumped)

The build system is broken because tabs were replaced by white spaces in the Makefiles. Introduced by the commit b2b11c5.

We have some icecream users at our physical site that are the lone user on their subnet. They are able to use ice cream by connecting via scheduler name directly to the scheduler. However if the configured scheduler decides there is a better scheduler it will disconnect all clients, even those which will never connect to a different one.

The schedulers that are in this situation are well known. Thus it would be acceptable to have a parameter so the scheduler will not disconnect any client.

The man page for icecc-scheduler is outdated. It mentions --allow-run-as-user which has been removed (6 years ago?).

Also, icecc-scheduler --help mentions --user-uid which is not documented in the manpage.

Since moving to Ubuntu 14.4 and iceccd version 1.0.1-1 the daemon regularly dies with the exit code 129, see log file below.

Any ideas?

Thanks Robert

WS3552:~/$ uname -a
Linux WS3552 3.13.0-35-generic #62-Ubuntu SMP Fri Aug 15 01:58:42 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

WS3552:~/$ ps -ef | grep iceccd
root 31550 2716 0 13:31 ? 00:00:00 /usr/sbin/iceccd -N rmelch-WS3552 -vvv -d -l /var/log/iceccd.log --nice 5 -u icecc -b /var/cache/icecc

Log file:

22300] 04:21:05: timeout <= 0
[22300] 04:21:05: !wait_for_msg()
[22300] 04:21:05: timeout <= 0
[22300] 04:21:05: !wait_for_msg()
[22300] 04:21:05: timeout <= 0
[22300] 04:21:05: !wait_for_msg()
[22300] 04:21:05: timeout <= 0
[21167] 16:21:20: accepted 10 0.0.0.0
[21167] 16:21:20: send JobLocalBeginMsg to client
[21167] 16:21:20: pushed local job 3348
[21167] 16:21:20: eof && !HAS_MSG
[21167] 16:21:20: scheduler->send_msg( JobLocalDoneMsg( 3348) );
[21167] 16:21:21: accepted 10 0.0.0.0
[21167] 16:21:21: send JobLocalBeginMsg to client
[21167] 16:21:21: pushed local job 3349
[21167] 16:21:21: eof && !HAS_MSG
[21167] 16:21:21: scheduler->send_msg( JobLocalDoneMsg( 3349) );
[21167] 16:21:21: accepted 10 0.0.0.0
[21167] 16:21:21: send JobLocalBeginMsg to client
[21167] 16:21:21: pushed local job 3350
[21167] 16:21:21: eof && !HAS_MSG
[21167] 16:21:21: scheduler->send_msg( JobLocalDoneMsg( 3350) );
[21167] 16:24:18: accepted 10 172.16.164.67
[21167] 16:24:18: handle_transfer_env
[21167] 16:24:18: mkdir name File exists
[21167] 16:24:18: handle_transfer_env_done
[21167] 16:24:18: exit code: 129

I commented this issue on the ccache bugzilla and they gave me this answer:

https://bugzilla.samba.org/show_bug.cgi?id=10923

I think it would be really interesting that IceCream could support this.

I am trying to compile WebKit project on MacOS with icecc support.
I made two patches on my "for-mac" branch but they aren't woking :)

https://github.com/ragner/icecream/commits/for-mac

The compilation starts "well" but after a while a get the following error message:

CompileC /Users/ragner/Workspace/Repositories/WebKit/WebKitBuild/JavaScriptCore.build/Release/JavaScriptCore.build/Objects-normal/x86_64/udis86.o disassembler/udis86/udis86.c normal x86_64 c com.apple.compilers.llvm.clang.1_0.compiler
cd /Users/ragner/Workspace/Repositories/WebKit/Source/JavaScriptCore
setenv LANG en_US.US-ASCII
/usr/local/libexec/icecc/bin/clang -x c -arch x86_64 -fmessage-length=0 -std=gnu99 -Wno-trigraphs -fpascal-strings -O3 -Werror -Wno-missing-field-initializers -Wmissing-prototypes -Wno-return-type -Wformat -Wno-missing-braces -Wparentheses -Wswitch -Wno-unused-function -Wno-unused-label -Wno-unused-parameter -Wno-unused-variable -Wunused-value -Wno-empty-body -Wno-uninitialized -Wno-unknown-pragmas -Wno-shadow -Wno-four-char-constants -Wno-conversion -Wno-constant-conversion -Wno-int-conversion -Wno-enum-conversion -Wsign-compare -Wno-shorten-64-to-32 -Wpointer-sign -Wnewline-eof -DNDEBUG -DHAVE_DTRACE=1 -DWEBKIT_VERSION_MIN_REQUIRED=WEBKIT_VERSION_LATEST -DHAVE_HEADER_DETECTION_H -fasm-blocks -fstrict-aliasing -Wdeprecated-declarations -mmacosx-version-min=10.8 -g -fvisibility=hidden -Wno-sign-conversion -I/Users/ragner/Workspace/Repositories/WebKit/WebKitBuild/JavaScriptCore.build/Release/JavaScriptCore.build/JavaScriptCore.hmap -I/Users/ragner/Workspace/Repositories/WebKit/WebKitBuild/Release/include -I/Users/ragner/Workspace/Repositories/WebKit/WebKitBuild/Release/DerivedSources/JavaScriptCore -I. -Iicu -I/Users/ragner/Workspace/Repositories/WebKit/WebKitBuild/Release/usr/local/include -I/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include -I/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include -I/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include -I/Users/ragner/Workspace/Repositories/WebKit/WebKitBuild/JavaScriptCore.build/Release/JavaScriptCore.build/DerivedSources/x86_64 -I/Users/ragner/Workspace/Repositories/WebKit/WebKitBuild/JavaScriptCore.build/Release/JavaScriptCore.build/DerivedSources -Wall -Wextra -Wcast-qual -Wchar-subscripts -Wextra-tokens -Wformat=2 -Winit-self -Wmissing-format-attribute -Wmissing-noreturn -Wpacked -Wpointer-arith -Wredundant-decls -Wundef -Wwrite-strings -Wexit-time-destructors -Wglobal-constructors -Wtautological-compare -F/Users/ragner/Workspace/Repositories/WebKit/WebKitBuild/Release -include /Users/ragner/Workspace/Repositories/WebKit/WebKitBuild/PrecompiledHeaders/JavaScriptCorePrefix-cvbmncevuhmwsbfybcsnvapqaoce/JavaScriptCorePrefix.h -MMD -MT dependencies -MF /Users/ragner/Workspace/Repositories/WebKit/WebKitBuild/JavaScriptCore.build/Release/JavaScriptCore.build/Objects-normal/x86_64/udis86.d --serialize-diagnostics /Users/ragner/Workspace/Repositories/WebKit/WebKitBuild/JavaScriptCore.build/Release/JavaScriptCore.build/Objects-normal/x86_64/udis86.dia -c /Users/ragner/Workspace/Repositories/WebKit/Source/JavaScriptCore/disassembler/udis86/udis86.c -o /Users/ragner/Workspace/Repositories/WebKit/WebKitBuild/JavaScriptCore.build/Release/JavaScriptCore.build/Objects-normal/x86_64/udis86.o
In file included from :1:
In file included from /Users/ragner/Workspace/Repositories/WebKit/Source/JavaScriptCore/disassembler/udis86/udis86.c:30:
In file included from /Users/ragner/Workspace/Repositories/WebKit/Source/JavaScriptCore/config.h:39:
/Users/ragner/Workspace/Repositories/WebKit/WebKitBuild/Release/usr/local/include/wtf/Platform.h:550:5: error: '__MAC_OS_X_VERSION_MIN_REQUIRED' is not defined, evaluates to 0 [-Werror,-Wundef]

if __MAC_OS_X_VERSION_MIN_REQUIRED >= 1070

^

/Users/ragner/Workspace/Repositories/WebKit/WebKitBuild/Release/usr/local/include/wtf/Platform.h:557:5: error: '__MAC_OS_X_VERSION_MIN_REQUIRED' is not defined, evaluates to 0 [-Werror,-Wundef]

if __MAC_OS_X_VERSION_MIN_REQUIRED >= 1080

^

/Users/ragner/Workspace/Repositories/WebKit/WebKitBuild/Release/usr/local/include/wtf/Platform.h:678:22: error: '__MAC_OS_X_VERSION_MIN_REQUIRED' is not defined, evaluates to 0 [-Werror,-Wundef]

if PLATFORM(IOS) || __MAC_OS_X_VERSION_MIN_REQUIRED >= 1060

                 ^

Could anyone help me with that patches?

There's no documentation, example or anything that explains the icerun command.

In company, we have a icecream scheduler setup, I guess it's older than ubuntu 13.04. My own machine is 13.04, it can't join the network. I got following when tried "icecc":

ICECC[22872] 08:10:50: icecream seems to have invoked itself recursively!

And I tried to use 12.04 live cd on another machine in same network, it works fine.

Could you help me on this issue? or guide me how to analysis it? Thanks.

$ icecc --build-native
adding file /bin/true=/usr/bin/true
adding file /usr/lib/libSystem.B.dylib
adding file /usr/lib/system/libcache.dylib
adding file /usr/lib/system/libsystem_pthread.dylib
adding file /usr/lib/system/libsystem_kernel.dylib
adding file /usr/lib/system/libsystem_platform.dylib
adding file /usr/lib/system/libdyld.dylib
adding file /usr/lib/system/libsystem_malloc.dylib
adding file /usr/lib/system/libcompiler_rt.dylib
adding file /usr/lib/system/libunwind.dylib
adding file /usr/lib/system/libsystem_c.dylib
adding file /usr/lib/system/libsystem_m.dylib
adding file /usr/lib/system/libdispatch.dylib
adding file /usr/lib/system/libsystem_blocks.dylib
adding file /usr/lib/system/libsystem_asl.dylib
adding file /usr/lib/system/liblaunch.dylib
adding file /usr/lib/system/libquarantine.dylib
adding file /usr/lib/system/libmacho.dylib
adding file /usr/lib/system/libcorecrypto.dylib
adding file /usr/lib/system/libxpc.dylib
adding file /usr/lib/system/libsystem_sandbox.dylib
adding file /usr/lib/libobjc.A.dylib
adding file /usr/lib/libauto.dylib
adding file /usr/lib/libc++.1.dylib
adding file /usr/lib/libc++abi.dylib
adding file /usr/lib/libDiagnosticMessagesClient.dylib
adding file /usr/lib/system/libsystem_notify.dylib
adding file /usr/lib/system/libsystem_info.dylib
adding file /usr/lib/system/libsystem_dnssd.dylib
adding file /usr/lib/system/libsystem_network.dylib
adding file /usr/lib/system/libkeymgr.dylib
adding file /usr/lib/system/libcommonCrypto.dylib
adding file /usr/lib/system/libcopyfile.dylib
adding file /usr/lib/system/libremovefile.dylib
adding file /usr/lib/system/libsystem_configuration.dylib
adding file /usr/lib/system/libsystem_stats.dylib
adding file /usr/lib/system/libunc.dylib
adding file /usr/bin/gcc
adding file /usr/lib/libxcselect.dylib
adding file /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
adding file /usr/lib/libicucore.A.dylib
adding file /usr/lib/libz.1.dylib
adding file /usr/bin/g++
ls: cc1: No such file or directory
adding file /usr/bin/cc1=
ls: cc1plus: No such file or directory
adding file /usr/bin/cc1plus=
adding file /usr/bin/as=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/as
adding file /usr/lib/dyld
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
ls: /usr/bin/Apple: No such file or directory
adding file /usr/bin/Apple=
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
ls: /usr/bin/Apple: No such file or directory
adding file /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/libexec/as/x86_64/as
cp: /usr/bin/cc1=: No such file or directory
cp: /usr/bin/cc1plus=: No such file or directory
cp: /usr/bin/Apple=: No such file or directory
md5: /tmp/iceccenvzUBLyR/usr/bin/Apple=: No such file or directory
md5: /tmp/iceccenvzUBLyR/usr/bin/cc1=: No such file or directory
md5: /tmp/iceccenvzUBLyR/usr/bin/cc1plus=: No such file or directory
creating f633e35470b9ee2701511360c2d05897.tar.gz
tar: usr/bin/Apple=: Cannot stat: No such file or directory
tar: usr/bin/cc1=: Cannot stat: No such file or directory
tar: usr/bin/cc1plus=: Cannot stat: No such file or directory
tar: Error exit delayed from previous errors.
Couldn't create archive

I built from the git master branch.

Have not tested any other releases of Ubuntu but I get the following error when trying to build icecream.

It seems that "make" creates icecc, etc., but is searching for icecc.1, etc., when doing "make install":
https://gist.github.com/thopiekar/aef3bb9d2b801f564e2b

I posted over on stack overflow about this but I figure the number of icecc users over there is pretty low.

Not sure if this is the right place to ask either, but here goes -

I can't manage to get an icecc daemon to connect to the local icecc-scheduler from any machine running Fedora 20.

I've had no issues setting this up on 5 different Ubuntu 14.04 machines, and each can run the scheduler with no issue. In fact, it appears to work out of the box with no additional config on Ubuntu - simple install and play.

In those cases on Ubuntu

sudo apt-get install icecc
sudo service iceccd start

And on one of the machines

sudo service icecc-scheduler start

Then simply setting the path and building like so

export PATH=/usr/lib/icecc/bin:$PATH
make -j16

This is all that is needed to get the distributed compile working on Ubuntu as far as I can see.

On Fedora installing and starting I use

sudo yum install icecream.x86_64
sudo systemctl start iceccd

And compiling with

export PATH=/usr/libexec/icecc/bin:$PATH
make -j16

This doesn't distribute the compile.
The icemon utility on the scheduler does not show any evidence of the fedora machine either and running a status on the iceccd service gives this error:

Jul 21 09:44:08 Fedora20 iceccd[4642]: [4642] 09:44:08: scheduler not yet found.

So far the only thing I've tried that might have been the issue is opening up the ports that the readme provides by adding them to the Zones->Ports part of Firewall Configuration , but this hasn't helped.

Maybe there is something I need to do on the Ubuntu schedular and daemons? Has anyone else had any luck with setting up icecream on Fedora 20?

Ubuntu 14.04, icecc 1.0.1-1, iceccd node on a medium-sized (10-20 nodes) network crashed:

ThreadStacktrace:
 .
 Thread 1 (LWP 3774):
 #0  0x00007f792133dbb9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
         resultvar = 0
         pid = 3774
         selftid = 3774
 #1  0x00007f7921340fc8 in __GI_abort () at abort.c:89
         save_stage = 2
         act = {__sigaction_handler = {sa_handler = 0x7fffe606ef26, sa_sigaction = 0x7fffe606ef26}, sa_mask = {__val = {140158226155612, 4357466, 860, 4294967295, 140158224794579, 0, 140737052597360, 42949673084, 140158234636703, 140737052598680, 0, 0, 0, 21474836480, 140158241402880, 140158226170736}}, sa_flags = 4357751, sa_restorer = 0x429080 <Daemon::handle_transfer_env_done(Client*)::__PRETTY_FUNCTION__>}
         sigs = {__val = {32, 0 <repeats 15 times>}}
 #2  0x00007f7921336a76 in __assert_fail_base (fmt=0x7f7921488370 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x427e77 "current_kids > 0", file=file@entry=0x427d5a "main.cpp", line=line@entry=860, function=function@entry=0x429080 <Daemon::handle_transfer_env_done(Client*)::__PRETTY_FUNCTION__> "bool Daemon::handle_transfer_env_done(Client*)") at assert.c:92
         str = 0xfc12a0 ""
         total = 4096
 #3  0x00007f7921336b22 in __GI___assert_fail (assertion=0x427e77 "current_kids > 0", file=0x427d5a "main.cpp", line=860, function=0x429080 <Daemon::handle_transfer_env_done(Client*)::__PRETTY_FUNCTION__> "bool Daemon::handle_transfer_env_done(Client*)") at assert.c:101
 No locals.
 #4  0x0000000000409123 in Daemon::handle_transfer_env_done (this=this@entry=0x7fffe606e100, client=client@entry=0xfc94d0) at main.cpp:860
         __PRETTY_FUNCTION__ = "bool Daemon::handle_transfer_env_done(Client*)"
         installed_size = 0
         current = {static npos = <optimized out>, _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0xfc9238 "x86_64/stbgcc-4.5.4-2.8"}}
         r = <optimized out>
 #5  0x000000000040d170 in Daemon::handle_transfer_env (this=this@entry=0x7fffe606e100, client=client@entry=0xfc94d0, _msg=_msg@entry=0xfc9120) at main.cpp:834
         __PRETTY_FUNCTION__ = "bool Daemon::handle_transfer_env(Client*, Msg*)"
         emsg = 0xfc9120
         sock_to_stdin = -1
         pid = 0
         target = {static npos = <optimized out>, _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0xfc9348 "x86_64"}}
         fmsg = 0xfc9360
 #6  0x000000000040d466 in Daemon::handle_activity (this=this@entry=0x7fffe606e100, client=client@entry=0xfc94d0) at main.cpp:1380
         __PRETTY_FUNCTION__ = "bool Daemon::handle_activity(Client*)"
         msg = 0xfc9120
         ret = <optimized out>
 #7  0x000000000040df3b in Daemon::answer_client_requests (this=this@entry=0x7fffe606e100) at main.cpp:1571
         i = 10
         c = 0xfc9090
         client = 0xfc94d0
         it = {_M_node = 0x7fffe606e1e0}
         had_scheduler = true
         listen_fd = <optimized out>
         status = 0
         listen_set = {fds_bits = {1024, 0 <repeats 15 times>}}
         tv = {tv_sec = 2, tv_usec = 990098}
         __PRETTY_FUNCTION__ = "int Daemon::answer_client_requests()"
         ret = <optimized out>
         max_fd = 10
 #8  0x000000000040e180 in Daemon::working_loop (this=this@entry=0x7fffe606e100) at main.cpp:1642
         ret = <optimized out>
 #9  0x000000000040648b in main (argc=<optimized out>, argv=<optimized out>) at main.cpp:1881
         progName = {static npos = <optimized out>, _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0xfb8438 "iceccd"}}
         nl = {<std::_List_base<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >> = {_M_impl = {<std::allocator<std::_List_node<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >> = {<__gnu_cxx::new_allocator<std::_List_node<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >> = {<No data fields>}, <No data fields>}, _M_node = {_M_next = 0x7fffe606e0f0, _M_prev = 0x7fffe606e0f0}}}, <No data fields>}
         pidFile = <incomplete type>
         max_processes = <optimized out>
         d = {clients = {<std::map<MsgChannel*, Client*, std::less<MsgChannel*>, std::allocator<std::pair<MsgChannel* const, Client*> > >> = {_M_t = {_M_impl = {<std::allocator<std::_Rb_tree_node<std::pair<MsgChannel* const, Client*> > >> = {<__gnu_cxx::new_allocator<std::_Rb_tree_node<std::pair<MsgChannel* const, Client*> > >> = {<No data fields>}, <No data fields>}, _M_key_compare = {<std::binary_function<MsgChannel*, MsgChannel*, bool>> = {<No data fields>}, <No data fields>}, _M_header = {_M_color = std::_S_red, _M_parent = 0xfb8480, _M_left = 0xfb8480, _M_right = 0xfb8480}, _M_node_count = 1}}}, active_processes = 0}, envs_last_use = {_M_t = {_M_impl = {<std::allocator<std::_Rb_tree_node<std::pair<std::basic_string<char, std::char_traits<char>, std::allocator<char> > const, long> > >> = {<__gnu_cxx::new_allocator<std::_Rb_tree_node<std::pair<std::basic_string<char, std::char_traits<char>, std::allocator<char> > const, long> > >> = {<No data fields>}, <No data fields>}, _M_key_compare = {<std::binary_function<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool>> = {<No data fields>}, <No data fields>}, _M_header = {_M_color = std::_S_red, _M_parent = 0xfc9150, _M_left = 0xfc9150, _M_right = 0xfc9150}, _M_node_count = 1}}}, native_environments = {_M_t = {_M_impl = {<std::allocator<std::_Rb_tree_node<std::pair<std::basic_string<char, std::char_traits<char>, std::allocator<char> > const, NativeEnvironment> > >> = {<__gnu_cxx::new_allocator<std::_Rb_tree_node<std::pair<std::basic_string<char, std::char_traits<char>, std::allocator<char> > const, NativeEnvironment> > >> = {<No data fields>}, <No data fields>}, _M_key_compare = {<std::binary_function<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool>> = {<No data fields>}, <No data fields>}, _M_header = {_M_color = std::_S_red, _M_parent = 0x0, _M_left = 0x7fffe606e170, _M_right = 0x7fffe606e170}, _M_node_count = 0}}}, envbasedir = {static npos = <optimized out>, _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0xfb5a38 "/var/cache/icecc"}}, user_uid = 115, user_gid = 126, warn_icecc_user = false, tcp_listen_fd = 5, unix_listen_fd = 6, machine_name = {static npos = <optimized out>, _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0xfb8468 "x86_64"}}, nodename = {static npos = <optimized out>, _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0xfb8408 "alkesh"}}, noremote = false, custom_nodename = false, cache_size = 1040770734, fd2chan = {_M_t = {_M_impl = {<std::allocator<std::_Rb_tree_node<std::pair<int const, MsgChannel*> > >> = {<__gnu_cxx::new_allocator<std::_Rb_tree_node<std::pair<int const, MsgChannel*> > >> = {<No data fields>}, <No data fields>}, _M_key_compare = {<std::binary_function<int, int, bool>> = {<No data fields>}, <No data fields>}, _M_header = {_M_color = std::_S_red, _M_parent = 0xfc92b0, _M_left = 0xfc92b0, _M_right = 0xfc92b0}, _M_node_count = 1}}}, new_client_id = 50816, remote_name = {static npos = <optimized out>, _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0xfb84d8 "10.40.155.72"}}, next_scheduler_connect = 0, icecream_load = 0, icecream_usage = {tv_sec = 80567, tv_usec = 799372}, current_load = 0, num_cpus = 8, scheduler = 0xfba4e0, discover = 0x0, netname = {static npos = <optimized out>, _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x6319f8 <std::string::_Rep::_S_empty_rep_storage+24> ""}}, schedname = {static npos = <optimized out>, _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0xfb59f8 "stewie.wroclaw.osa"}}, max_scheduler_pong = 3, max_scheduler_ping = 36, bench_source = {static npos = <optimized out>, _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x102b4f8 "\n\nunsigned foo(int x[64], int y[64])\n{\n  if ((x)[0] > (y)[0]) goto gt; if ((x)[0] < (y)[0]) goto lt; if ((x)[1] > (y)[0]) goto gt; if ((x)[1] < (y)[0]) goto lt; if ((x)[2] > (y)[0]) goto gt; if ((x)[2"...}}, current_kids = 0}
         debug_level = <optimized out>
         logfile = {static npos = <optimized out>, _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0xfb5988 "/var/log/iceccd.log"}}
         detach = <optimized out>

This seems to happen randomly from time to time. It is annoying since unattended nodes generally don't automatically restart the daemon.

I can also post the full apport crash log which includes a coredump if you tell me where you want it.

Branch: master, followed tests/README (Kubuntu 14.04, GCC 4.9)

icecc.log :

==============
Test (remote): make test 1
==============

scheduler.log :

==============
Test (remote): make test 1
==============
[12334] 10:41:06: saw eof without complete msg! 1
[12334] 10:41:06: remove daemon localice
[12334] 10:41:06: saw eof without complete msg! 1
[12334] 10:41:06: remove daemon remoteice1
[12334] 10:41:06: saw eof without complete msg! 1
[12334] 10:41:06: remove daemon remoteice2

Does this mean the message passing is broken?

icecream version 1.0.1
File: daemon/main.cpp

In method handle_activity() at line number 1370,
ret = handle_file_chunk_env(client, msg);
Here, handle_file_chunk_env frees client and freed pointer 'client' is passed as an argument to other functions (like handle_compile_file(), handle_transfer_env(), handle_get_cs()).
handle_file_chunk_env also frees msg and freed pointer msg is dereferenced at statement switch(msg->type) at line number 1377.

Suggested patch:

I don't have time/interest to fix this right now, so track it here - this is what you get for make distcheck

ERROR: files left after uninstall:
./etc/init.d/icecream
./etc/logrotate.d/icecream
./etc/sysconfig/SuSEfirewall2.d/services/iceccd
./etc/sysconfig/SuSEfirewall2.d/services/icecream-scheduler
./var/adm/fillup-templates/sysconfig.icecream

It seems to be harmful to have multiple icecream schedulers running on the same network. But in other master/slave contexts which require a central server, this kind of problem has been solved with a voting scheme: each client could potentially be a server, but conflicts are resolved dynamically so that at any given point in time there is agreement on which machine should be the server. (It might even change depending which machine performs that job most effectively: it needs to have low latency but not necessarily the fastest CPU.) This way there is no administration to be done, and icecream would more effective in dynamically changing configurations: people might gather in a conference room for example, and could spontaneously share the CPUs of each others' laptops for a while just by being on the same wifi. The humans wouldn't need to decide who's going to run the scheduler.

Better yet, following the principle of decentralization, maybe a central scheduler should not be necessary at all. Jobs could be announced on a multicast channel for example, so that any machine with spare capacity could contact the requester to get a work packet, do the work and reply with the result. The requester can then ensure that each compilation occurs only once, by giving a different job to each helper, without needing a central scheduler to manage it. Whenever the requester has spare CPU capacity, it would do its own compilation, so that there is no delay in case no helpers are available.

I've installed icecream from openSUSE 12.3 repo (Version: 1.0.0-12.4.1, Arch: x86_64), enabled service icecream (with Yast2 -> runlevel), checked:

# systemctl is-enabled icecream.service
icecream.service is not a native service, redirecting to /sbin/chkconfig.
Executing /sbin/chkconfig icecream --level=5
enabled

All works OK until I restart computer. Then service doesn't work:

# /etc/init.d/icecream status
Checking for Distributed Compiler Daemon:                                                                                                                                                        unused
icecream.service - LSB: icecc
          Loaded: loaded (/etc/init.d/icecream)
          Active: inactive (dead) since Wed, 2013-05-01 11:14:51 MSK; 41min ago
         Process: 867 ExecStop=/etc/init.d/icecream stop (code=exited, status=0/SUCCESS)
         Process: 784 ExecStart=/etc/init.d/icecream start (code=exited, status=0/SUCCESS)
          CGroup: name=systemd:/system/icecream.service

May 01 11:14:50 pc.lan systemd[1]: Starting LSB: icecc...
May 01 11:14:50 pc.lan systemd[1]: Started LSB: icecc.
May 01 11:14:50 pc.lan icecream[784]: Starting Distributed Compiler Daemon..done
May 01 11:14:51 pc.lan icecream[867]: Shutting down Distributed Compiler Daemon..done

I tried to reenable service, all the same: it doesn't work after reboot.

I would like to point out that identifiers like "_ENVIRONMENT_H" and "_LOAD_H_" do not fit to the expected naming convention of the C++ language standard.
Would you like to adjust your selection for unique names?

After commit 9649787 out of source tree builds do not work. In source builds still work.

CXX      remote.o
../../icecream/client/remote.cpp:54:27: fatal error: services/util.h: No such file or directory
 #include "services/util.h"
                           ^
compilation terminated.
make[2]: *** [remote.o] Error 1

This commit added the not found include.

Hi,

I've noticed via ICECC_DEBUG that when compiling a file locally it uses whatever compiler is in your path and not the version that is found in ICECC_VERSION tarball. This means that object files can be created by incompatible compilers. I don't think this is commonly understood in icecream deployments where ICECC_VERSION is used.

For instance, I recently setup a compile farm where I created a tarball and put it up on a local file share for people to download and specify as ICECC_VERSION. This is wrong though because they might have an incompatible local compiler.

I think it would be best for icecc to use the ICECC_VERSION specified compiler even for local compile jobs instead of whatever is in the path.

Thoughts?
Adam

I get this error when I try to run autogen.sh from the latest git version:

libtoolize: putting auxiliary files in `.'.
libtoolize: copying file `./ltmain.sh'
libtoolize: You should add the contents of the following files to `aclocal.m4':
libtoolize:   `/usr/share/aclocal/libtool.m4'
libtoolize:   `/usr/share/aclocal/ltoptions.m4'
libtoolize:   `/usr/share/aclocal/ltversion.m4'
libtoolize:   `/usr/share/aclocal/ltsugar.m4'
libtoolize:   `/usr/share/aclocal/lt~obsolete.m4'
libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and
libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree.
libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
configure.ac:17: error: 'AM_CONFIG_HEADER': this macro is obsolete.
    You should use the 'AC_CONFIG_HEADERS' macro instead.
/usr/share/aclocal-1.13/obsolete-err.m4:12: AM_CONFIG_HEADER is expanded from...
configure.ac:17: the top level
autom4te: /usr/bin/m4 failed with exit status: 1
aclocal: error: echo failed with exit status: 1
    error: aclocal  failed

I am on an Arch Linux x86_64 machine. If you would like information about what versions of various programs I am using, I can supply those.

Hi,

we are using icecream with 20 computers on our network.

It happens that some of the computers are low in memory because they are used by users.

Then, it happens that the compiler lacks of memory like this:

cc1plus: out of memory allocating 32768 bytes after a total of 3055616 bytes
ICECC[30838] 18:24:36: Compiled on xxx.xxx.xxx.xxx
make[1]: *** [/paht_to_object/out.o] Error 1

I would like icecream to either:

• try to compile once again with another computer
• try to compile locallly

instead of crashing...

I saw (in workit.cpp:477) that some memory errors are parsed to be treated as EXIT_OUT_OF_MEMORY... is it possible that by adding "out of memory allocating" as another string to find for and that all will be fine?

Thanks,

Eric

line 1 (and others): [Icecream](Icecream)
line 59: [openSUSE Icecream node LiveCD](http://forgeftp.novell.com/kiwi-ltsp/icecream/)
line 286: http://ktown.kde.org/~coolo/ppc-osx-create-i586.tar.gz
line 465: [SuSEfirewall2](SuSEfirewall2)

In daemon/workit.cpp the argv for the compiler execv call is created via strdup, which has to be freed.

I received a complaint from coworkers that when I bring my laptop from home to work, my coworkers' machines start sending too many compile jobs to it, because on their machines, my laptop appears to be the fastest machine on the network. But being an i5 instead of an i7 it's really not. I have an i7 at home too, so I'm not sure why the laptop thinks it's faster, but from observation of the icecream monitor, I get the impression that speed is a relative thing: the number varies wildly (the same machine might have 30 in one context and 300 in another), and only has meaning within the context of a particular group of machines which have been exchanging jobs in the recent past. So one idea is that if the machine stores its own speed rating, it should reset the rating whenever the network configuration changes, so that it no longer has an assumption about how fast it is. I could achieve this by restarting iceccd �when this happens (but that requires some investigation, how to get systemd to do that), but I don't think I should need to, because iceccd already knows when it has lost the connection to the scheduler. Would it be a great loss of efficiency in case of false alarms, if iceccd reset its own speed rating whenever it re-connects to a different scheduler?

Or is the problem rather that the other machines on the network have their own mistaken impression of my laptop's speed? Based on what, then?

I tested it at icecc version 0.9.5~1.0.9, Ubuntu 12.04 64bit

When a server's iceccd daemon send job packets, another server's iceccd daemons recieved packets will die immediately with segmentation fault log shown below.

But, I can't know exactly when iceccd is killed.
Please help me.

*** Segmentation fault
Register dump:

RAX: 0000000029a2e765 RBX: 00007fffd0bd6120 RCX: 00007ff529a2e738
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00007fffd0bd6120
RBP: 00007fffd0bd6170 R8 : 00007ff529a2e770 R9 : 0000000000000000
R10: 0000000000004000 R11: 0000000000000246 R12: 00007fffd0bd6450
R13: 000000000000002a R14: 0000000000000016 R15: 000000000085d090
RSP: 00007fffd0bd5f10

RIP: 000000000041d87b EFLAGS: 00010202

CS: 0033 FS: 0000 GS: 0000

Trap: 0000000e Error: 00000004 OldMask: 00000000 CR2: 00000078

FPUCW: 0000037f FPUSW: 00000000 TAG: 00000000
RIP: 00000000 RDP: 00000000

ST(0) 0000 0000000000000000 ST(1) 0000 0000000000000000
ST(2) 0000 0000000000000000 ST(3) 0000 0000000000000000
ST(4) 0000 0000000000000000 ST(5) 0000 0000000000000000
ST(6) 0000 0000000000000000 ST(7) 0000 0000000000000000
mxcsr: 1fa0
XMM0: 0000000000000000000000007f797d31 XMM1: 0000000000000000000000007f797d31
XMM2: 0000000000000000000000007f797d31 XMM3: 0000000000000000000000007f797d31
XMM4: 0000000000000000000000007f797d31 XMM5: 0000000000000000000000007f797d31
XMM6: 0000000000000000000000007f797d31 XMM7: 0000000000000000000000007f797d31
XMM8: 0000000000000000000000007f797d31 XMM9: 0000000000000000000000007f797d31
XMM10: 0000000000000000000000007f797d31 XMM11: 0000000000000000000000007f797d31
XMM12: 0000000000000000000000007f797d31 XMM13: 0000000000000000000000007f797d31
XMM14: 0000000000000000000000007f797d31 XMM15: 0000000000000000000000007f797d31

Backtrace:
/usr/sbin/iceccd[0x41d87b]
/usr/sbin/iceccd[0x40ec52]
/usr/sbin/iceccd[0x40cadc]
/usr/sbin/iceccd[0x40dd73]
/usr/sbin/iceccd[0x40df78]
/usr/sbin/iceccd[0x4067a7]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed)[0x7ff52969776d]
/usr/sbin/iceccd[0x406b69]

Memory map:

00400000-0042e000 r-xp 00000000 08:02 141484688 /usr/sbin/iceccd
0062e000-0062f000 r--p 0002e000 08:02 141484688 /usr/sbin/iceccd
0062f000-00630000 rw-p 0002f000 08:02 141484688 /usr/sbin/iceccd
0081b000-0083c000 rw-p 00000000 00:00 0 [heap]
0083c000-0099b000 rw-p 00000000 00:00 0 [heap]
7ff528c35000-7ff528c39000 r-xp 00000000 08:02 1240 /lib/x86_64-linux-gnu/libSegFault.so
7ff528c39000-7ff528e38000 ---p 00004000 08:02 1240 /lib/x86_64-linux-gnu/libSegFault.so
7ff528e38000-7ff528e39000 r--p 00003000 08:02 1240 /lib/x86_64-linux-gnu/libSegFault.so
7ff528e39000-7ff528e3a000 rw-p 00004000 08:02 1240 /lib/x86_64-linux-gnu/libSegFault.so
7ff528e3a000-7ff528e42000 r-xp 00000000 08:02 1251 /lib/x86_64-linux-gnu/libnss_compat-2.15.so
7ff528e42000-7ff529041000 ---p 00008000 08:02 1251 /lib/x86_64-linux-gnu/libnss_compat-2.15.so
7ff529041000-7ff529042000 r--p 00007000 08:02 1251 /lib/x86_64-linux-gnu/libnss_compat-2.15.so
7ff529042000-7ff529043000 rw-p 00008000 08:02 1251 /lib/x86_64-linux-gnu/libnss_compat-2.15.so
7ff529043000-7ff52904f000 r-xp 00000000 08:02 1249 /lib/x86_64-linux-gnu/libnss_files-2.15.so
7ff52904f000-7ff52924e000 ---p 0000c000 08:02 1249 /lib/x86_64-linux-gnu/libnss_files-2.15.so
7ff52924e000-7ff52924f000 r--p 0000b000 08:02 1249 /lib/x86_64-linux-gnu/libnss_files-2.15.so
7ff52924f000-7ff529250000 rw-p 0000c000 08:02 1249 /lib/x86_64-linux-gnu/libnss_files-2.15.so
7ff529250000-7ff529267000 r-xp 00000000 08:02 3669 /lib/x86_64-linux-gnu/libnsl-2.15.so
7ff529267000-7ff529466000 ---p 00017000 08:02 3669 /lib/x86_64-linux-gnu/libnsl-2.15.so
7ff529466000-7ff529467000 r--p 00016000 08:02 3669 /lib/x86_64-linux-gnu/libnsl-2.15.so
7ff529467000-7ff529468000 rw-p 00017000 08:02 3669 /lib/x86_64-linux-gnu/libnsl-2.15.so
7ff529468000-7ff52946a000 rw-p 00000000 00:00 0
7ff52946a000-7ff529474000 r-xp 00000000 08:02 1245 /lib/x86_64-linux-gnu/libnss_nis-2.15.so
7ff529474000-7ff529674000 ---p 0000a000 08:02 1245 /lib/x86_64-linux-gnu/libnss_nis-2.15.so
7ff529674000-7ff529675000 r--p 0000a000 08:02 1245 /lib/x86_64-linux-gnu/libnss_nis-2.15.so
7ff529675000-7ff529676000 rw-p 0000b000 08:02 1245 /lib/x86_64-linux-gnu/libnss_nis-2.15.so
7ff529676000-7ff52982b000 r-xp 00000000 08:02 1239 /lib/x86_64-linux-gnu/libc-2.15.so
7ff52982b000-7ff529a2a000 ---p 001b5000 08:02 1239 /lib/x86_64-linux-gnu/libc-2.15.so
7ff529a2a000-7ff529a2e000 r--p 001b4000 08:02 1239 /lib/x86_64-linux-gnu/libc-2.15.so
7ff529a2e000-7ff529a30000 rw-p 001b8000 08:02 1239 /lib/x86_64-linux-gnu/libc-2.15.so
7ff529a30000-7ff529a35000 rw-p 00000000 00:00 0
7ff529a35000-7ff529a4a000 r-xp 00000000 08:02 1071 /lib/x86_64-linux-gnu/libgcc_s.so.1
7ff529a4a000-7ff529c49000 ---p 00015000 08:02 1071 /lib/x86_64-linux-gnu/libgcc_s.so.1
7ff529c49000-7ff529c4a000 r--p 00014000 08:02 1071 /lib/x86_64-linux-gnu/libgcc_s.so.1
7ff529c4a000-7ff529c4b000 rw-p 00015000 08:02 1071 /lib/x86_64-linux-gnu/libgcc_s.so.1
7ff529c4b000-7ff529d46000 r-xp 00000000 08:02 1247 /lib/x86_64-linux-gnu/libm-2.15.so
7ff529d46000-7ff529f45000 ---p 000fb000 08:02 1247 /lib/x86_64-linux-gnu/libm-2.15.so
7ff529f45000-7ff529f46000 r--p 000fa000 08:02 1247 /lib/x86_64-linux-gnu/libm-2.15.so
7ff529f46000-7ff529f47000 rw-p 000fb000 08:02 1247 /lib/x86_64-linux-gnu/libm-2.15.so
7ff529f47000-7ff52a029000 r-xp 00000000 08:02 7260 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16
7ff52a029000-7ff52a228000 ---p 000e2000 08:02 7260 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16
7ff52a228000-7ff52a230000 r--p 000e1000 08:02 7260 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16
7ff52a230000-7ff52a232000 rw-p 000e9000 08:02 7260 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16
7ff52a232000-7ff52a247000 rw-p 00000000 00:00 0
7ff52a247000-7ff52a24b000 r-xp 00000000 08:02 45762 /usr/lib/libcap-ng.so.0.0.0
7ff52a24b000-7ff52a44a000 ---p 00004000 08:02 45762 /usr/lib/libcap-ng.so.0.0.0
7ff52a44a000-7ff52a44b000 r--p 00003000 08:02 45762 /usr/lib/libcap-ng.so.0.0.0
7ff52a44b000-7ff52a44c000 rw-p 00004000 08:02 45762 /usr/lib/libcap-ng.so.0.0.0
7ff52a44c000-7ff52a44e000 r-xp 00000000 08:02 1238 /lib/x86_64-linux-gnu/libdl-2.15.so
7ff52a44e000-7ff52a64e000 ---p 00002000 08:02 1238 /lib/x86_64-linux-gnu/libdl-2.15.so
7ff52a64e000-7ff52a64f000 r--p 00002000 08:02 1238 /lib/x86_64-linux-gnu/libdl-2.15.so
7ff52a64f000-7ff52a650000 rw-p 00003000 08:02 1238 /lib/x86_64-linux-gnu/libdl-2.15.so
7ff52a650000-7ff52a672000 r-xp 00000000 08:02 1254 /lib/x86_64-linux-gnu/ld-2.15.so
7ff52a859000-7ff52a85f000 rw-p 00000000 00:00 0
7ff52a86f000-7ff52a872000 rw-p 00000000 00:00 0
7ff52a872000-7ff52a873000 r--p 00022000 08:02 1254 /lib/x86_64-linux-gnu/ld-2.15.so
7ff52a873000-7ff52a875000 rw-p 00023000 08:02 1254 /lib/x86_64-linux-gnu/ld-2.15.so
7fffd0bb7000-7fffd0bd8000 rw-p 00000000 00:00 0 [stack]
7fffd0bff000-7fffd0c00000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]

I have looked at a few source files for your current software. I have noticed that some checks for return codes are missing.

Would you like to add more error handling for return values from functions like the following?

• strdup ⇒ work_it
• dup2 ⇒ setup_env_cache

I have tried following:
$ /usr/lib/icecc/icecc-create-env --clang /usr/bin/clang /usr/bin/clang++

Got error:
adding file /bin/true
adding file /lib/x86_64-linux-gnu/libc.so.6
adding file /lib64/ld-linux-x86-64.so.2
adding file /usr/bin/clang
adding file /usr/lib/x86_64-linux-gnu/libLLVM-3.2.so.1
adding file /lib/x86_64-linux-gnu/libpthread.so.0
adding file /usr/lib/x86_64-linux-gnu/libstdc++.so.6
adding file /lib/x86_64-linux-gnu/libgcc_s.so.1
adding file /usr/lib/x86_64-linux-gnu/libffi.so.6
adding file /lib/x86_64-linux-gnu/libdl.so.2
adding file /lib/x86_64-linux-gnu/libm.so.6
adding file /usr/bin/gcc=/usr/bin/clang++
adding file /usr/bin/g++=/usr/bin/clang++
adding file /usr/bin/as
adding file /usr/lib/libopcodes-2.23.2-system.so
adding file /usr/lib/libbfd-2.23.2-system.so
adding file /lib/x86_64-linux-gnu/libz.so.1
ls: cannot access include/: No such file or directory
adding file include/=
adding file /etc/ld.so.conf=/tmp/icecc_ld_so_conf6oI4gK
cp: cannot stat ‘include/=’: No such file or directory
/usr/bin/md5sum: /tmp/iceccenvFsemCo/nclude/=: No such file or directory
creating fe636d9e8ab1a7f4bae57dfdb0e3911b.tar.gz
tar: nclude/*=: Cannot stat: No such file or directory
tar: Exiting with failure status due to previous errors
Couldn't create archive

Any suggestion? Thanks in advance.

Thanks @ragner helped me to fix the issue to create clang package on Ubuntu 12.10 and 13.04 in #58 .

Now I have my clang package on my 13.04.

My settings for icecream is sth like:
export PATH=/usr/lib/icecc/bin:$PATH
export ICECC_VERSION=/home/liangqi/icecc-package-clang-3.2-1.tar.gz
alias make="make -j48"

When trying to build my project, I got error like:
ICECC[22143] 14:36:46: write of source chunk to host 10.9.70.97
ICECC[22143] 14:36:46: failed Resource temporarily unavailable
ICECC[22143] 14:36:46: got exception 15 (10.9.70.97)

ICECC[22750] 14:36:56: no server found behind given hostname 10.0.0.1:10245
ICECC[22750] 14:36:56: got exception 2 (10.0.0.1)

ICECC[25699] 14:39:17: write of source chunk to host 10.9.70.97
ICECC[25699] 14:39:17: failed Broken pipe
ICECC[25699] 14:39:17: got exception 15 (10.9.70.97)

clang++ -c -pipe -O2 -fPIC -fno-exceptions -Wall -W -D_REENTRANT -DQT_NO_LIBUDEV -DQT_NO_XKB -DQT_BOOTSTRAPPED -DQT_LITE_UNICODE -DQT_NO_CAST_TO_ASCII -DQT_NO_CODECS -DQT_NO_DATASTREAM -DQT_NO_LIBRARY -DQT_NO_QOBJECT -DQT_NO_SYSTEMLOCALE -DQT_NO_THREAD -DQT_NO_UNICODETABLES -DQT_NO_USING_NAMESPACE -DQT_NO_DEPRECATED -DQT_NO_TRANSLATION -DQT_QMAKE_LOCATION="/home/liangqi/build/qt5-clang/qtbase/bin/qmake" -DQT_CRYPTOGRAPHICHASH_ONLY_SHA1 -DQT_NO_CAST_FROM_ASCII -DQT_BUILD_BOOTSTRAP_LIB -DQT_BUILDING_QT -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS -DQT_DISABLE_DEPRECATED_BEFORE=0x050000 -DQT_NO_EXCEPTIONS -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_NO_DEBUG -I/home/liangqi/qt/qt5/qtbase/mkspecs/linux-clang -I/home/liangqi/qt/qt5/qtbase/src/tools/bootstrap -I../../../include -I../../../include/QtCore -I../../../include/QtCore/5.1.0 -I../../../include/QtCore/5.1.0/QtCore -I../../../include/QtXml -I/home/liangqi/build/qt5-clang/qtbase/include/QtXml/5.1.0 -I/home/liangqi/build/qt5-clang/qtbase/include/QtXml/5.1.0/QtXml -I../../corelib/global -I/home/liangqi/qt/qt5/qtbase/src/3rdparty/zlib -I. -o .obj/debug-shared/qvector.o /home/liangqi/qt/qt5/qtbase/src/corelib/tools/qvector.cpp
g++: error: no such file or directory: 'clang'
ICECC[25763] 14:39:18: Compiled on 10.9.70.97

And I checked with icemon, this build was not displayed there. I tried similar build from same machine with gcc and package, it works fine.

Any suggestion for this clang build on linux? Thanks in advance.

I use RHEL 6.1 as a icecc daemon and RHEL 6.2 as a icecc scheduler. After iceccd start the multiple lines are appeared in iceccd log:

9341] 18:48:00: scheduler is on 192.168.1.42:8765 (net )
[9341] 18:48:00: scheduler not yet found.
[9341] 18:48:03: reconn Node Name: hostname

All builds are local. I've disabled iptables on both sides but result is still the same. I have a secondary icecc-scheduler running on other host. It works perfectly but when I try to connect icecc daemon from RHEL 6.1 host the result is also negative. What can be possible reason for this?

icecream version 1.0.1
File: services/comm.cpp

In method get_netnames() at line number 1242, argument is negative to close() function.
ask_fd should be checked for negative value before passing it to close() function.
Suggested patch:

Create virtualmachines with different OSes to test changes.

We have a setup where groups on the same physical subnet want to use different ice cream schedulers. This is what the netname parameter should be for. However two of the servers are detecting the third has a better startime/version and disconnecting all the clients despite different net names.

scheduler/scheduler.cpp does not check for netname at all when disconnecting daemons (the broadcase packet doesn't have such a field)

This is an idea from Arun Raghavan (https://bugzilla.redhat.com/show_bug.cgi?id=1229618):

It would be nice if iceccd on laptops only runs when we are on A/C power.
We probably don't want random compile jobs to be scheduled on our laptop
when we're running on battery.

The daemon should write in a file (for example /var/run/icecc/number-of-processors) so that build scripts could read that file in run-time and decide the proper -j value for make/ninja or whatever build system you are using.

Experimenting with running multiple schedulers with 1.1rc1, I discovered that on any machine that is running a scheduler locally, iceccd will never discover any other scheduler on the network. The scheduler on localhost does see the other scheduler and disconnects everyone, but iceccd on that host will always reconnect to the local scheduler, not the better one on a different machine. Daemons on machines on different networks seem to work correctly.

Running scheduler -vv I see the following in the log:
[20423] 16:01:35: ICECREAM scheduler 1.0.98 starting up, port 8765
[20424] 16:01:35: broadcast eth0 10.140.160.127
[20424] 16:01:35: broadcast from 10.140.160.34:58982 (version 34)
[20424] 16:01:35: broadcast from 10.140.160.34:58890 (version 34)
[20424] 16:01:35: broadcast from 10.140.160.34:57476 (version 29)
[20424] 16:02:11: Scheduler from 10.140.160.15:43476 (version 34) has announced itself as a preferred scheduler, disconnecting all connections.
[20424] 16:02:11: remove daemon [hostname removed]

and iceccd running -vv shows the following
[20436] 16:01:35: Suitable scheduler found at 10.140.160.34:8765 (version: 34)
[20436] 16:01:35: scheduler is on 10.140.160.34:8765 (net ICECREAM)
[20436] 16:01:35: scheduler not yet found.
[20436] 16:01:38: Connected to scheduler (I am known as 10.140.160.34)
[20436] 16:02:11: scheduler closed connection
[20436] 16:02:38: broadcast eth0 10.140.160.127
[20436] 16:02:38: scheduler not yet found.
[20436] 16:02:38: Suitable scheduler found at 10.140.160.34:8765 (version: 34)
[20436] 16:02:38: scheduler is on 10.140.160.34:8765 (net ICECREAM)
[20436] 16:02:38: scheduler not yet found.
[20436] 16:02:41: Connected to scheduler (I am known as 10.140.160.34)

I would suggest the scheduler not respond to broadcasts when it thinks there is a better scheduler, but still listen, if there is a timeout it should take over.

The documentation states that for icecream to work in heterogeneous environments, the daemon must run as root. However, the daemon goes out of its way to prevent users from running it as root:

    if (getuid() == 0) {
        struct passwd *pw = getpwnam("icecc");

Could you please clarify then what is the proper way of using icecream in het.environments?