|
|
|
|
| Welcome, Guest | Home | Search | Login | Register | |
| Author | My Retro68 notes... (Read 72441 times) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
lauland
512 MB  Posts: 674 Symtes 7 Mewconer! 
|
on: January 13, 2025, 18:11
I took a look at it a while back, but am taking a fresh stab at it. I'm going to use this to record my notes and findings. This'll save anyone else who might want to try time, and let you guys know more about what it is and can do. ---- Despite the name, Retro68 includes compilers and support for building Classic and Carbon PPC apps, in addition to m68k. It does not include Apple's Universal Headers, out of the box, but you can supply your own from a copy of MPW. If you do this, you MUST put them in the right place BEFORE building Retro68. They can not be added later. (This messed me up previously). If you don't use Apple's headers, it will use its own "Multiversal Headers" which are incomplete, and have several differences from Apple's. This can cause problems building anything other than simple applications. ---- I'd successfully built it on a MacBook Pro running an OS version earlier than 10.14 previously. I copied the working folders to my current Intel 10.14 MBP, but they won't run, as they have dependencies on either the brew or macports that I had on that machine. Since I no longer have the previous machine, it looks like I have to build it from scratch... The compiler and binutils built fine, but am running into trouble with some of the more esoteric utilities it comes with, such as the "Mac to ELF" converter. I don't know if that is actually needed to built Mac apps or not, and will try the compiler without it. Otherwise, will try and fix it. Looks like an incompatibility with the newer 10.14 compiler. Also tried on an M2 MacBookPro running MacOS 14.71. This built the compiler, but has trouble with libcpp that are pretty bad and may not be easily fixable. This is pretty typical of my experience in trying to build older versions of gcc (which Retro68 uses) using newer gcc's. This goes double when you are building on MacOS X...using or trying to build anything other than the one Apple supplies with XCode can be quite painful and/or futile. Because of this, I'm going to try building it in Linux instead, using a VirtualBox VM. On the M2 MacBookPro that means using an ARM64 version of Linux, which may or may not work. I will probably have much more luck trying on my Intel Mac where I can run a 32-bit x86 Linux VM. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Jatoba
|
256 MB Posts: 270 System 9 Newcomer!
Reply #1 on: January 13, 2025, 19:04
|
IIRC Retro68 is also supported on PPC Mac OS X. Might be worth a shot, too? If I ever used it, that's the route I'd take, on the DLSD. Can it be compiled on... Power MachTen?  MPW tool?  Probably not viably. We saw what happened with the GCC 3 compilation attempts on Power MachTen.
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #2 on: January 13, 2025, 20:58
|
It built with zero problems on M2 Mac using this distro in virtualbox: Fedora-Workstation-Live-osb-40-1.14.aarch64 (I expect it will go very smoothly on x86 Linux). Built in MacOS 14.71 on same machine as long as I commented out one line in "Retro68/gcc/libcpp/system.h" #ifndef HAVE_SETLOCALE //# define setlocale(category, locale) (locale) #endif Haven't tested in either yet...but both built with no errors. Going to take another look on my Intel MBP...but I've got it built twice so that's good enough to put it through its paces...
Last Edit: January 13, 2025, 21:02 by lauland
|
cballero
|
1024 MB Posts: 1176 System 7, today and forever
Reply #3 on: January 14, 2025, 01:06
|
So you’re building an older “GNU Compiler Collection”? I had to look up GCC to see what I was asking about, lol! just trying to follow along a bit 
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #4 on: January 14, 2025, 15:33
|
Please do keep following along @cballero! That is ANOTHER excellent question! I apologize I keep throwing out technical terms as if everyone should "just know them". Whenever you see ANYTHING I say you're curious about, please pipe up! ---- gcc is widely considered the best open source C/C++ compiler...sometimes the ONLY one other than MS's Visual whatever. They call it a "collection" because it includes support for many other language such as Ada and Fortran. Unfortunately it is primarily command line, but, behind the scenes it is what XCode on MacOS X uses. Retro68 is a version of gcc that targets Classic MacOS, originally created to build m68k System 6 applications, but it also includes support for PowerPC and even Carbon these days. The reason I'm bringing it up is that CodeWarrior and MPW are very old, and do not support many "modern" C++ language features. A lot of what "porting", ie getting a MacOS 7/8/9 version of an open source app, involves is dealing with differences or missing things with CW. At some point, if we try and port a particular game we may find it just can't handle something obscure, and we'd end up wasting a lot of time, or even having to re-write bits. If we could use gcc, via Retro68, it might save a LOT of time and effort. It is an example of what is called a "cross compiler", in that it runs on a different machine or operating system than the one for which it builds programs. So it runs (ie "is hosted) on a "modern" system line Linux, MacOS X or Windows, but you use it to create programs for Classic MacOS 6/7/8/9. Some open source programs are available only as source code, and you need to build them yourself, and this is the case with Retro68. I think that about covers it. Let me know if there's anything I missed.
|
cballero
|
1024 MB Posts: 1176 System 7, today and forever
Reply #5 on: January 14, 2025, 20:33
|
Thank you, Lauland!  you always offer such meaty insight into these very technical topics! Usually I can wrap my head around the high-level concepts, but the essence of this particular thread was eluding me completely!  I 'see' it much more clearly now, at least enough to follow it better!
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #6 on: January 14, 2025, 21:05
|
Stay curious! People want to avoid cross-compiling because it's a pain when you have to get the results every tine you compile from the host to the machine where it can actually run. In our case, we can use Basilisk and Sheepshaver so it won't be too painful. We'll be building applications for anything from System 6 to MacOS 9 using the command line of MacOS X or Linux. ---- You might wonder...why can't we run Retro68 on MacOS 8/9 itself? The problem is the OS is missing a lot of "unix-style" (or even just modern) infrastructure that gcc relies on...starting with the command line! There HAVE been ports of gcc (just the plain compiler, not Retro68, which comes with extra tools and Mac specific parts) to MacOS 7/8/9...there was a decent (but kludgey) one for MPW, and MachTen comes with a good (but very old) version. But even then, as gcc got bigger and bigger with each version, and required more and more things, it got to the point where getting even a slightly newer version of gcc for MachTen is nigh impossible. The OS is just too limited (doesn't have real virtual/protected memory) and the people who wrote the newer versions of gcc assumed too much. ---- Retro68 itself uses an older version of gcc, because support for the Motorola 68k cpu chips was dropped or broke or wasn't maintained well. Ironically, this causes problems, like what I was seeing, because building older versions of gcc with newer ones is tricky.
Last Edit: January 14, 2025, 21:21 by lauland
|
Bolkonskij
|
Administrator 1024 MB  Posts: 2023
Reply #7 on: January 15, 2025, 08:41
|
@lauland Your advice about including Apple's Universal Headers instead of Retro68's own "Multiversal Headers" is very good! There have been many reported incidents by people who wrote Macintosh applications on Retro68 only to discover that their programs ran fine in Basilisk and Mini vMac, but wouldn't on a real Mac Plus. I wonder if that's the cause for it.
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #8 on: January 15, 2025, 16:44
|
I wouldn't be surprised at all if that were the case. The idea of an "open source" version of Apple's Universal Headers is a good one to get around licensing issues...but I really doubt Apple or anyone else cares in the 2020's, so they're a bit pointless. It may be the Retro68 author created them to hew entirely to license concepts (maybe philosophically?), when there isn't really any problem. I ran into difficulties because the names of some of the headers were different, things were in different files, had slightly different spellings, and some things were missing. I couldn't even get some standard Mac code to compile, way before the point of trying to run them. It was frustrating enough because I knew it was just because the Retro68 author insisted on using their own headers by default (for the unclear reasons above). That you had to rebuild the entire package if you wanted to add Apple's later was irritating too. That, and the fact that it was a cross compiler, and dealing with resource forks on Linux is a real kludge, made me throw my hands up. But I didn't want to write it off, and knew they HAD gotten far enough to make the thing actually produce System 6 applications, so...on this fresh look things should go better.
Last Edit: January 15, 2025, 16:46 by lauland
|
Jatoba
|
256 MB Posts: 270 System 9 Newcomer!
Reply #9 on: January 15, 2025, 20:50
|
A "minimal Retro68" OS VM image could be helpful to have.
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #10 on: January 15, 2025, 22:38
|
I've got a Fedora ARM64 Linux for VirtualBox one right now on my m2 MBP. The VDI file is "Dynamically allocated storage" and 11g in size. Has full stock gnome gui, standard dev tools and built Retro68, and that's it. Still need to test actually building something. Will...of course, try and stop me...let y'all know how that goes when I get to it.
|
Jatoba
|
256 MB Posts: 270 System 9 Newcomer!
Reply #11 on: January 16, 2025, 08:27
|
I'm not sure I ever will actually try to install it, but I know that I'd make sure at minimum I'd use a VM image I can run off VirtualPC in Mac OS 9, preferably in VPC4 (faster, has most features from VPC 5 and 6). And/or my DLSD OS X for much faster native compilation.
|
cballero
|
1024 MB Posts: 1176 System 7, today and forever
Reply #12 on: January 16, 2025, 08:35
|
Wait, what would you use VPC for? Editing or compiling within OS 9? Now that’s a cool thing to try within a G4 Mini!
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #13 on: January 16, 2025, 15:49
|
@Jatoba, you're going to need a VM with an x86 version of Linux to run on anything but an Apple Silicon Mac. I've got one for my Intel MBP, but it is a modern distro, so I don't know how well it'd run on G4 hardware, probably not at all, or terribly slowly. Modern Linux distros use the Gnome gui, which requires 3d acceleration, which VPC can't do, as far as I know. There are other more lightweight gui's, but they can be a pain to install...chicken and the egg thing...you need to get Linux at least running ONCE with Gnome, just to install the other gui's! (Unless you use a very old Linux distro, or a special one for slower machines). I can look into it. I haven't done much with VPC on MacOS 9, but that does sound interesting.
Last Edit: January 16, 2025, 15:51 by lauland
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #14 on: January 18, 2025, 20:06
|
Ok, I believe I now know some of the reasons Retro68 isn't used very much for Classic Mac coding. The fact that it only comes as source code means you have to build it. If ANYTHING goes wrong, which they certainly might if you don't have an OS or compiler the author had tested with, you'll have a bad time. Mine was very mixed, and I'd like to think I "know what I'm doing". (Daily use Linux and gcc). There aren't a lot of people good with the Linux command line that ALSO want to do Classic Mac coding, so I think many never get out of the starting gate, so to speak. ---- The source code alone takes up around 2g. The final built "toolchain" binaries take up exactly 2g. But the intermediate parts, needed while building it, take up an additional 6.8g on top. This was on x86 Linux, which is the place building it will most likely work. I didn't time the build, but watched a movie, and then let it run overnight...so just building it definitely took many hours on a lower end MacBook Pro (slow, but with 32g of memory). This was in a VirtualBox VM, and didn't take advantage of multiple cores, but is the safest cleanest way to build on a Mac. ---- You can build it for MacOS X native, but it requires packages installed using "Homebrew", which is a beast unto itself. I did so successfully on an M2 Mac running the latest OS, but ran into problems on my Intel machine with an older OS (kept so I can run 32-bit binaries), and older Homebrew. It says it is possible to build on MacOS X Tiger, supposedly even PPC, but the version of Homebrew for it is very very old, and I wouldn't suggest it. Building on any PPC will probably take at LEAST a day. Doing so in a Linux VM using VPC on a PPC may work, but will probably take multiple days, and then run very very slowly once you have it. ---- With all that out of the way, it looks quite good, for what it is, command line only, no IDE, not user friendly in any way. I have yet to try it with anything other than the samples it comes with, but am eager to try. It built samples for m68k, ppc, and Carbon, including MPW tools and shared libraries! One very nice feature is that it automatically builds disk images of your app. Which could then easily be used with either Basilisk or Sheepshaver. This saves countless time, and avoids dealing with Resource Fork difficulties on Linux, etc. I'm going to try some of the "examples" that come with MPW and CW or from Apple. I'll then move on to some of my own old code. The goal eventually being building SDL and games for it, but I'm not counting my chickens yet...
Last Edit: January 18, 2025, 20:14 by lauland
|
|
Pages: [1] 2 3
|
| |||||||||||||||
|
© 2021 System7Today.com. |
