Cross-compile chain for OS X (not uploaded yet)

Posted by: Daria

Cross-compile chain for OS X (not uploaded yet) - 20/09/2003 20:34

I now have a cross-compile toolchain for MacOS X. I have it installed into /opt/local, which is the directory DarwinPorts suggested for its content; I plan to eventually contribute a port. When I get a few minutes I'll post a skeleton kit like mlord has from peter with the toolchain for linux x86 that he compiled, and when I get somewhere with better network than Laura's dialup (BTW, thanks Laura!) I'll upload the toolchain. The main lodge at Hueston Woods has for-pay wireless with a decent uplink, and I paid for today, so if I get back over there tonight, maybe I can upload it now. Anyhow, I have a new gpsapp compiled with the v3 font support; I'd love to have v3 to test it with

I also have gpsapp_host compiled for MacOS, but it doesn't work yet since it's not byteswapping anything.
Posted by: Daria

Re: Cross-compile chain for OS X (not uploaded yet) - 21/09/2003 23:26

Here's the modified "kit" I used to build it.
Posted by: V99

Re: Cross-compile chain for OS X (not uploaded yet) - 22/09/2003 01:30

Cool, I tried to compile it a while ago but didn't get anywhere with compilation problems, so I just put it on my FreeBSD box instead.
Posted by: jdandrea

Re: Cross-compile chain for OS X (not uploaded yet) - 22/09/2003 06:53

Yay! Excellent news. I'll have to give this one a try. Thanks.
Posted by: Daria

Cross-compile chain for OS X uploaded - 22/09/2003 07:34

http://empeg.dementia.org/distributions/

There will eventually be some sort of nice html page there, but the absolute path to the binary distribution should stay the same.

The compiled kit is about 32 megs compressed.
Posted by: mcomb

Re: Cross-compile chain for OS X (not uploaded yet) - 24/09/2003 15:16

Hey cool. This will come in handy, thanks.
-Mike
Posted by: jdandrea

Re: Cross-compile chain for OS X uploaded - 18/01/2004 21:13

Now that I've finally gotten around to downloading this toolchain for darwin, I'm curious: is there any way to tie this gracefully into Xcode (or would I even want to)? Inquiring minds ...
Posted by: Daria

Re: Cross-compile chain for OS X uploaded - 18/01/2004 22:10

I don't know, honestly, because the truth is I'm still learning the "MacOS way(tm)"
Posted by: Daria

Cross-compile chain for OSX Intel - 04/07/2011 02:49

Here's the kit. the binaries will follow.
Posted by: Daria

Re: Cross-compile chain for OSX Intel - 04/07/2011 02:54

http://empeg.dementia.org/distributions/ again has the intel darwin kit. not tested yet, as it finished mere moments ago.
Posted by: Daria

Re: Cross-compile chain for OSX Intel - 05/07/2011 01:20

updated kit and toolchain in same place; this time also builds zlib and ncurses.
Posted by: tonyc

Re: Cross-compile chain for OSX Intel - 12/07/2011 17:14

Thanks. Have you by any chance tried to build a kernel using this toolchain? I'm getting this error:

Code:
arm-empeg-linux-gcc -D__KERNEL__ -I/Users/tonyc/dev/empeg/kernel/current/include -Wall -Wstrict-prototypes -O2  \
-fno-strict-aliasing -pipe -msoft-float -march=armv4 -mtune=strongarm110   -c -o sock.o sock.c
Assembler messages:
option `-marmv4' is deprecated: use -march=armv4
{standard input}:508: Error: Rn must not overlap other operands -- `swp r3,r2,[r3]'
make[3]: *** [sock.o] Error 1
make[2]: *** [first_rule] Error 2
make[1]: *** [_subdir_core] Error 2
make: *** [_dir_net] Error 2




No idea what's going on there. My next step would be to do build my own toolchain instead of relying on your binaries, but if you've got a quick fix, let me know.
Posted by: Daria

Re: Cross-compile chain for OSX Intel - 12/07/2011 19:21

if you build from the same source i do, you'll have the same problem. i can see where it was introduced but not why, if that patch is right, the generated code would have worked before.

i'll look some more after i get the openafs lion client finished later tonight.
Posted by: Daria

Re: Cross-compile chain for OSX Intel - 12/07/2011 21:33

can you arm-empeg-linux-gcc -D__KERNEL__ -I/Users/tonyc/dev/empeg/kernel/current/include -Wall -Wstrict-prototypes -O2 -fno-strict-aliasing -pipe -msoft-float -march=armv4 -mtune=strongarm110 -E sock.c > sock.i

and tell me what's on line 508 of sock.i?
Posted by: Daria

Re: Cross-compile chain for OSX Intel - 12/07/2011 21:37

(it's going to be an issue like this:
http://www.rockbox.org/tracker/task/7972
but the simplest way to fix it is just to patch the kernel)
Posted by: tonyc

Re: Cross-compile chain for OSX Intel - 13/07/2011 00:03

Something's screwing with the line numbers, because that line (and many others) are blank. The only swp instruction I see in there is in this block:

Code:
extern const char xchg_str[];

extern __inline__ unsigned long __xchg(unsigned long x, volatile void *ptr, int size)
{
        switch (size) {
                case 1: __asm__ __volatile__ ("swpb %0, %1, [%2]" : "=r" (x) : "r" (x), "r" (ptr) : "memory");
                        break;
                case 2: abort ();
                case 4: __asm__ __volatile__ ("swp %0, %1, [%2]" : "=r" (x) : "r" (x), "r" (ptr) : "memory");
                        break;
                default: arm_invalidptr(xchg_str, size);
        }
        return x;
}


Here's the full sock.i file.
Posted by: Daria

Re: Cross-compile chain for OSX Intel - 13/07/2011 00:53

that's gonna be it. lemme see what i can do with that.
Posted by: Daria

Re: Cross-compile chain for OSX Intel - 13/07/2011 01:01

apply the attached diff to your kernel tree. i *think* that will do it. if so, i'll ask mark if he's willing to add it to v514; it's what i believe to be the barest fix.
Posted by: tonyc

Re: Cross-compile chain for OSX Intel - 13/07/2011 01:16

That wins, but fails further into the build:

Quote:

arm-empeg-linux-ar rcs lib.a changebit.o checksum.o clearbit.o copy_page.o findbit.o memchr.o memcpy.o memset.o memzero.o setbit.o strchr.o strrchr.o testchangebit.o testclearbit.o testsetbit.o semaphore.o system.o uaccess.o io-sa1100.o
make -C arch/arm/kernel
arm-empeg-linux-gcc -D__KERNEL__ -I/Users/tonyc/dev/empeg/kernel/current/include -D__ASSEMBLY__ -mno-fpu -mapcs-32 -marmv4 -c -o entry-armv.o entry-armv.S
entry-armv.S: Assembler messages:
entry-armv.S:370: Error: Macro `arm700_bug_check' was already defined
entry-armv.S:456: Warning: destination register same as write-back base
make[1]: *** [entry-armv.o] Error 1
make: *** [_dir_arch/arm/kernel] Error 2
Posted by: Daria

Re: Cross-compile chain for OSX Intel - 13/07/2011 01:38

[pre]
--- a/arch/arm/kernel/entry-armv.S
+++ b/arch/arm/kernel/entry-armv.S
@@ -397,8 +397,6 @@ irq_prio_ebsa110:
run on an ARM7 and we can save a couple of instructions.
--pb */
.macro arm700_bug_check, instr, temp
- .endm
- .macro arm700_bug_check, instr, temp
#ifndef __ARM_ARCH_4__
and \temp, \instr, #0x0f000000 @ check for SWI
teq \temp, #0x0f000000

[/pre]
Posted by: tonyc

Re: Cross-compile chain for OSX Intel - 13/07/2011 01:54

Marvelous. dbrashear++
Posted by: Daria

Re: Cross-compile chain for OSX Intel - 13/07/2011 02:01

well, basically it's just patches to deal with the tightening up of what gas enforces.
Posted by: tonyc

Re: Cross-compile chain for OSX Intel - 13/07/2011 02:54

Gotcha. Now I can build kernels, but I'm getting an undefined reference to fstat error when trying to build GNU gettext:

Quote:

make[5]: Nothing to be done for `all-am'.
Making all in src
/bin/sh ../libtool --tag=CC --mode=link arm-empeg-linux-gcc -DINSTALLDIR=\"/opt/arm/arm-empeg-linux/bin\" -I/opt/arm/include -I/opt/arm/arm-empeg-linux/include/ -L/opt/arm/lib -L/opt/arm/arm-empeg-linux/lib -o gettext gettext-gettext.o ../gnulib-lib/libgrt.a ../intl/libintl.la
libtool: link: arm-empeg-linux-gcc -DINSTALLDIR=\"/opt/arm/arm-empeg-linux/bin\" -I/opt/arm/include -I/opt/arm/arm-empeg-linux/include/ -o .libs/gettext gettext-gettext.o -L/opt/arm/lib -L/opt/arm/arm-empeg-linux/lib ../gnulib-lib/libgrt.a ../intl/.libs/libintl.so -lc -Wl,-rpath -Wl,/opt/arm/arm-empeg-linux/lib
../intl/.libs/libintl.so: undefined reference to `fstat'
collect2: ld returned 1 exit status


I've never seen anything like that when cross-compiling on my linux machine.
Posted by: Daria

Re: Cross-compile chain for OSX Intel - 13/07/2011 03:09

Originally Posted By: tonyc
Gotcha. Now I can build kernels, but I'm getting an undefined reference to fstat error when trying to build GNU gettext:

Quote:

make[5]: Nothing to be done for `all-am'.
Making all in src
/bin/sh ../libtool --tag=CC --mode=link arm-empeg-linux-gcc -DINSTALLDIR=\"/opt/arm/arm-empeg-linux/bin\" -I/opt/arm/include -I/opt/arm/arm-empeg-linux/include/ -L/opt/arm/lib -L/opt/arm/arm-empeg-linux/lib -o gettext gettext-gettext.o ../gnulib-lib/libgrt.a ../intl/libintl.la
libtool: link: arm-empeg-linux-gcc -DINSTALLDIR=\"/opt/arm/arm-empeg-linux/bin\" -I/opt/arm/include -I/opt/arm/arm-empeg-linux/include/ -o .libs/gettext gettext-gettext.o -L/opt/arm/lib -L/opt/arm/arm-empeg-linux/lib ../gnulib-lib/libgrt.a ../intl/.libs/libintl.so -lc -Wl,-rpath -Wl,/opt/arm/arm-empeg-linux/lib
../intl/.libs/libintl.so: undefined reference to `fstat'
collect2: ld returned 1 exit status


I've never seen anything like that when cross-compiling on my linux machine.


I have. there was some fun in glibc i remember from sparclinux that did that. i'm not (network) near the toolchain; what does arm-empeg-linux-nm libc.a |grep fstat
show? you'll need the full path to libc in your install.
Posted by: Daria

Re: Cross-compile chain for OSX Intel - 13/07/2011 11:25

actually, this one should be simpler. you relocated my tree, which is fine, but you need to tweak one file. arm-empeg-linux/lib/libc.so should have the paths corrected.

i should add that to a readme.
Posted by: tonyc

Re: Cross-compile chain for OSX Intel - 13/07/2011 12:11

Yeah, /opt/local is "owned" by MacPorts, so I didn't like the idea of using /opt/local/arm.

I did, however, end up symlinking /opt/local/armtools to /opt/arm, so the paths inside libc.so are legit. Shouldn't that still work?
Posted by: Daria

Re: Cross-compile chain for OSX Intel - 13/07/2011 12:44

it may be unhappy at a symlink. it's just a text file, try editing and see what happens? (fstat is defined in libc_nonshared.a)
Posted by: tonyc

Re: Cross-compile chain for OSX Intel - 13/07/2011 13:02

No dice. I'll build my own toolchain and see if that fixes it.
Posted by: tonyc

Re: Cross-compile chain for OSX Intel - 13/07/2011 13:32

Wonderful, now the toolchain build is failing:

Code:
hecking whether to build shared libraries... no
checking whether to build static libraries... yes
checking for objdir... .libs
creating libtool
loading cache ../config.cache
checking whether to enable maintainer-specific portions of Makefiles... no
checking for Cygwin environment... (cached) no
checking for mingw32 environment... (cached) no
checking for executable suffix... (cached) .dSYM
checking for gcc... (cached) gcc
checking whether the C compiler (gcc -g -O2 -W -Wall ) works... no
configure: error: installation or configuration problem: C compiler cannot create executables.
Configure in /Users/tonyc/tmp/armtools-darwin/build-binutils/binutils-2.10.1/bfd failed, exiting.
make: *** [arm-linux-binutils] Error 1


It doesn't like gcc? Earlier in the binutils build it likes it just fine, but once it gets into bfd, it doesn't.

Update:
From the config.log in the bfd subdirectory:
Code:
configure:1850: checking for gcc
configure:1963: checking whether the C compiler (gcc -g -O2 -W -Wall ) works
configure:1979: gcc -o conftest.dSYM -g -O2 -W -Wall   conftest.c  1>&5
configure:1976: warning: return type defaults to 'int'
ld: can't open output file for writing: conftest.dSYM, errno=21
collect2: ld returned 1 exit status
configure: failed program was:

#line 1974 "configure"
#include "confdefs.h"

main(){return(0);}


errno 21 appears to be EISDIR. wtf?
Posted by: Daria

Re: Cross-compile chain for OSX Intel - 13/07/2011 15:30

you're missing a patch, the one that tells it not to assume .dSYM is an object type, for one of the config.* files.

did you use my kit for the toolchain?
Posted by: tonyc

Re: Cross-compile chain for OSX Intel - 13/07/2011 15:50

Yeah, I'm using:
http://empeg.dementia.org/distributions/armtools-darwin-intel.tar.gz

Which patch is the one that does that? I have:
Code:
gcc-configure.patch
gcc-nold.patch
gcc3-binutils.patch
glibc-man.patch
linux-Makefile.patch

grep dSYM *.patch yields nothing.
Posted by: Daria

Re: Cross-compile chain for OSX Intel - 13/07/2011 16:01

looks like i uploaded the wrong one? hang on.
Posted by: Daria

Re: Cross-compile chain for OSX Intel - 13/07/2011 16:05

here's the corrected one. it will be on the website in a moment
Posted by: tonyc

Re: Cross-compile chain for OSX Intel - 13/07/2011 16:19

That one seems to be humming along. Thanks.
Posted by: Daria

Re: Cross-compile chain for OSX Intel - 13/07/2011 22:09

since you ran into trouble with gettext, have a toolchain which can compile gettext, tho you need to make arm-linux-gettext before it does. no weird fstat error.
Posted by: tonyc

Re: Cross-compile chain for OSX Intel - 15/10/2012 17:42

Many moons later, and with the latest and greatest Mac toolchain, I'm still ending up with several things that fail to build with the "undefined reference to fstat64" errors. Here's what it looks like when I try to build glib-2.34:

Code:
  CC       giounix.lo
  CC       gspawn.lo
  CCLD     libglib-2.0.la
  CC       gtester.o
  CCLD     gtester
./.libs/libglib-2.0.so: undefined reference to `fstat64'
./.libs/libglib-2.0.so: undefined reference to `stat64'
./.libs/libglib-2.0.so: undefined reference to `lstat64'
collect2: ld returned 1 exit status


Here's the arm-empeg-linux-nm output for libc.so:

Code:
arm-empeg-linux-nm /opt/arm/arm-empeg-linux/lib/libc.so.6|grep stat64         
0008a7f8 T __fxstat64
000e50bc b __have_no_stat64
0008a9dc T __lxstat64
0008a614 T __xstat64


And here's the same for libc_nonshared.a:

Code:
arm-empeg-linux-nm /opt/arm/arm-empeg-linux/lib/libc_nonshared.a | grep stat64
         U __fxstat64
         U __xstat64
xstat64.os:
00000004 C __have_no_stat64
00000000 T __xstat64
fxstat64.os:
00000000 T __fxstat64
         U __have_no_stat64
lxstat64.os:
         U __have_no_stat64
00000000 T __lxstat64
         U __lxstat64
         U __xstat64


Looks like the relevant symbols are indeed missing from libc. Any ideas what to try next?