Closed cspiegel closed 2 years ago
Thanks for heads-up! Looks like a nice update. I'll let you know if I run into problems.
I'm probably missing something obvious, but I can't get this to build in Xcode. I keep getting lots of undefined symbol
linker errors. That usually means I've forgotten to add some source file or library, but I seem to be compiling the exact same files as Gargoyle, where compilation works just fine, so there must be some other setting that is off.
Here are the errors: https://gist.github.com/angstsmurf/341cff5f4851055c83cf3cea103855d7
Curious... I'm going to have to work to get XCode installed and running in my Mac VM. I'm unfamiliar with it, but I don't suspect it'll be too difficult. Once I get a proper development environment going, I can test and see what's going on, or at least try.
From the error log, it feels like io.cpp
and iff.cpp
aren't being built, or at least aren't being linked in. If there's a detailed build log, you could check to ensure io.o
and iff.o
are being included properly.
Thanks for taking a look! For some reason I often have problems when adding C++ projects to Xcode, and the solution tends to be something embarrassingly simple.
And the solution was embarrassingly simple here too. Somehow Xcode had confused the io.cpp
and iff.cpp
files with their headers, so the file that was shown as io.cpp
in the Xcode UI was in fact io.h
and vice versa. After deleting the file references and re-adding them it compiles just fine.
Very weird and annoying, but at least it is fixed. Thanks again for putting me on the right track!
Bocfel 2.0 has just been released, and if you want to update to it, there are some things you'll probably want to know:
It's been ported to C++, so your local patches will not directly apply. The good news is that the overall structure of the code is the same (I didn't rewrite it entirely, but converted it in place). You'll have to manually redo the changes, most likely, but it won't be hard.
Prior to 2.0, Bocfel determined which Glk startup to use based on the operating system. Windows got winglk, everybody else got glkunix. This would cause problems with something like remglk on Windows, since remglk uses glkunix. There was no way to specify "Unix Glk but Windows OS". There were already special cases in place for Gargoyle (always glkunix) and GlkDOS (also glkunix), so I finally just split the two apart. Now you have to define the macro
ZTERP_GLK_UNIX
for glkunix, orZTERP_GLK_WINGLK
for winglk. The build will fail if neither of these is defined.C++14 is required, so the build will have to be sure it's setting that.
I can't think of anything else offhand that would cause problems, but if you run into anything, let me know.