yut148 / toolwhip Goto Github PK

Good evening fellow-WebKit/Chromium folks,

I'm following a similar project
I'm glad to see someone working on new-distcc-xcode integration.
I'm working on a similar project, but with Cygwin.

I already have a working cross-compiler to build Mac OS X 10.5 binaries 
using Cygwin/XP. It even works using distcc from a remote machine, but 
only for make based buildsystems. I stumbled accross your project and I'm 
just trying to get it working on Cygwin.

I'll attach a simple patch which makes it possible to compile the toolwhip-
distcc (the modern version with pump support) on Cygwin.

Keep up the good work.
If anyone is interessed, I could provide my HOWTO to setup Cygwin/XP <-> 
Mac OS X 10.5 cross-compile guide.

Cheers,
Niko ([email protected])

Currently, distccd runs two Avahi threads when configured with Avahi for 
zeroconf support, when configured with --enable-xcode-integration, and 
when run in --zeroconf mode.  One Avahi thread is for "normal" distcc 
zeroconf, and the other is for Xcode-style distcc zeroconf.

When both Avahi threads are running, distccd will crash.  Generally, the 
crashes occur when attempting to free a bad pointer.  The stacks implicate 
either Avahi or DBus, an Avahi dependency.  Disabling one Avahi thread 
(the "normal" distccd zeroconf registration) eliminates the crashes, so it 
appears likely that there's some sort of global state that is not intended to 
be shared between two Avahi threads.

I experienced similar problems when adding xci_zeroconf: when using 
Avahi, stopping both threads generally caused crashes.  I removed the 
code to stop the xci_zeroconf Avahi thread because of this, and because in 
normal operation, it wouldn't be hit anyway.

To resolve this problem properly, we should only run a single Avahi thread 
to register both types of zeroconf advertisements.

On some of the bots, we end up waiting for the distcc timeout before the 
build runs locally.  The default timeout is 5minutes, which is longer then the 
build should be.  So it would be nice to turn the timeout into something that 
can be controlled via an environ var so it can be lowered.

It would be cool if toolwhip could be updated to Lion and the developer Tools 
4.1 : http://www.opensource.apple.com/release/developer-tools-41/

Meaning gcc-5666.3, distcc-2503 and ld64-123.2.1

Regards Marco

What steps will reproduce the problem?
1. Pull http://toolwhip.googlecode.com/svn/trunk revision 176
2. Follow the steps in gcc_42-5574.README

What is the expected output? What do you see instead?

EXPECTED: Everything builds

ACTUAL: When executing this part:

for i in gcc g++ ; do
  gcc -m32 -O2 -I../usr_include -I../gcc_42-5574/include -I../gcc_42-5574/gcc \
    -I../gcc_42-5574/gcc/config -D__LITTLE_ENDIAN__ \
    "-DPDN=\"-apple-darwin9-$i-4.2.1\"" ../gcc_42-5574/driverdriver.c \
    -Llibiberty -liberty -o $i-4.2
done

I get:

/tmp/cc1xyQGi.o: In function `get_arch_name':
driverdriver.c:(.text+0x123c): undefined reference to `NXGetArchInfoFromName'
driverdriver.c:(.text+0x1247): undefined reference to `NXGetAllArchInfos'
driverdriver.c:(.text+0x1278): undefined reference to `NXGetLocalArchInfo'
collect2: ld returned 1 exit status
/tmp/ccm47pff.o: In function `get_arch_name':
driverdriver.c:(.text+0x123c): undefined reference to `NXGetArchInfoFromName'
driverdriver.c:(.text+0x1247): undefined reference to `NXGetAllArchInfos'
driverdriver.c:(.text+0x1278): undefined reference to `NXGetLocalArchInfo'
collect2: ld returned 1 exit status

What steps will reproduce the problem?
1. Try to follow the gcc_42-5574.README steps

What is the expected output? What do you see instead?

EXPECTED: compile gcc

ACTUAL: errors out because there is no gcc source

What version of the product are you using? On what operating system?
http://toolwhip.googlecode.com/svn/trunk/ revision 176

Please provide any additional information below.

It looks like the apple gcc_42 packages are at
http://www.opensource.apple.com/tarballs/gcc_42/ at the moment.  Might be
good to add this to the readme.

The toolwhip toolchain is now 1 1/2 years old, a refurbishment to a recent 
MacOSX-10.6 toolchain is highly appreciated.

Moreover, I'd like to helpbuilding up a debian repository with a darwin 
cross-compiler with many libraries ported to to this toolchain.

An example of such a toolchain is our mingw cross-compiler toolchain under

http://www.clazzes.org/projects/mingw-debian-packaging/

  Best regards, Wolfgang

What steps will reproduce the problem?
1. svn checkout http://toolwhip.googlecode.com/svn/trunk/ toolwhip-read-only  
2. Try to follow the ld64 README

What is the expected output? What do you see instead?

EXPECTED: Builds

ACTUAL: Fails because various stdio functions are not defined.  Including
stdio.h from Options.h makes everything work.

What version of the product are you using? On what operating system?

Revision 176 of the above package, on FC12.

1. Got SDKs and headers from a Mac running XCode 3, 10.5
2. Following READMES, compiled cctools and ld64 on Gentoo host
3. Followed readme for gcc, getting source from Apple's open source page
4. During 'make' of gcc for i386, got a warning about a buffer overflow being 
detected and build fails.

Seems to fail while archiving libgcov.a.

Using Revision 177.

rm -f ./libgcov.a
i686-apple-darwin9-ar  rc ./libgcov.a libgcc/./_gcov.o 
libgcc/./_gcov_merge_add.o libgcc/./_gcov_merge_single.o 
libgcc/./_gcov_merge_delta.o libgcc/./_gcov_fork.o libgcc/./_gcov_execl.o 
libgcc/./_gcov_execlp.o libgcc/./_gcov_execle.o libgcc/./_gcov_execv.o 
libgcc/./_gcov_execvp.o libgcc/./_gcov_execve.o 
libgcc/./_gcov_interval_profiler.o libgcc/./_gcov_pow2_profiler.o 
libgcc/./_gcov_one_value_profiler.o
*** buffer overflow detected ***: /Developer/usr/bin/ranlib terminated
======= Backtrace: =========
/lib32/libc.so.6(__fortify_fail+0x48)[0x55667418]
/lib32/libc.so.6[0x55665460]
/lib32/libc.so.6[0x55664ae8]
/lib32/libc.so.6(_IO_default_xsputn+0xa0)[0x555e91e0]
/lib32/libc.so.6(_IO_padn+0xd0)[0x555dc680]
/lib32/libc.so.6(_IO_vfprintf+0x1213)[0x555bc943]
/lib32/libc.so.6(__vsprintf_chk+0xa7)[0x55664b97]
/lib32/libc.so.6(__sprintf_chk+0x2d)[0x55664add]
/Developer/usr/bin/ranlib[0x804b752]
/Developer/usr/bin/ranlib[0x804cd3e]
/Developer/usr/bin/ranlib[0x804d57d]
/lib32/libc.so.6(__libc_start_main+0xe5)[0x55594a65]
/Developer/usr/bin/ranlib[0x8048eb1]
======= Memory map: ========
08048000-0806f000 r-xp 00000000 08:03 48960                              
/Developer/usr/bin/libtool
0806f000-08070000 r--p 00026000 08:03 48960                              
/Developer/usr/bin/libtool
08070000-08071000 rw-p 00027000 08:03 48960                              
/Developer/usr/bin/libtool
0948b000-094ac000 rw-p 00000000 00:00 0                                  [heap]
55555000-55571000 r-xp 00000000 08:03 538130                             
/lib32/ld-2.10.1.so
55571000-55572000 r--p 0001c000 08:03 538130                             
/lib32/ld-2.10.1.so
55572000-55573000 rw-p 0001d000 08:03 538130                             
/lib32/ld-2.10.1.so
55573000-55574000 r-xp 00000000 00:00 0                                  [vdso]
55574000-55575000 rw-p 00000000 00:00 0
5557e000-556c0000 r-xp 00000000 08:03 538117                             
/lib32/libc-2.10.1.so
556c0000-556c2000 r--p 00142000 08:03 538117                             
/lib32/libc-2.10.1.so
556c2000-556c3000 rw-p 00144000 08:03 538117                             
/lib32/libc-2.10.1.so
556c3000-556c7000 rw-p 00000000 00:00 0
556c7000-556db000 rw-p 00000000 08:03 425952                             
/path/to/toolwhip-read-only/gcc.i386.obj/gcc/libgcov.a (deleted)
556db000-556e7000 r-xp 00000000 08:03 547143                             
/lib32/libgcc_s.so.1
556e7000-556e8000 r--p 0000b000 08:03 547143                             
/lib32/libgcc_s.so.1
556e8000-556e9000 rw-p 0000c000 08:03 547143                             
/lib32/libgcc_s.so.1
ffc6c000-ffc83000 rw-p 00000000 00:00 0                                  [stack]
i686-apple-darwin9-ar: fatal error in /Developer/usr/bin/ranlib
make[3]: *** [libgcov.a] Error 1
make[3]: Leaving directory `/path/to/toolwhip-read-only/gcc.i386.obj/gcc'
make[2]: *** [stmp-multilib] Error 2
make[2]: Leaving directory `/path/to/toolwhip-read-only/gcc.i386.obj/gcc'
make[1]: *** [all-gcc] Error 2
make[1]: Leaving directory `/path/to/toolwhip-read-only/gcc.i386.obj'
make: *** [all] Error 2


Searching for similar errors elsewhere, it seems that there is some flag that 
might get set on ar to catch these things and seems to be somewhat common when 
building toolchains, but I found no solutions.

Xcode doesn't include localhost in the cpu pool, so it sends everything out not 
really using the local 
host.  The workaround is to put localhost into a pool of cpus, but that doesn't 
completely work, then 
you end up:

  setenv DISTCC_HOSTS "--randomize localhost:0,lzo,cpp/0"

That "/0" is probably what screws them up, we probably need to double check our 
distcc handles 
both of those and tweak accordingly also.

distccd --host-info (xci) returns JOBS= and CPUS= lines, reflecting the 
number of jobs (default ncpus+2) and number of CPUs in the system.  Xcode 
(xcodebuild), when setting the DISTCC_HOSTS environment variable, only 
seems to respect the CPUS= line, setting the number of slots on a host to 2 
more than the value reported in CPUS=.  When a distccd server is intentionally 
configured to permit fewer jobs, Xcode may flood that server with requests to 
compile things.

Xcode should be fixed.

In the mean time, to help users avoid problems that might be caused by 
dispatching too many jobs to a single distccd server, we might want to 
provide a command-line option to change the value reported in CPUS=.

On a CentOS 5.3 system, I have no 
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq.  This is causing 
messages like this:

distccd[11151] (dcc_cpuspeed) ERROR: open cpuinfo_max_freq failed: No such 
file or directory

This causes --host-info to fail to report a CPUSPEED line.  This appears to be 
harmless and won't cause Xcode to discard the potential distccd server.

I believe this is because the acpi_cpufreq kernel module is not loaded on this 
system.  We should still be able to pull the frequency from /proc/cpuinfo.