Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Cross-building everywhere...

8 views
Skip to first unread message

Robert Heller

unread,
Feb 7, 2006, 12:30:18 PM2/7/06
to
I presently develop Tcl/Tk + C/C++ Open Source programs on a Linux
system. I have set up (using mingw32) cross-building of C/C++ coded
DLLs for MS-Windows and I am wondering:

1) What exactly is needed to do this for MacOSX, for both the ppc and
the x86 Macs?

2) I have used FreeWrap in the past to 'bundle' the applications, but am
thinking of moving to another bundler. Do any other the other bundling
hacks have a cross-build/bundle capability? Do any exist for MacOSX on
either ppc or x86?

I know I can probably build a cross gcc/g++ compiler for any random
system -- that is not hard. The 'tricky' part is:

a) getting the libtcl...stub.a and libtk...stub.a files, plus what other
'native' libraries needed to build a .so or .dll or whatever MacOSX
calls it.

b) bundling the Tcl/Tk code, the images, the help files, and the
.so/.dll into some sort of self-contained executable that can be just
plopped onto CD or a FTP site and then copied/downloaded to an
end-user's system and just run, without the end-user having to install a
bunch of stuff. Note: this executable might in fact be a self
installer.

The main point of (b) above is so that non-computer geek types can use
my software products without having to deal with geeky things
like terminal windows, frink, or having to visit SourceForge.net or
something.

\/
Robert Heller ||InterNet: hel...@deepsoft.com
http://www.deepsoft.com/ ||FidoNet: 1:321/153
http://www.deepsoft.com/~heller /\



Kevin Walzer

unread,
Feb 7, 2006, 1:07:17 PM2/7/06
to
Robert Heller wrote:
> I presently develop Tcl/Tk + C/C++ Open Source programs on a Linux
> system. I have set up (using mingw32) cross-building of C/C++ coded
> DLLs for MS-Windows and I am wondering:
>
> 1) What exactly is needed to do this for MacOSX, for both the ppc and
> the x86 Macs?

Not sure about whether gcc supports this kind of cross-compiling on OS
X. The dual-architecture focus for OS X makes things more complicated in
itself.

>
> 2) I have used FreeWrap in the past to 'bundle' the applications, but am
> thinking of moving to another bundler. Do any other the other bundling
> hacks have a cross-build/bundle capability? Do any exist for MacOSX on
> either ppc or x86?

Freewrap has just been ported to OS X. See
http://www.nscl.msu.edu/~bazin/freewrap/

Starkits/starpacks are probably a better solution, however. A
cross-platform application that I'm about to release (runs on OS X,
Linux and Windows) was developed and wrapped entirely on OS X. You can
easily create the starkit and then wrap it with the pre-compiled
platform-specific runtime on another platform; Jean-Claude Wippler makes
all the major platform starkit runtimes available at his website.

Tclkit does not yet build as a "universal" binary on OS X, as far as I
am aware; this means that tclkit will run natively under Mac-PPC, and
run under the "Rosetta" emulator environment on Intel (which is plenty
fast, as I understand).


>
> I know I can probably build a cross gcc/g++ compiler for any random
> system -- that is not hard. The 'tricky' part is:
>
> a) getting the libtcl...stub.a and libtk...stub.a files, plus what other
> 'native' libraries needed to build a .so or .dll or whatever MacOSX
> calls it.

If you use the precompiled binaries made available by the various
developers, this shouldn't be a problem. (You don't even need to use
ActiveState's distribution, which requires licensing fees: look at SD
Archive for various starkits and libraries, and other relevant sites.)
If you want to build everything yourself, it will be a lot more
complicated.

>
> b) bundling the Tcl/Tk code, the images, the help files, and the
> .so/.dll into some sort of self-contained executable that can be just
> plopped onto CD or a FTP site and then copied/downloaded to an
> end-user's system and just run, without the end-user having to install a
> bunch of stuff. Note: this executable might in fact be a self
> installer.

This is exactly what starkits/starpacks are designed to do.

>
> The main point of (b) above is so that non-computer geek types can use
> my software products without having to deal with geeky things
> like terminal windows, frink, or having to visit SourceForge.net or
> something.

Amen! The beauty of starkits/starpacks.

See the wiki for more information.


--
Cheers,

Kevin Walzer, PhD
WordTech Software - "Tame the Terminal"
http://www.wordtech-software.com
sw at wordtech-software.com

Robert Heller

unread,
Feb 7, 2006, 2:37:20 PM2/7/06
to
Kevin Walzer <s...@wordtech-software.com>,
In a message on Tue, 07 Feb 2006 13:07:17 -0500, wrote :

KW> Robert Heller wrote:
KW> > I presently develop Tcl/Tk + C/C++ Open Source programs on a Linux
KW> > system. I have set up (using mingw32) cross-building of C/C++ coded
KW> > DLLs for MS-Windows and I am wondering:
KW> >
KW> > 1) What exactly is needed to do this for MacOSX, for both the ppc and
KW> > the x86 Macs?
KW>
KW> Not sure about whether gcc supports this kind of cross-compiling on OS
KW> X. The dual-architecture focus for OS X makes things more complicated in
KW> itself.

I'm assuming I would need two MacOSX cross-compilers:

eg:

i386-macosx-<mumble>

and

ppc-macosx-<mumble>

I would not expect that the dual-architecture focus for OS X will
matter as much as things did back in the days of OS 7.<mumble> when
Apple was going from the 68K to the ppc. I expect that with OS X,
things will be much like the differences between a <mumble>.ppc.rpm and
a <mumble>.i386.rpm is under Linux in many ways.

I don't expect building the cross compilers and cross bintools to be
particularly difficult (been there, done that).

to go along with my existing

i386-mingw32-<mumble>

The thing is, the mingw32 package includes a pile of stuff to link with
to build proper Tcl/Tk .dlls for MS-Windows -- a pile of lib*.a and headers
(I probably have more of this than I need just for Tcl/Tk .dlls, but it
all came as package deal -- all in one big archive file)

The tricky part of a cross build environment is these 'details'. I need
to get the equivalent stuff for MacOSX, both the ppc and the x86
versions (eventually).

KW>
KW> >
KW> > 2) I have used FreeWrap in the past to 'bundle' the applications, but am
KW> > thinking of moving to another bundler. Do any other the other bundling
KW> > hacks have a cross-build/bundle capability? Do any exist for MacOSX on
KW> > either ppc or x86?
KW>
KW> Freewrap has just been ported to OS X. See
KW> http://www.nscl.msu.edu/~bazin/freewrap/

I've had trouble cross-building MS-Windows Freewraps with Freewrap
versions > 4.4 and I've been having trouble build the very latest
versions of Freewrap, mostly because I don't have a new enough version
of Linux installed on my machine (I'm still using RH 7.3 and for a bunch of
reasons I cannot upgrade as yet).

KW>
KW> Starkits/starpacks are probably a better solution, however. A
KW> cross-platform application that I'm about to release (runs on OS X,
KW> Linux and Windows) was developed and wrapped entirely on OS X. You can
KW> easily create the starkit and then wrap it with the pre-compiled
KW> platform-specific runtime on another platform; Jean-Claude Wippler makes
KW> all the major platform starkit runtimes available at his website.
KW>
KW> Tclkit does not yet build as a "universal" binary on OS X, as far as I
KW> am aware; this means that tclkit will run natively under Mac-PPC, and
KW> run under the "Rosetta" emulator environment on Intel (which is plenty
KW> fast, as I understand).

I take it a 'universal' binary is much like what Apple did in the old
days of 68k/ppc systems? I don't think I really want to go there. I'm
assuming that sooner or later someone will build a native MaxOS X/x86
version of the Tcl/Tk system (with its own set of stub libs). At that
point, I'd just build a MacOSX x86 executable bundle with MacOSX x86
shared libraries. The idea is that my products would have four
executable 'downloads':

Linux x86
MS-Windows x86
MacOSX ppc
MacOSX x86

plus a source archive (.tar.gz), for those who want to build it
themselves (or are running on 'something else', like AIX or Solaris or
Linux ppc, etc.) and maybe other things like RPMs or such.


KW>
KW>
KW> >
KW> > I know I can probably build a cross gcc/g++ compiler for any random
KW> > system -- that is not hard. The 'tricky' part is:
KW> >
KW> > a) getting the libtcl...stub.a and libtk...stub.a files, plus what other
KW> > 'native' libraries needed to build a .so or .dll or whatever MacOSX
KW> > calls it.
KW>
KW> If you use the precompiled binaries made available by the various
KW> developers, this shouldn't be a problem. (You don't even need to use
KW> ActiveState's distribution, which requires licensing fees: look at SD
KW> Archive for various starkits and libraries, and other relevant sites.)
KW> If you want to build everything yourself, it will be a lot more
KW> complicated.

I just need to be able to build *my* loadable shared libraries, using
the stubs libraries, so I need the various pieces to build *my*
packages: the OS specific include files, OS specific config files (eg
tclConfig.sh and tkConfig.sh), and the stubs libraries (libtcl...stub.a
and libtk...stub.a), plus whatever other dependent libraries and objects
are needed to create a shared library for the target system, all in a
format suitable for the cross-bintools I would be using. Some of my
code is in C or C++.

KW>
KW> >
KW> > b) bundling the Tcl/Tk code, the images, the help files, and the
KW> > .so/.dll into some sort of self-contained executable that can be just
KW> > plopped onto CD or a FTP site and then copied/downloaded to an
KW> > end-user's system and just run, without the end-user having to install a
KW> > bunch of stuff. Note: this executable might in fact be a self
KW> > installer.
KW>
KW> This is exactly what starkits/starpacks are designed to do.
KW>
KW> >
KW> > The main point of (b) above is so that non-computer geek types can use
KW> > my software products without having to deal with geeky things
KW> > like terminal windows, frink, or having to visit SourceForge.net or
KW> > something.
KW>
KW> Amen! The beauty of starkits/starpacks.
KW>
KW> See the wiki for more information.
KW>
KW>
KW> --
KW> Cheers,
KW>
KW> Kevin Walzer, PhD
KW> WordTech Software - "Tame the Terminal"
KW> http://www.wordtech-software.com
KW> sw at wordtech-software.com
KW>

Daniel A. Steffen

unread,
Feb 7, 2006, 8:44:15 PM2/7/06
to
Robert,

> I presently develop Tcl/Tk + C/C++ Open Source programs on a Linux
> system. I have set up (using mingw32) cross-building of C/C++ coded
> DLLs for MS-Windows and I am wondering: 1) What exactly is needed to
> do this for MacOSX, for both the ppc and the x86 Macs?

AFAIK it is not currently possible to fully cross-build for OSX on
hosts not running a darwin based OS. While building a standard gcc
targeting darwin is possible on e.g. linux, the rest of the toolchain
has not been ported, in particular the linker is not gnu tools based
and would be non-trivial to port.
Moreover the Apple gcc has slight differences to the FSF gcc, and those
Apple modifications may not build on non-darwin systems, leading to
inability to cross-build certain sources that build on a darwin system
(I suspect this would in particular affect ability to parse OSX header
files...)

> I take it a 'universal' binary is much like what Apple did in the old
> days of 68k/ppc systems? I don't think I really want to go there.

universal binaries are simply binaries for multiple architectures (or
even processor versions) wrapped together in an 'ar' like format, the
OS automatically runs/loads the most appropriate binary contained in
the archive. This has been a feature of the MachO binary format since
forever, NeXT used exactly this to ship binaries that ran on four
architectures a decade or so ago...

this is the preferred format to deliver macosx binaries as the user
doesn't have to know if he is using a ppc or x86 mac...

> I'm assuming that sooner or later someone will build a native MaxOS
> X/x86 version of the Tcl/Tk system (with its own set of stub libs).
> At that point, I'd just build a MacOSX x86 executable bundle with
> MacOSX x86 shared libraries.

tcl/tk stublibs for x86 OSX are not the problem, they are available now
(e.g. shipped with the OS on x86 macs), you just cannot link to them on
a non-darwin OS...

Cheers,

Daniel

Robert Heller

unread,
Mar 1, 2006, 2:52:00 PM3/1/06
to
"Daniel A. Steffen" <daniel....@gmail.com>,
In a message on 7 Feb 2006 17:44:15 -0800, wrote :

"AS> Robert,
"AS>
"AS> > I presently develop Tcl/Tk + C/C++ Open Source programs on a Linux
"AS> > system. I have set up (using mingw32) cross-building of C/C++ coded
"AS> > DLLs for MS-Windows and I am wondering: 1) What exactly is needed to
"AS> > do this for MacOSX, for both the ppc and the x86 Macs?
"AS>
"AS> AFAIK it is not currently possible to fully cross-build for OSX on
"AS> hosts not running a darwin based OS. While building a standard gcc
"AS> targeting darwin is possible on e.g. linux, the rest of the toolchain
"AS> has not been ported, in particular the linker is not gnu tools based
"AS> and would be non-trivial to port.
"AS> Moreover the Apple gcc has slight differences to the FSF gcc, and those
"AS> Apple modifications may not build on non-darwin systems, leading to
"AS> inability to cross-build certain sources that build on a darwin system
"AS> (I suspect this would in particular affect ability to parse OSX header
"AS> files...)

Bummer. So, I would need a MacOSX system to build for MacOSX and
cross-building, even only the shared library modules is not possible?

"AS>
"AS> > I take it a 'universal' binary is much like what Apple did in the old
"AS> > days of 68k/ppc systems? I don't think I really want to go there.
"AS>
"AS> universal binaries are simply binaries for multiple architectures (or
"AS> even processor versions) wrapped together in an 'ar' like format, the
"AS> OS automatically runs/loads the most appropriate binary contained in
"AS> the archive. This has been a feature of the MachO binary format since
"AS> forever, NeXT used exactly this to ship binaries that ran on four
"AS> architectures a decade or so ago...
"AS>
"AS> this is the preferred format to deliver macosx binaries as the user
"AS> doesn't have to know if he is using a ppc or x86 mac...
"AS>
"AS> > I'm assuming that sooner or later someone will build a native MaxOS
"AS> > X/x86 version of the Tcl/Tk system (with its own set of stub libs).
"AS> > At that point, I'd just build a MacOSX x86 executable bundle with
"AS> > MacOSX x86 shared libraries.
"AS>
"AS> tcl/tk stublibs for x86 OSX are not the problem, they are available now
"AS> (e.g. shipped with the OS on x86 macs), you just cannot link to them on
"AS> a non-darwin OS...

OK. Presumably if I had some kind of MacOSX box (no matter what
processor type), it would be possible to build for any/all MacOSX
systems -- that is cross-build within the MacOSX world and create a
'universal binary', with the various static wish exes (ppc, x86), and
matching shared lib modules (ppc, x86), along with the *.tcl, etc.
files.

Next question: Is it possible to get a version of x86 MacOSX and
install it on a random PC (eg a random *cheap* Pentium-ish box),
including as a *secondary* OS on my existing K6-500 Linux machine? (I
would not mind actually buying a copy of the OS from Apple.) Or do I
really have to buy an actual complete Mac? (I know, I could get one the
Mac 'minis' and just jack it into my Ethernet and never bother with a
keyboard, mouse, or monitor for it.)

"AS>
"AS> Cheers,
"AS>
"AS> Daniel
"AS>
"AS>

Erik Leunissen

unread,
Mar 1, 2006, 7:05:18 PM3/1/06
to
Robert,

I have no idea myself, but I found some discussion regarding macosx in
the cross-gcc mailing list ( crossgcc-...@sources.redhat.com ).

I attached two messages that I thought were interesting, but there is
more there.

Greetings,

Erik
--
leunissen@ nl | Merge the left part of these two lines into one,
e. hccnet. | respecting a character's position in a line.

Donal K. Fellows

unread,
Mar 2, 2006, 3:56:49 AM3/2/06
to
Robert Heller wrote:
> Next question: Is it possible to get a version of x86 MacOSX and
> install it on a random PC (eg a random *cheap* Pentium-ish box),
> including as a *secondary* OS on my existing K6-500 Linux machine?

Possibly, but I wouldn't want to bet on it since it is the option that
is least in Apple's interests to support. Random x86 hardware trouble is
one of the major sources of headaches under both Windows and Linux, and
it is the fault of the hardware manufacturers. (They seem to regard sane
and standardized interfaces as being beneath their dignity. At least
things are better than they used to be for external hardware...)

Donal.

Robert Heller

unread,
Mar 2, 2006, 8:20:24 AM3/2/06
to
"Donal K. Fellows" <donal.k...@manchester.ac.uk>,
In a message on Thu, 02 Mar 2006 08:56:49 +0000, wrote :

"KF> Robert Heller wrote:
"KF> > Next question: Is it possible to get a version of x86 MacOSX and
"KF> > install it on a random PC (eg a random *cheap* Pentium-ish box),
"KF> > including as a *secondary* OS on my existing K6-500 Linux machine?
"KF>
"KF> Possibly, but I wouldn't want to bet on it since it is the option that
"KF> is least in Apple's interests to support. Random x86 hardware trouble is
"KF> one of the major sources of headaches under both Windows and Linux, and
"KF> it is the fault of the hardware manufacturers. (They seem to regard sane
"KF> and standardized interfaces as being beneath their dignity. At least
"KF> things are better than they used to be for external hardware...)

Yeah, I figured it would be something like that... Sigh.

So, it looks like I will need to get a Mac "mini" at some point along
the line if I want to support MacOSX.

"KF>
"KF> Donal.
"KF>

Jeff Hobbs

unread,
Mar 2, 2006, 10:15:54 PM3/2/06
to Robert Heller
Robert Heller wrote:
> "Donal K. Fellows" <donal.k...@manchester.ac.uk>,
> In a message on Thu, 02 Mar 2006 08:56:49 +0000, wrote :
>
> "KF> Robert Heller wrote:
> "KF> > Next question: Is it possible to get a version of x86 MacOSX and
> "KF> > install it on a random PC (eg a random *cheap* Pentium-ish box),
> "KF> > including as a *secondary* OS on my existing K6-500 Linux machine?
> "KF>
> "KF> Possibly, but I wouldn't want to bet on it since it is the option that
> "KF> is least in Apple's interests to support. Random x86 hardware trouble is
> "KF> one of the major sources of headaches under both Windows and Linux, and
> "KF> it is the fault of the hardware manufacturers. (They seem to regard sane
> "KF> and standardized interfaces as being beneath their dignity. At least
> "KF> things are better than they used to be for external hardware...)
>
> Yeah, I figured it would be something like that... Sigh.
>
> So, it looks like I will need to get a Mac "mini" at some point along
> the line if I want to support MacOSX.

And you might consider that the newer minis should be able to
run Linux and Windows (well, Vista maybe) natively without
problem, and likely virtual support available soon.

--
Jeff Hobbs, The Tcl Guy
http://www.ActiveState.com/, a division of Sophos

Robert Heller

unread,
Mar 2, 2006, 11:02:53 PM3/2/06
to
Jeff Hobbs <je...@activestate.com>,
In a message on Thu, 02 Mar 2006 19:15:54 -0800, wrote :

JH> Robert Heller wrote:
JH> > "Donal K. Fellows" <donal.k...@manchester.ac.uk>,
JH> > In a message on Thu, 02 Mar 2006 08:56:49 +0000, wrote :
JH> >
JH> > "KF> Robert Heller wrote:
JH> > "KF> > Next question: Is it possible to get a version of x86 MacOSX and
JH> > "KF> > install it on a random PC (eg a random *cheap* Pentium-ish box),
JH> > "KF> > including as a *secondary* OS on my existing K6-500 Linux machine?
JH> > "KF>
JH> > "KF> Possibly, but I wouldn't want to bet on it since it is the option that
JH> > "KF> is least in Apple's interests to support. Random x86 hardware trouble is
JH> > "KF> one of the major sources of headaches under both Windows and Linux, and
JH> > "KF> it is the fault of the hardware manufacturers. (They seem to regard sane
JH> > "KF> and standardized interfaces as being beneath their dignity. At least
JH> > "KF> things are better than they used to be for external hardware...)
JH> >
JH> > Yeah, I figured it would be something like that... Sigh.
JH> >
JH> > So, it looks like I will need to get a Mac "mini" at some point along
JH> > the line if I want to support MacOSX.
JH>
JH> And you might consider that the newer minis should be able to
JH> run Linux and Windows (well, Vista maybe) natively without
JH> problem, and likely virtual support available soon.

I have *plenty* of Linux machines (I have five in my office right now,
plus one more co-located) -- I don't really need one more. And I
really have no need or desire to run MS-Windows at all. Since I can
cross-build for MS-Windows, I don't need to. That leaves only MacOSX.

JH>
JH> --
JH> Jeff Hobbs, The Tcl Guy
JH> http://www.ActiveState.com/, a division of Sophos
JH>

0 new messages