Open GoogleCodeExporter opened 8 years ago
Original comment by nightwat...@gmail.com
on 15 Sep 2007 at 1:44
I get this too with cygwin, I'm trying MinGW now.
Original comment by geo...@gmail.com
on 17 Sep 2007 at 8:32
[deleted comment]
Looks like the -I../include/foreign pulls in odcctools/include/i386/types.h and
defines _MACHTYPES_H_, so cygwin never parses /usr/include/machine/types.h which
contains clock_t and time_t. This patch to gets through this file, but the
next file
has the reverse problem: type.h loads from the cygwin-side first...
[Add to odcctools/include/i386/types.h after #include]:
#ifdef __CYGWIN__
// Define non-BSD types that Cygwin is expecting.
#define _CLOCK_T_ unsigned long /* clock() */
#define _TIME_T_ long /* time() */
#define _CLOCKID_T_ unsigned long
#define _TIMER_T_ unsigned long
typedef long int __loff_t;
// Inform Cygwin that basic types have been defined BSD-style.
#define __int8_t_defined
#define __vm_offset_t_defined
#define __vm_size_t_defined
#endif
Original comment by martinturon
on 23 Sep 2007 at 11:42
This revision will compile farther, but it is neither clean nor complete:
[Add to odcctools/include/i386/types.h after #include]:
#ifdef __CYGWIN__
// Define non-BSD types that Cygwin is expecting.
#define _CLOCK_T_ unsigned long /* clock() */
#define _TIME_T_ long /* time() */
#define _CLOCKID_T_ unsigned long
#define _TIMER_T_ unsigned long
// Inform Cygwin that basic types have been defined BSD-style.
#define __vm_offset_t_defined
#define __vm_size_t_defined
typedef long int __loff_t;
#ifdef __int8t_defined
// Force Cygwin to foreign INT definitions
#define __int8_t_defined
#else
// Use Cygwin INT definitions
#define _INT8_T
#define _INT16_T
#define _INT32_T
#endif
#endif //__CYGWIN__
Original comment by martinturon
on 23 Sep 2007 at 12:11
Thanks Martin...after your suggestion, it does get a little farther, but alas,
still
fails compilation:
$ make
cd libstuff && make
make[1]: Entering directory `/home/ahmiller/iphone-dev/odcctools/libstuff'
gcc -Wall -Wno-import -DHAVE_CONFIG_H -D__LITTLE_ENDIAN__=1 -I../include -I..
/include -include ../include/extern.h -I../include/foreign -g -O2 -fno-builtin-r
ound -fno-builtin-trunc -c -o errors.o errors.c
In file included from /usr/include/cygwin/types.h:21,
from /usr/include/sys/types.h:373,
from /usr/include/stdio.h:46,
from errors.c:26:
/usr/include/stdint.h:20: error: conflicting types for 'int32_t'
../include/i386/types.h:82: error: previous declaration of 'int32_t' was here
In file included from ../include/foreign/machine/endian.h:32,
from ../include/mach/mach_traps.h:72,
from ../include/mach/mach_init.h:75,
from ../include/mach/mach.h:64,
from errors.c:29:
../include/i386/endian.h:86:1: warning: "LITTLE_ENDIAN" redefined
In file included from /usr/include/cygwin/types.h:22,
from /usr/include/sys/types.h:373,
from /usr/include/stdio.h:46,
from errors.c:26:
/usr/include/endian.h:28:1: warning: this is the location of the previous defini
tion
In file included from ../include/foreign/machine/endian.h:32,
from ../include/mach/mach_traps.h:72,
from ../include/mach/mach_init.h:75,
from ../include/mach/mach.h:64,
from errors.c:29:
../include/i386/endian.h:87:1: warning: "BIG_ENDIAN" redefined
In file included from /usr/include/cygwin/types.h:22,
from /usr/include/sys/types.h:373,
from /usr/include/stdio.h:46,
from errors.c:26:
/usr/include/endian.h:29:1: warning: this is the location of the previous defini
tion
In file included from ../include/foreign/machine/endian.h:32,
from ../include/mach/mach_traps.h:72,
from ../include/mach/mach_init.h:75,
from ../include/mach/mach.h:64,
from errors.c:29:
../include/i386/endian.h:88:1: warning: "PDP_ENDIAN" redefined
In file included from /usr/include/cygwin/types.h:22,
from /usr/include/sys/types.h:373,
from /usr/include/stdio.h:46,
from errors.c:26:
/usr/include/endian.h:30:1: warning: this is the location of the previous defini
tion
In file included from ../include/foreign/machine/endian.h:32,
from ../include/mach/mach_traps.h:72,
from ../include/mach/mach_init.h:75,
from ../include/mach/mach.h:64,
from errors.c:29:
../include/i386/endian.h:90:1: warning: "BYTE_ORDER" redefined
In file included from /usr/include/cygwin/types.h:22,
from /usr/include/sys/types.h:373,
from /usr/include/stdio.h:46,
from errors.c:26:
/usr/include/endian.h:31:1: warning: this is the location of the previous defini
tion
errors.c:135: warning: visibility attribute not supported in this configuration;
ignored
make[1]: *** [errors.o] Error 1
make[1]: Leaving directory `/home/ahmiller/iphone-dev/odcctools/libstuff'
make: *** [libstuff] Error 2
Original comment by aaronmiller@gmail.com
on 24 Sep 2007 at 8:39
Martin I'm trying to understand what you meant by this code here :
#ifdef __int8t_defined
// Force Cygwin to foreign INT definitions
#define __int8_t_defined
#else
// Use Cygwin INT definitions
#define _INT8_T
#define _INT16_T
#define _INT32_T
#endif
what is the '__int8t_defined' versus '__int8_t_defined'? I tried changing the
code to
this :
#ifndef __int8_t_defined
// Force Cygwin to foreign INT definitions
#define __int8_t_defined
#else
// Use Cygwin INT definitions
#define _INT8_T
#define _INT16_T
#define _INT32_T
#endif
That seems like what you may have intended. It fixes some of the problems but
there
were several warnings and another error.
odcctools/libstuff/bytesex.c
In file included from /usr/include/sys/types.h:373,
from ../../../odcctools/include/mach-o/ranlib.h:28,
from ../../../odcctools/libstuff/bytesex.c:207
/usr/include/cygwin/types.h:195: error: conflicting types for 'register_t'
../../../odcctools/include/i386/types.h:120: error: previous declaration of
'register_t' was here
But it doesn't say where it was :P
Original comment by leyl...@gmail.com
on 2 Oct 2007 at 1:31
I was looking up what odcctools is and if any one has built it under cygwin, I
cam
across this page...
http://labs.docudesk.com/latest-technologies/2007/5/8/macos-target-gcj-create-ma
ctelppc-binaries-from-os-x-linux-and-cygwin.html
...don't have time to look into it further though.
Original comment by leyl...@gmail.com
on 2 Oct 2007 at 1:48
This docudesk.com instructions basically work (except that OpenDarwin project
closed
and you need to replace odcctools URL in Makefile for, say,
http://biolpc22.york.ac.uk/pub/linux-mac-cross/odcctools-20060413.tar.bz2), but
they
use older, simpler version of odcctools, which do not include conflicting
types.h file.
And they do not build the freshest GNU C/C++, but it is OK - they build i386/PPC
odcctools at least.
I am trying to analyze differences between older odcctools and the ones from
iphone-dev project.
Original comment by vic...@gmail.com
on 2 Oct 2007 at 5:28
How can I join project?
Original comment by vic...@gmail.com
on 3 Oct 2007 at 6:36
odcctools built successfully.
There are several problems, most harmful is clash of
odcctools/include/foreign/machine with native Cygwin machine include
directories.
Patch can not remove/rename directories, so you need to do it manually:
cd odcctools
patch -p0 <odcctools_cygwin.patch
mv include/foreign/machine include/foreign/_machine
then cd ../build/odcctools
configure, make, make install
You're here!
Original comment by vic...@gmail.com
on 5 Oct 2007 at 5:05
Attachments:
Am I the first having built the toolkit under Cygwin? ;-)
It actually built without a hitch after odcctools patch.
Testing how it compiles iPhone apps.
Original comment by vic...@gmail.com
on 5 Oct 2007 at 6:27
nice work, guys.
lucky me, i first tried after you published the patch ;)
odcctools builds in cygwin, just do not leave odcctools directory as supposed
in the
main build instructions.
let's head on to the next traps.
Original comment by naughty....@gmail.com
on 7 Oct 2007 at 9:25
I managed to build Motion app from http://lucasnewman.com/phonedemos.zip, but I
needed to copy GraphicsServices.h from Berlios repository at:
http://svn.berlios.de/svnroot/repos/iphone-binutils/trunk
Somehow it contains fresher version with more functions defined.
Also I found that there is probably some deficiency in Objective-C compiler.
It does not like construct:
LKTransform sublayerTransform = LKTransformIdentity;
where LKTransfromIdentity is defined in LayerKit/LKTransform.h as
extern LKTransform LKTransformIdentity;
It complains
FlipACoinApp.m:19: error: initializer element is not constant
Is it known bug?
Original comment by vic...@gmail.com
on 8 Oct 2007 at 6:23
It builds FlipACoin, include GraphicsServices was missed in the source.
Original comment by vic...@gmail.com
on 9 Oct 2007 at 5:14
In attach you can find logs for my install session toolchain on CygWin.
I worry about 2 things:
1. I have many warnings(see attach for logs) when build toolchain. is they are
critical?
2. Size of executables of test apps(iphonedemos from Lucas Newman with modified
makefile) differ from size of apps builded on CygWin. Also i'm warry about this.
On early builds toolchain i compile FlipACoin, and the executable runs on
iPhone
extremely fast and don't play animation with sunbeams.
My working toolchain based on llvm rev.42269. Test apps in attach build on it.
Original comment by yo.l...@gmail.com
on 23 Oct 2007 at 9:15
Attachments:
Hard to tell - you enclosed so many files, many of them are not even logs, that
signal/noise ratio is not very high. From what I've seen, there are many benign
warnings. Some warnings are for real deficiencies of the programs, but it is
not my
job to fix them.
Executable sizes - many exes are still built with toolchain 0.20 on MacOS or
Linux.
They use different backend version and so must be different, the point is they
are
running.
FlipACoin - yea, you;re right, I have the sunbeams, but in very fast manner. I
will
look at the code, how the animation is implemented. I just built the toolchain
and
verified that it builds some stuff. I don't have many iPhone programs,
especially
really complicated ones to test toolchain.
For some time nobody was even interested in Cygwin port at all, so I stopped
actively
working on it.
Original comment by vic...@gmail.com
on 25 Oct 2007 at 9:25
victzh, Thank you for the odcctools patch it worked like a charm.
I had already compiled odcctools and I'm now stopped on the last step. OMG, I'm
almost there.
When I ran the command "make LLVM_VERSION_INFO=2.0-svn-iphone-dev-0.3-svn"
after 35
minutes it give me an error. "... -lc".
I've checked LLVMOBJDIR and HEAVENLY and the symlinks into iPhone paths.
My question is simple, are you finished to compile the toolchain and build any
HelloWorld to make sure it works in cygwin?
If you have any tip in my problem it will be appreciated.
Original comment by igorcha...@gmail.com
on 6 Nov 2007 at 2:19
I followed the instruction from here:
http://iphone.fiveforty.net/wiki/index.php/Toolchain_installation_-_Windows
However, when i tried to run ./configure. I have got the following errors:
/home/llvm-svn
$'r':command not found
syntax error near the unexpected token 'new line'
Any ideas what could be the problem?
Original comment by eln...@gmail.com
on 7 Nov 2007 at 4:15
[deleted comment]
Hello, I followed the same instructions on iphone.fiveforty.net, but I'm having
trouble with the Mac OSX Headers.
On the Apple Tools download page, I have a choice between XCode 3.0 and XCode
2.5.
Nowhere in the instructions does it say which one I need for IPhone dev ??
I've tried downloading the XCode 3.0 and I can extract the PKG files using
HFSExplorer or TransMac. Strangely everyone in here talks of these files as
directories?? I am unable to extract headers from the PKG files on windows or in
Cygwin. None of the mentioned tools will do it.
Please tell me how to extract files from PKG so I can get at the .pax.gz header
files! This step is missing from the instructions.
Original comment by anders.e...@gmail.com
on 7 Nov 2007 at 1:23
Anders, I took XCode 2.5, since 3.0 seemed specifically for Leopard. Then dug
into
the .dmg with TransMac and copied out the Archive.pax.gz file from the
MacOSX10.4.Universal.pkg/Contents dir and followed the advice from the main
instructions to pull out the headers. You'll have to replace some of the links
to
certain libraries with the actual libraries...things must work differently in
Cygwin
than other platforms. Good luck!
Original comment by aaronmiller@gmail.com
on 9 Nov 2007 at 5:44
Thanks a bunch, Aaron, this information would have saved me some hours of
frustration
since the XCode 3.0 dmg file contains PKG files instead of folders and there is
apparently no way of extracting these archives on a windows PC even with
cygwin...
(correct me if I'm wrong).
Thanks to victzh's patch file I've now been able to compile and install
everything
for iphone dev and hopefully I can compile and run hello world within moments :)
Original comment by anders.e...@gmail.com
on 10 Nov 2007 at 10:42
Tried to follow the Wiki page and instructions but fail after the make for llvm:
arm-apple-darwin-lipo -output libgcc_s.10.4.dylib -create libgcc_s.10.4.dylib_T*
arm-apple-darwin-lipo: can't figure out the architecture type of: libgcc_s.10.4.
dylib_T
make[1]: *** [libgcc_s.10.4.dylib] Error 1
Any ideas?
Original comment by NetMage....@gmail.com
on 10 Nov 2007 at 9:46
@NetMage.SCW: Did you use the installation guidelines on iphone.fiveforty.net ?
I've
been able to install and compile the toolset twice on different machines now
using
those guidelines, even managed to compile and run HelloWorld. If you did use
them,
try manually deleting the entire checkout of llvm and checking it out again,
then
follow the guidelines again, closely, step by step.
Original comment by anders.e...@gmail.com
on 11 Nov 2007 at 4:21
@NetMage.SCW: Just realized you may rather be missing "usr/lib/libc.dylib" from
your
iphone filesystem. You need this to be able to build the toolchain. Get a hold
of
that and try again.
Original comment by anders.e...@gmail.com
on 11 Nov 2007 at 4:27
Everybory, just to inform that I am building iPhone binaries from my Windows /
Cygwin since Nov, 6.
Thanks victzh for the patch without it I would never get it.
Original comment by igorcha...@gmail.com
on 12 Nov 2007 at 1:11
Yup, many many thanks to victch for getting us this far!
NetMage, I've run across that error myself and usually a "make clean" then a:
# $ make LLVM_VERSION_INFO=2.0-svn-iphone-dev-0.3-svn
# $ make install
solves it.
Also, to everyone else, while I have a "working" toolchain, I've noticed that
not all
apps build correctly. For example, when I compile the "Motion" sample, I only
get 1/3
indicators showing up. The FlipACoin app refuses to compile, throwing a syntax
error
on code that works for others. Anyway, I suspect not all is well with toolchains
built on Windows/Cygwin, so proceed with caution...or tell us what other magic
you're
using! :)
Original comment by aaronmiller@gmail.com
on 12 Nov 2007 at 8:31
OK, glad to report that after replacing the GraphicsServices.h from the
iphone-dev
repository with the one from
http://svn.berlios.de/svnroot/repos/iphone-binutils/trunk (as victzh noted),
graphics
dependent apps like FlipACoin and Motion now compile & work. So, if you get a
non-functional Motion app or a non-compiling FlipACoin, be sure to check your
/usr/local/arm-apple-darwin/include/GraphicsServices/GraphicsServices.h file.
Original comment by aaronmiller@gmail.com
on 12 Nov 2007 at 10:16
am I the only one getting an "undefined symbol: ___eprintf" whenever I try to
compile
code using asserts? What is the correct way to fix this?
Original comment by anders.e...@gmail.com
on 13 Nov 2007 at 1:58
Saw this note in Issue #64: recompiling with -D__DARWIN_UNIX03, helps with
"___eprintf"
Original comment by aaronmiller@gmail.com
on 13 Nov 2007 at 7:40
the topic in #iphone on irc.osx86.hu has included a link to
http://wiki.iphonegameover.com/Windows_Cygwin_Binary_Toolchain_Installation for
some
time.
Original comment by beej666@gmail.com
on 4 Jan 2008 at 11:49
When compiling this: http://wiki.iphonegameover.com/Hello_World_Tutorial
The HelloWorld program compiles fine ... but when I upload the HelloWorld.app
in my
Iphone, the blue screen with Hello World doesn't show and the screen freezes
...
Anyone has any idea why ?
Please ... and Thankyou
Original comment by matin...@gmail.com
on 23 Feb 2008 at 8:18
Never mind ... I had to change the permissions ... to executable.
Original comment by matin...@gmail.com
on 25 Feb 2008 at 12:54
It seems newest cygwin adopted mingw-gcc to generate native win32 exe, which
causes
the libstdc++-v3 build failed. I tried to modify the libstdc++-v3/configure
line 2390
from yes to no for bypassing the check and it seems works.
PS, as I used prefix to assign different root directory for installing, there
are
some troubles while building. Finally, I find to create symbolic link under
/opt/iphone-toolchain/arm-apple-darwin/{include,lib,libexec,sys-include} is
helpful,
they are all in upper level directory after a series of make install.
Original comment by pin...@gmail.com
on 9 Jul 2008 at 4:15
I've applied the patch above but i still get similar errors on execute.c.
gcc -Wall -Wno-import -DHAVE_CONFIG_H -D__LITTLE_ENDIAN__=1 -I../include -I..
/../../odcctools/include -include ../../../odcctools/include/extern.h -I../../..
/odcctools/include/foreign -g -O2 -fno-builtin-round -fno-builtin-trunc -c -o
execute.o ../../../odcctools/libstuff/execute.c
In file included from /usr/include/sys/types.h:25,
from /usr/include/stdio.h:46,
from ../../../odcctools/libstuff/execute.c:26:
/usr/include/machine/_types.h:59: error: conflicting types for 'uint32_t'
/usr/include/stdint.h:28: error: previous declaration of 'uint32_t' was here
make[1]: *** [execute.o] Error 1
make[1]: Leaving directory `/home/iphone-dev/build/odcctools/libstuff'
make: *** [libstuff] Error 2
Does anybody know what can cause this? I've followed everything exactly.
Original comment by gearfo...@gmail.com
on 18 Jul 2008 at 12:31
I think i know the cause partially, it's because i'm compiling for 2.0 using
the
tutorial on the wikee.iphwn.org website.
They've updated their odccctools there so probably the patch doesn't apply
correctly...
Do you know if someone can make a patch for this version please
(odcctools-ld9.2
branch from svn).
Thanks in advance.
Original comment by gearfo...@gmail.com
on 18 Jul 2008 at 1:33
@gearforce I had that very same error. My quick fix for this is just erase
your
odcctools build directory and configure again, then make, make install, etc.
I'm sorta
stuck at including the OS X headers, but oh well. I've been trying to do this
for a
good three days on my eeePC with cygwin under XP and this is by far the best
guide.
Thanks victzh, that patch really pushed my installation ahead!
Original comment by sudo.adam.carruthers@gmail.com
on 18 Dec 2009 at 6:51
Original issue reported on code.google.com by
aaronmiller@gmail.com
on 15 Sep 2007 at 6:09