build failed

[GoogleCodeExporter]

i compiled the toolchain and this is the output: 
...
Build progress logged to: toolchain/bld/cctools-iphone/make.log 
Build & install failed. Check make.log and install.log

i use ubuntu 8.10 server edition..

please help me!!

Original issue reported on code.google.com by itsf...@gmail.com on 31 Mar 2009 at 5:43

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Hi itsfall, can you please provide the make.log for cctools-iphone?

Original comment by m4d...@gmail.com on 5 Apr 2009 at 6:46

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Fix for this problem:

sudo apt-get install gobjc
cd toolchain/bld/cctools-iphone/
./config.status --recheck
make clean
cd ../../../
./toolchain.sh build

Original comment by axelmoll...@gmail.com on 20 Apr 2009 at 8:58

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Thanks for the fix axelmoller5. It seems like the Objective-C compiler detection
isn't working on itsfall's system.

Original comment by m4d...@gmail.com on 21 Apr 2009 at 9:03

• Changed state: Accepted

[GoogleCodeExporter]

Same problem + fix on ubuntu 9.04

Original comment by Maurice....@gmail.com on 23 May 2009 at 9:59

[GoogleCodeExporter]

./config.status = no such file or directory, help?

Original comment by ackdrumm...@aol.com on 17 Aug 2009 at 8:03

[GoogleCodeExporter]

Just make sure you have gobjc installed and restart the whole process: the 
result is 
the same. It's a localisation bug relating to checking for objective c support 
by 
sniffing some output. Not fixed because the project has been dead for some 
time. I 
suspect once you have completed the build you won't find it very useful, sorry.

Original comment by m4d...@gmail.com on 17 Aug 2009 at 8:11

[GoogleCodeExporter]

could the problem be that i am using the 3.0 sdk for lack of availability of 
the 2.2.1?

Original comment by ackdrumm...@aol.com on 17 Aug 2009 at 8:26

[GoogleCodeExporter]

I think it's unlikely to be the problem, I think once you get to the compile 
stage it's going to fail anyway 
since there are several patches to the code which are version specific. If you 
like, create a new bug which 
explains exactly what's going wrong when you try to compile for 3.0 and I'll 
try to work it out, which might 
help anyone else trying the same.

You might be better to use an older version of the firmware (check the top of 
the script to set the target 
version), although the corresponding SDKs are impossibly hard to track down. 
You might try this:
http://isohunt.com/torrent_details/110108489/iphone+sdk+"2.2"?tab=summary

This is all theoretical, after you manage to get all this working there's a 
whole other step of getting some 
actually useful headers which was never finished. You're going to find what 
this tool spits out really limited 
unfortunately until the classdump fixes come around, which won't be for a long 
time (if ever). Just want to 
make sure you know the situation before you spend hours trying to get this 
working.

Original comment by m4d...@gmail.com on 17 Aug 2009 at 8:37

[GoogleCodeExporter]

understood. went to sauriks site (one of them at least) it says he's checking 
the
legality of making something like this for linux for the 3.0 firmware. lets 
hope its
done soon. i hope steve jobs (or who ever replaced him) grows a pair, and makes 
xcode
for windows or linux. i mean windows can be run on mac but not vice versa. 
thats one
of the few things i will ever give windows over mac... *sigh* time for bed its
4:48... another sleepless hopeful night gone to waste...

Original comment by ackdrumm...@aol.com on 17 Aug 2009 at 8:49

[GoogleCodeExporter]

Steve Jobs' pair growth notwithstanding, the situation is more that Apple 
maintain quality by 
reducing the variables. If they distributed XCode for Windows or Linux, they 
would have to 
support it which would require enormous resources and expenditure. I wouldn't 
bank on any of 
Apple's dev tools ever being available for any other OS, for all kinds of other 
reasons too. 
Saurik's page is incredibly out of date and I think either he's lost interest 
in the package 
idea, the legal issue was never resolved, or some new event has arisen that I'm 
not aware of 
(not unlikely).

Your best bet to get any development done is to find the toolchain package in 
Cydia, install 
that, and build on your iPhone. As far as I know that still works and is the 
main way people 
develop "jailbroken" apps. If you get particularly tricky you could likely 
write some build 
routines for your IDE which would copy to and build on the iPhone itself and in 
the end it would 
be seamless, if a tiny bit slow.

Original comment by m4d...@gmail.com on 17 Aug 2009 at 9:02

[GoogleCodeExporter]

cydia is based on bsd sorta. do you think its possible to add cydia as a source 
and
install the toolchain from there to linux? they both (at least mine using 
ubuntu)
were debian at one point or another and support debian. is it worth a shot?

Original comment by ackdrumm...@aol.com on 17 Aug 2009 at 9:15

[GoogleCodeExporter]

The similarities are only conceptual and the BSD programs are just a standard 
set of Unix tools, which doesn't indicate 
anything more than they follow the same rough idea. In reality the software was 
built for a completely different 
architecture, OS, set of libraries etc. Really it would be the equivalent of 
trying to run OSX PowerPC apps on a regular 
x86 Debian box (for instance). Cydia supports the Debian package format - from 
what I've seen - and probably the general 
system of managing them, but Debian packages are just glorified gzip files with 
installation scripts and something that 
keeps track of them and their dependencies (gross understatement but I'm trying 
to emphasise a point :p). The software 
inside the compressed file still won't run on a system it wasn't built for.

Actually, the reason you can't do it is the same reason we need the toolchain 
in the first place. You need to compile 
the source code into a binary format that will be executed on the target 
machine. Because of the way CPUs and just 
general hardware differ you need to be really specific about the target 
platform, but also you need to be sure that the 
libraries you compiled against will be there too and a bunch of other things.

So unfortunately that won't work. 

Original comment by m4d...@gmail.com on 17 Aug 2009 at 9:39