🚀 go-pugleaf

<jonhoyle@mac.com> wrote in message
news:1116960211.043994.76260@o13g2000cwo.googlegroups.com...
> Now that Metrowerks has discontinued their x86 cross-compiler, I am
> left with wondering if there is another Mac-hosted x86 cross-compiler?
> (I know that gcc is available on x86, but it is not Mac-hosted.)  I am
> also guessing that Symbian (the new owners of the Metrowerks x86 tools)
> has no interest in continuing to sell the Mac-hosted version of these
> tools.  (Makes you wonder why Metrowerks couldn't have made the
> agreement to continue to sell Mac versions.)
>
> In particular, I have written a number of small utilities that I have
> cross-compiled for both Mac and Windows, but I prefer to do my
> development on the Mac side, saving the Windows side for debugging.
> Most start off as command-line utilities, often ending up as
> DLL's/Shared Libraries with a RealBasic GUI on top of it.  CodeWarrior
> 9.4 was perfect for just that, but that solution no longer exists, so I
> am looking for the best approximation to that.
>

gcc can be used as a cross compiler. I've never actually tried to make one,
but build instructions are provided (as well as warnings that it's tricky.)
I once looked into this as a possibility for XCode; the big problem I see is
debugging.

I haven't tried doing any x86 w/ 9.5 & Tiger yet. If that works, I'm okay
for another year or two anyway. If not, I'd still rather dedicate an old
machine to Panther & CW9.4 than use anything else I know of (particularly
including Visual Studio on PC.)

jonhoyle@mac.com wrote:
> Now that Metrowerks has discontinued their x86 cross-compiler, I am
> left with wondering if there is another Mac-hosted x86 cross-compiler?
> (I know that gcc is available on x86, but it is not Mac-hosted.)  ...

You can use MinGW to build Win32 executables (EXE, DLL, etc, in GUI or
console flavours) from OS X. MinGW is a complete GNU toolchain
including gcc, gas, and associated utilities.

I recently wrote these porting instructions for 10.x:
http://groups-beta.google.com/group/comp.sys.mac.programmer.tools/browse_frm/thread/481f7d3e6c021636/1471e5a81e0a94e5#1471e5a81e0a94e5

Eclipse (http://www.eclipse.org/) makes a top-notch IDE companion - I
like it better than Xcode for portable projects.

--Toby

> 
> Jonathan Hoyle
> Eastman Kodak

On 25/5/05 04:48, in article
1116992890.824483.56310@g47g2000cwa.googlegroups.com, "toby"
<toby@telegraphics.com.au> wrote:

> 
> 
> jonhoyle@mac.com wrote:
>> Now that Metrowerks has discontinued their x86 cross-compiler, I am
>> left with wondering if there is another Mac-hosted x86 cross-compiler?
>> (I know that gcc is available on x86, but it is not Mac-hosted.)  ...
> 
> You can use MinGW to build Win32 executables (EXE, DLL, etc, in GUI or
> console flavours) from OS X. MinGW is a complete GNU toolchain
> including gcc, gas, and associated utilities.
> 
> I recently wrote these porting instructions for 10.x:
> http://groups-beta.google.com/group/comp.sys.mac.programmer.tools/browse_frm/t
> hread/481f7d3e6c021636/1471e5a81e0a94e5#1471e5a81e0a94e5
> 
> Eclipse (http://www.eclipse.org/) makes a top-notch IDE companion - I
> like it better than Xcode for portable projects.
> 
> --Toby
> 
>> 
>> Jonathan Hoyle
>> Eastman Kodak
> 

Toby,

My company has decided to look at porting our code to MinGW, and thanks to
your build_cross.sh script it looks like we can stick with Macs, and it's
going to be a bit easier than we anticipated! (But we still have to get our
heads around make files!!)

The only thing that seems to be missing from the toolset is gdb. Have you
had any success in remote debugging OS X host -> Windows target? Is it
simple to do?



-- 
Cheers.
Steve Folly.

Steve wrote:
> On 25/5/05 04:48, in article
> 1116992890.824483.56310@g47g2000cwa.googlegroups.com, "toby"
> <toby@telegraphics.com.au> wrote:
>
> >
> >
> > jonhoyle@mac.com wrote:
> >> Now that Metrowerks has discontinued their x86 cross-compiler, I am
> >> left with wondering if there is another Mac-hosted x86 cross-compiler?
> >> (I know that gcc is available on x86, but it is not Mac-hosted.)  ...
> >
> > You can use MinGW to build Win32 executables (EXE, DLL, etc, in GUI or
> > console flavours) from OS X. MinGW is a complete GNU toolchain
> > including gcc, gas, and associated utilities.
> >
> > I recently wrote these porting instructions for 10.x:
> > http://groups-beta.google.com/group/comp.sys.mac.programmer.tools/browse_frm/t
> > hread/481f7d3e6c021636/1471e5a81e0a94e5#1471e5a81e0a94e5
> >
> > Eclipse (http://www.eclipse.org/) makes a top-notch IDE companion - I
> > like it better than Xcode for portable projects.
> >
> > --Toby
> >
> >>
> >> Jonathan Hoyle
> >> Eastman Kodak
> >
>
> Toby,
>
> My company has decided to look at porting our code to MinGW, and thanks to
> your build_cross.sh script it looks like we can stick with Macs, and it's
> going to be a bit easier than we anticipated! (But we still have to get our
> heads around make files!!)

I'd be happy to help, having recently helped move a team of programmers
from VSS/VS build+debug to Subversion/Eclipse build+debug. This
involved writing some moderately complex Makefiles, which Eclipse deals
with rather nicely. It also has gdb integration at least for the native
target; these guys target Linux.

>
> The only thing that seems to be missing from the toolset is gdb. Have you
> had any success in remote debugging OS X host -> Windows target? Is it
> simple to do?

I have not done that, as I rarely use symbolic debuggers, but it would
be an interesting thing to try...

By the way I recently updated the build-cross script for more recent
MinGW release files:

GCC_VERSION=3.4.2-20040916-1
BINUTILS=binutils-2.15.91-20040904-1
MINGW=mingw-runtime-3.7
W32API=w32api-3.2

The gcc configure command now looks like:

	"$SRCDIR/$GCC/configure" --with-gcc --with-gnu-ld --with-gnu-as \
		--with-sys-root="$PREFIX/$TARGET" \
		--without-newlib --disable-multilib \
		--target=$TARGET  --prefix=$PREFIX \
		--enable-threads --disable-nls --enable-languages=c,c++ \
		--disable-win32-registry --disable-shared

--Toby

> 
> 
> 
> -- 
> Cheers.
> Steve Folly.

On 1/6/05 00:42, in article
1117582976.124298.186480@f14g2000cwb.googlegroups.com, "toby"
<toby@telegraphics.com.au> wrote:

> I'd be happy to help.

Thank you. If it's alright, I'll keep your email address on file just in
case! :)

>> The only thing that seems to be missing from the toolset is gdb. Have you
>> had any success in remote debugging OS X host -> Windows target? Is it
>> simple to do?
> 
> I have not done that, as I rarely use symbolic debuggers, but it would
> be an interesting thing to try...

I'm just starting to read the gdb manual, to be honest I wouldn't have a
clue where to start. I'll carry on reading for now... :)
 
> By the way I recently updated the build-cross script for more recent
> MinGW release files:
> 
> GCC_VERSION=3.4.2-20040916-1
> BINUTILS=binutils-2.15.91-20040904-1
> MINGW=mingw-runtime-3.7
> W32API=w32api-3.2

How do you know which versions to use? Are they the same as the 'official'
MinGW download for Windows?
 
> The gcc configure command now looks like:
> 
> "$SRCDIR/$GCC/configure" --with-gcc --with-gnu-ld --with-gnu-as \
> --with-sys-root="$PREFIX/$TARGET" \
> --without-newlib --disable-multilib \
> --target=$TARGET  --prefix=$PREFIX \
> --enable-threads --disable-nls --enable-languages=c,c++ \
> --disable-win32-registry --disable-shared
> 

Thanks. Out of interest, what difference do the new configure options make?


Using gcc it's interesting to watch it report more warnings and errors where
Codewarrior let it through without any problems.

We're also investigating Visual Studio (2005 beta 2) and that also spots
more potential problems in our code.

I was always under the impression that Codewarrior was leading the way wrt.
standards compliance?

-- 
Steve.

Steve wrote:
> On 1/6/05 00:42, in article
> 1117582976.124298.186480@f14g2000cwb.googlegroups.com, "toby"
> <toby@telegraphics.com.au> wrote:
>
> > I'd be happy to help.
>
> Thank you. If it's alright, I'll keep your email address on file just in
> case! :)
>
> >> The only thing that seems to be missing from the toolset is gdb. Have you
> >> had any success in remote debugging OS X host -> Windows target? Is it
> >> simple to do?
> >
> > I have not done that, as I rarely use symbolic debuggers, but it would
> > be an interesting thing to try...
>
> I'm just starting to read the gdb manual, to be honest I wouldn't have a
> clue where to start. I'll carry on reading for now... :)

Failing that, you can always run an IDE like Eclipse under Windows,
hooked up to MinGW toolset. It's probably easier to get started
debugging that way.

>
> > By the way I recently updated the build-cross script for more recent
> > MinGW release files:
> >
> > GCC_VERSION=3.4.2-20040916-1
> > BINUTILS=binutils-2.15.91-20040904-1
> > MINGW=mingw-runtime-3.7
> > W32API=w32api-3.2
>
> How do you know which versions to use? Are they the same as the 'official'
> MinGW download for Windows?

I probably wouldn't have updated beyond my last post on the subject,
except I needed to do a new build on a new system and found a couple of
those distribution files had gone missing. I take my cue from the
"Current" file list at
http://sourceforge.net/project/showfiles.php?group_id=2435

>
> > The gcc configure command now looks like:
> >
> > "$SRCDIR/$GCC/configure" --with-gcc --with-gnu-ld --with-gnu-as \
> > --with-sys-root="$PREFIX/$TARGET" \
> > --without-newlib --disable-multilib \
> > --target=$TARGET  --prefix=$PREFIX \
> > --enable-threads --disable-nls --enable-languages=c,c++ \
> > --disable-win32-registry --disable-shared
> >
>
> Thanks. Out of interest, what difference do the new configure options make?

Not much - mainly I decided to use the new --with-sys-root option.

>
>
> Using gcc it's interesting to watch it report more warnings and errors where
> Codewarrior let it through without any problems. ... I was always under the impression that Codewarrior was leading the way wrt.
> standards compliance?

My opinion is each compiler has different blind spots, so the best
thing is to show your code to as many of them as possible. Where I'm
working, we've found that gcc with all warnings (-Wall) spots a lot of
things that MSVC lets through. Porting to gcc therefore has a generally
positive effect on code quality. In fact, the format-string checking of
gcc alone (an example of where it goes beyond the call of duty) has
pre-emptively picked up some serious portability-type issues.

--Toby

> 
> -- 
> Steve.