|
|
|
|
| Welcome, Guest | Home | Search | Login | Register | |
| Author | Trying to compile Jabbernaut and need some help! (Read 125141 times) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
lauland
512 MB  Posts: 674 Symtes 7 Mewconer! 
|
Reply #15 on: February 05, 2024, 15:44
I think I can definitely say that cw6 is buggy when it comes to headers. Unfortunately, it being the last that generates m68k apps (and the first hosted natively on MacOS X), we end up being stuck with it more than we'd like. Doing the PPC Goliath build I ran into things that just shouldn't happen: It'd be trying to include sys/types.h even though a macro named something like "pre_MacOS_X" was ifdef'd around it. I'd look where that macro was defined in a global place and everything WAS correct, and it was included. Edit a tiny bit the file where it was defined, edit the file that included it, and bang, suddenly it saw the macro! Comparatively, on cw8, nothing like that. (For the record, it uses a new very solid IDE. In my testing cw7 feels just like cw6, though hopefully more stable). So I'm suspecting a similar thing is happening with Jabbernaut...it's "including" the wrong file (the windows jdk one) even though the project itself and the code is correct. If I just open/edit things enough, or remove the right files and add them back, it'll probably (eventually) build. I'm hesitant (although tempted) to throw out the project files and start from scratch since you never know what obscure setting or grouping is critical in them. Some more testing of a mutant "cw7 ide with the cw6 m68k plugins" might show if the bug is in the IDE or in the compiler itself... |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Last Edit: February 05, 2024, 15:46 by lauland
|
Bolkonskij
|
Administrator 1024 MB  Posts: 2023
Reply #16 on: February 05, 2024, 16:52
|
If the header inclusion on CW 6 is buggy, shouldn't we be able to find more proof of it? And possibly (?) even a quickfix. This was a professional grade (and expensive) IDE back in the day, I find it hard to believe that companies and academics would have put up with such nasty bugs? But yes, I wholeheartedly agree. All things point into the same direction ...
|
Knezzen
|
Administrator 512 MB Posts: 608 Village idiot
Reply #17 on: February 07, 2024, 12:46
|
I'm in a weird way happy that you stumbled on the exact issue I did, lauland. I was beginning to question my sanity and my competence to do anything computer related for a while there. I cross my fingers, hoping you get it to compile! Don't lose hope 
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #18 on: February 08, 2024, 16:36
|
Not weird AT ALL! I know that feeling 100% where you're reasonably sure you're a competent programmer...but then something that should be trivial just throws you completely! Another pair of eyes is ALWAYS a good thing! The cw6 bug: It seems to be triggered when importing xml projects, possibly opening projects from different versions of cw, and, especially BOTH at the same time. Doing "re-search for files..." seems to, usually, fix it... Goliath: Running into the problems with PowerPlant I expected. It uses some bits/functions/classes that don't exist in the cw6 version. For now I'm just going to comment things out until it eventually builds and hope none of it is critical, and see how far I can get. If that ends up being untenable, I'll have to go back and try the fun of backporting the cw8 PowerPlant... JabberNaut: Lots of progress. I removed all the access paths and only added back what was completely needed, in this case GUSI and openssl ones. I found there are serious issues with...surprise!...the dependencies... ...GUSI comes with several unix-style headers that Mac compilers typically don't have. "sys/time.h" conflicts with the "time.h" that comes with cw's MSL. Putting the GUSI access path at the very end of the list, specifically after "compiler:" fixed this. ...The version of MacZoop you found came out right around MacOS 8, and includes "Appearance" support. BUT it does this by defining many structures and constants in its own headers...which conflict with the real ones in Apple's Universal Headers. It also has a few other names of types, like "Sizing" that is defined somewhere else, in one of the other dependencies, or by Apple, that need to be changed. So, changing all "Sizing" to int, and, commenting out the Appearance stuff in MacZoop, and changing a bunch of pointers to Appearance structures to void * gets pretty far...but I need to add #include <Appearance.h> to various parts of MacZoop to replace the commented out stuff, etc etc etc. Obviously a lot more very similar problems in other parts, but you get the idea...
Last Edit: February 08, 2024, 16:39 by lauland
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #19 on: February 18, 2024, 04:48
|
Jabbernaut: One mystery solved...or at least identified... The version of MacZoop that you guys found as a dependency is very likely not the right one that the author used. My theory about the duplicate symbols being part of Appearance.h were completely wrong. They actually are defined in both the MacZoop headers AND the Jabbernaut headers themselves! So I'm going to look at different versions of MacZoop next...
|
Bolkonskij
|
Administrator 1024 MB Posts: 2023
Reply #20 on: February 18, 2024, 11:16
|
That sounds like a likely cause! Unfortunately, there's no way to be absolutely sure which version of MacZoop was used by Max, unless he put some comments into the sources.
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #21 on: February 20, 2024, 05:45
|
Jabbernaut: It turns out one of you guys already helpfully included multiple versions of MacZoop in the Dependencies folder! But only the first one was being used (alphabetically) for the Zoop headers...version 2.5x. Cool cool...but removing ALL of those and putting different versions of MacZoop, including several old 2.0 and 2.1 versions didn't help. I still get multiply defined dialog things. The good news is the definitions match...which will be easier to fix...but begs the question, how is it supposed to work?!? There might still be some odd header conflict or including the wrong one, etc etc. Goliath: VERY CLOSE to getting PPC build using CodeWarrior 6. Down to a single error calling an undecorated function called "find". The only one that takes the right number of parameters is in <string> (part of C++ std lib), but it looks right and like I need to specify the function with a class and "::" and it's a weird template with syntax I don't understand...tried a few things but have't got it QUITE right. Shouldn't be too hard to try some different things, etc etc. Very happily all the weird PowerPlant errors resolved with some added #include's and commenting out unneeded/unsupported things. Had to add a couple things the older Universal Headers don't have in them, but that wasn't a big deal. So after I fix "find" everything will compile...and then it'll try the link...which just MIGHT work... After I've got Goliath building for PPC in CW6, I'll try changing the targets to m68k!
|
cballero
|
1024 MB Posts: 1176 System 7, today and forever
Reply #22 on: February 20, 2024, 11:46
|
Wow!! Brilliant, Lauland!  So thanks to your efforts Goliath has a really good chance of having a major PPC update? This then can pave the way for a 68k version? Mind-blown here for sure! Astounding efforts, my friend!! Ps. and I'm starting to truly marvel at more and more (as I really begin to comprehend) what all of you do behind the scenes with the programming behind the upcoming app like this one, as well as Knez's newly-released Sound Pirate; and I just downloaded the patched iTunes that can play online radio stations again in OS 9, what? Wow!  then the recent Wikipedia app (not to mention new 68k games, too??) and I apparently missed the whole Chat Gpt app debut as well? I mean, this is just, truly wow.. I don't even have words for all these levels of Classic Mac programming mastery and genius going on here.. in the wise words of Wayne's World, "we're not worthy! we're not worthy!"
|
Knezzen
|
Administrator 512 MB Posts: 608 Village idiot
Reply #23 on: February 20, 2024, 15:03
|
Wow! Great progress, lauland! I feel like we need to compensate you somewhat Get on Hotline as well when you have time. Would be fun to chat some 
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #24 on: February 26, 2024, 16:56
|
Let me know how to get on Hotline...I've heard of it, but know abs zero. Goliath: I'm using whatever source was avail from mg, so unfortunately not a new version. I have it building PPC on CW8 which seems to be what the authors used. I'm working first on getting it for PPC using CW6, since that was the last one that supported m68k officially... Jabbernaut: MacZoop is definitely the issue. The problems I'm running into are strange, with a LOT of duplicated const, enum, and structure definitions in the MZ headers repeated in a couple of the Jabbernaut ones themselves. So either I'm still not using the right version of MacZoop, or there's something tricky with header names (the cw6 "bug"/"feature" I'd mentioned before). I mean, the original authors got it building somehow! The alternative is to try hacking the headers, maybe moving the duplicated stuff out into a single place and having THAT included where needed, etc etc.
|
cballero
|
1024 MB Posts: 1176 System 7, today and forever
Reply #25 on: February 26, 2024, 20:21
|
Well, Knez did put together a new client he uploaded to the MG that's at this link: https://macintoshgarden.org/apps/hotstuffIn Mac OS 9, I had a little more success jumping in and connecting with the FAT version vs the Carbon version; the latter just exited suddenly without any prompt when I attempted to connect to the default server with it.
|
Bolkonskij
|
Administrator 1024 MB Posts: 2023
Reply #26 on: February 27, 2024, 06:43
|
@lauland Here's a thread with all the connection & client info for Hotline you need! Interesting revelation about MacZoop. We assume that Max had build the code successfully. But then he had just sent me what he was able to scavenge from his dying old HDD. I wouldn't discount the fact that this was very much work in progress code and he might have been in the process of refactoring parts of it but dropped the pencil mid way ... explaining the duplicating consts, enums etc. ? One way or the other, it doesn't make things easier.
Last Edit: February 27, 2024, 06:44 by Bolkonskij
|
Jatoba
|
256 MB Posts: 270 System 9 Newcomer!
Reply #27 on: March 02, 2024, 15:04
|
This is probably unrelated, but that issue you guys ran into due to references to Windows JDK reminded me that a part of the Windows win32 API was ported to the Mac OS to facilitate porting Microsoft Office for it. There's also some correlation between that effort and Microsoft Visual C++ 4.0 Cross-Development Edition for Macintosh. If you are lacking Windows headers of some sort by any chance, maybe something of value could be there. I can relate to unmentioned dependencies that you are never told you needed, by the way... Compiling SDL 1.2.15 for Mac OS 9 required me to grab various headers from OpenGL and put them both in the folder where most of the source was, and in specific MPW folders that MPW expected them to be in. But none of that was mentioned in the official how-to-compile docs for Mac OS 9... I'm watching this thread much like how one would watch a movie of a detective trying to solve the mystery of who is the murderer.
Last Edit: March 02, 2024, 15:06 by Jatoba
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #28 on: March 17, 2024, 23:09
|
Goliath: Well, as if this were a murder mystery show...there's been a plot twist! The detective was following the wrong suspect! So I thought I was making tons of progress...going file by file and adding type casts, fixing prototypes, or commenting out things that didn't seem to be in the cw6 headers, etc etc etc...but then I got down to about 20 errors and couldn't easily figure out how to fix them. Had to take a break and then I started thinking about the "errors" I'd been fixing...wait a minute...it compiled fine on cw8, right? I assumed cw6 was "pickier" about types, hence the needs for casts and broken prototypes...but...was there a more logical explanation? Unfortunately there WAS a really good one...I was using the wrong OpenSSL headers for the cw6 build! Long story short (well not really): - The OpenSSL that came with the Goliath source didn't include everything needed...my assumption is it was a "U.S. export safe" version? I couldn't find anything corresponding to the exact partial version but found something very close and put everything in the right places... - OpenSSL is separated into numerous subdirectories, with the headers for each part in the same places as the corresponding source... - ...BUT there is an include/openssl directory at the root of the source where the different parts can include bits without having to use the full path... - The Makefile creates links from where all the headers REALLY are into include/openssl...there is an applescript that creates aliases to do the same thing, but it doesn't work in MacOS X... - So for cw8, I just copied ALL the .h files I could find into include/openssl...this worked well. As you may have already guessed...somehow in moving from my cw8 machine to my cw6 machine, I didn't get the right include/openssl folder. Somehow I ended up with aliases (my cw6 machine can run MacOS 9)...but the aliases were to the wrong version of OpenSSL that I had elsewhere on my drive!!! Bad news: I really need to start over as I'm betting 80% of the problems were due to this and nothing to do with cw6 vs cw8 (older universal headers, compiler differences, etc). Good news: The next try should go MUCH smoother since I won't be dealing with so many "mysterious" type casting etc! Obviously a bummer, but I want to jump back on it...
Last Edit: March 17, 2024, 23:14 by lauland
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #29 on: March 17, 2024, 23:13
|
JabberNaut: I haven't checked, but wouldn't be surprised at all if I did the same goofy thing with OpenSSL. I was trying to use the same version/build as I was with Goliath. But it's also REALLY good to know that the version of MacZoop included might never have built and only been a snapshot. It means instead of trying to keep moving things around to get things to "just build", I can now more safely muck with the headers. The obvious next thing to try is to comment out the dup things, and then when source tries to use them, but is including headers where they aren't anymore, have them include where I've left them uncommented. I think this'll probably mean the places in the JabberNaut source where it dups what is already in MacZoop logically should be removed.
Last Edit: March 18, 2024, 00:37 by lauland
|
|
Pages: 1 [2] 3 4 ... 6
|
| |||||||||||||||
|
© 2021 System7Today.com. |
