Mac Version
Opened this issue · 7 comments
Will you make a Mac binary?
I'd like to have Mac binaries, but I don't own a Mac so I'm not in a good position to be doing so. I'll look into it more though.
In the meantime, other Mac users either build the compiler themselves, or use wine
with the Windows version.
I'd like to have Mac binaries, but I don't own a Mac so I'm not in a good position to be doing so. I'll look into it more though.
In the meantime, other Mac users either build the compiler themselves, or use
wine
with the Windows version.
I tried it with Wine but it doesn't work because it's 64Bit. Could you make a 32Bit Windows Binary?
Just to clarify, is your computer a very old 32-bit one?
If you have a 64-bit Mac, try putting WINEARCH=win64
in your terminal before using wine.
The Windows binaries work fine on an M1 Mac if you use wine64 nesfab.exe test.cfg
.
I've come close to compiling on my M1 Mac:
- Install boost and gcc with homebrew (
brew install boost gcc
) - Edit the Makefile to get rid of the hard link to
g++
to use$(CXX)
instead:
lexer_gen: $(SRCDIR)/lexer_gen.cpp $(SRCDIR)/lex_op_name.inc
$(CXX) -std=c++17 -O1 -o lexer_gen $<
- Add overrides to
INCS
andLDLIBS
in the Makefile to allow them to be specified on the command line:
override INCS+= -I$(SRCDIR)
override LDLIBS+= -lboost_program_options
- Compile pointing the environment variables to the Homebrew locations e.g. on my machine:
CXX=/opt/homebrew/Cellar/gcc/13.1.0/bin/g++-13 INCS=-I/opt/homebrew/Cellar/boost/1.82.0_1/include LDLIBS=-L/opt/homebrew/Cellar/boost/1.82.0_1/lib make ARCH= release
It compiles almost all the way, but fails when linking to boost_program_options (Undefined symbols for architecture arm64
). This may be a Homebrew/ARM thing...
@sdwfrost Glad to see you try, even if it didn't work. I'd say building Boost from scratch might work, but that's a pretty big pain to do.
BTW those makefile changes look good. If they don't break compatibility, you can PR those changes and I'll merge them.
I got it compiled and linking with these changes, the missing bit was to use a dedicated boost lib that was compiled with gcc instead of the bottled one which is compiled with clang.
diff --git a/Makefile b/Makefile
index 24b915d..5308f6d 100644
--- a/Makefile
+++ b/Makefile
@@ -52,6 +52,12 @@ ifndef ARCH
ARCH=AMD64
endif
+ifeq ($(ARCH),ARM64)
+override CXX:=g++-13
+override INCS+=-I$(HOME)/Devel/arch/nes/tools/boost/include
+override LDLIBS:=-L$(HOME)/Devel/arch/nes/tools/boost/lib -Wl,-ld_classic -lboost_program_options
+endif
+
ifeq ($(ARCH),AMD64)
override CXXFLAGS+= \
-mpopcnt \
@@ -215,7 +221,7 @@ $(SRCDIR)/macro_lex_tables.hpp \
$(SRCDIR)/macro_lex_tables.cpp
lexer_gen: $(SRCDIR)/lexer_gen.cpp $(SRCDIR)/lex_op_name.inc
- g++ -std=c++17 -O1 -o lexer_gen $<
+ $(CXX) -std=c++17 -O1 -o lexer_gen $<
$(LEX_TABLES): lexer_gen $(SRCDIR)/lexer_gen.cpp $(SRCDIR)/lex_op_name.inc
./lexer_gen
But while running nesfab i get a SIGABRT early on:
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc
Process 16319 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
frame #0: 0x00000001943f4744 libsystem_kernel.dylib`__pthread_kill + 8
libsystem_kernel.dylib`:
-> 0x1943f4744 <+8>: b.lo 0x1943f4764 ; <+40>
0x1943f4748 <+12>: pacibsp
0x1943f474c <+16>: stp x29, x30, [sp, #-0x10]!
0x1943f4750 <+20>: mov x29, sp
Target 0: (nesfab) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
* frame #0: 0x00000001943f4744 libsystem_kernel.dylib`__pthread_kill + 8
frame #1: 0x000000019442bc28 libsystem_pthread.dylib`pthread_kill + 288
frame #2: 0x0000000194339ae8 libsystem_c.dylib`abort + 180
frame #3: 0x0000000101c291b8 libstdc++.6.dylib`__gnu_cxx::__verbose_terminate_handler() + 376
frame #4: 0x0000000101c26a5c libstdc++.6.dylib`__cxxabiv1::__terminate(void (*)()) + 12
frame #5: 0x0000000101c26a88 libstdc++.6.dylib`std::terminate() + 24
frame #6: 0x0000000101c26c70 libstdc++.6.dylib`__cxa_throw + 96
frame #7: 0x0000000100518e94 nesfab`void static_any_pool_t<cfg_node_t>::resize<block_d>(unsigned long) + 236
frame #8: 0x00000001004c8f78 nesfab`eval_t::insert_cfg(bool, pstring_t) + 264
frame #9: 0x00000001004baf74 nesfab`eval_t::eval_t(ir_t&, fn_t&) + 1640
frame #10: 0x00000001004b8514 nesfab`build_ir(ir_t&, fn_t&) + 172
frame #11: 0x00000001000f02a0 nesfab`fn_t::compile() + 156
frame #12: 0x00000001000fc318 nesfab`auto global_t::compile(log_t*)::'lambda'(auto&)::operator()<fn_t>(auto&) const + 24
frame #13: 0x00000001000fc490 nesfab`void global_t::delegate<global_t::compile(log_t*)::'lambda'(auto&)>(auto const&) + 184
frame #14: 0x00000001000ea8dc nesfab`global_t::compile(log_t*) + 220
frame #15: 0x00000001000eaec0 nesfab`global_t::compile_all()::'lambda'(global_t&)::operator()(global_t&) const + 28
frame #16: 0x00000001000fc8dc nesfab`void global_t::do_all<global_t::compile_all()::'lambda'(global_t&)>(global_t::compile_all()::'lambda'(global_t&) const&)::'lambda'(std::atomic<bool>&)::operator()(std::atomic<bool>&) const + 64
frame #17: 0x00000001001063c0 nesfab`void parallelize<void global_t::do_all<global_t::compile_all()::'lambda'(global_t&)>(global_t::compile_all()::'lambda'(global_t&) const&)::'lambda'(std::atomic<bool>&), void global_t::do_all<global_t::compile_all()::'lambda'(global_t&)>(global_t::compile_all()::'lambda'(global_t&) const&)::'lambda'()>(unsigned int, global_t::compile_all()::'lambda'(global_t&) const&, void global_t::do_all<global_t::compile_all()::'lambda'(global_t&)>(global_t::compile_all()::'lambda'(global_t&) const&)::'lambda'() const&) + 56
frame #18: 0x00000001000fc9d0 nesfab`void global_t::do_all<global_t::compile_all()::'lambda'(global_t&)>(global_t::compile_all()::'lambda'(global_t&) const&) + 108
frame #19: 0x00000001000eaf14 nesfab`global_t::compile_all() + 76
frame #20: 0x0000000100027ae4 nesfab`main + 7152
frame #21: 0x00000001940d3f28 dyld`start + 2236
I'm not a c++ nor boost programmer, but seems like static_any_pool_t::resize
fails to alloc.
I saw that the latest release here said that it compiles under Clang++, so I thought I've give it a whirl on macOS 15. I uncommented the "override CXX:=clang++" and added my Boost install location to the INCS declaration. Alas, it fails with a lot of template instantiations. Basically, the template definition for some of the data structures seems to require a sizeof(), but there are only forward declarations available when it encounters this and so it fails. This seems to be a pattern used all over the code, so this is just one example:
CXX obj/text.o clang++ -std=c++20 -pthread -Wall -Wextra -Wno-unused-parameter -Wno-unknown-warning-option -Wno-narrowing -Wno-missing-field-initializers -Wno-missing-braces -Wno-unused-command-line-argument -fmax-errors=3 -ftemplate-depth=100 -pipe -Isrc -I/Volumes/Outboard/Projects/boost_1_86_0 -DVERSION=\""1.5"\" -DGIT_COMMIT=\""heads/master-dirty"\" -mpopcnt -msse4 -mcx16 -mmovbe -O0 -g -c -o obj/text.o src/text.cpp In file included from src/text.cpp:1: In file included from src/text.hpp:13: In file included from src/pstring.hpp:10: In file included from src/assert.hpp:8: In file included from src/format.hpp:7: In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/sstream:278: In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/istream:170: In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/ostream:189: In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/format:195: In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/__format/container_adaptor.h:24: In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/queue:272: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/deque:252:34: error: invalid application of 'sizeof' to an incomplete type 'rom_array_t' 252 | static const _DiffType value = sizeof(_ValueType) < 256 ? 4096 / sizeof(_ValueType) : 16; | ^~~~~~~~~~~~~~~~~~ /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/deque:266:15: note: in instantiation of template class 'std::__deque_block_size<rom_array_t, long>' requested here 266 | __deque_block_size<_ValueType, _DiffType>::value | ^ /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/deque:476:20: note: in instantiation of default argument for '__deque_iterator<value_type, pointer, reference, __map_pointer, difference_type>' required here 476 | using iterator = __deque_iterator<value_type, pointer, reference, __map_pointer, difference_type>; | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ src/handle.hpp:93:33: note: in instantiation of template class 'std::deque<rom_array_t>' requested here 93 | using value_type = typename Pool::value_type; | ^ src/rom_decl.hpp:26:30: note: in instantiation of template class 'pool_handle_t<rom_array_ht, std::deque<rom_array_t>, PHASE_ROM_DUMMY>' requested here 26 | struct rom_array_ht : public pool_handle_t<rom_array_ht, std::deque<rom_array_t>, PHASE_ROM_DUMMY> {}; | ^ src/rom_decl.hpp:17:7: note: forward declaration of 'rom_array_t' 17 | class rom_array_t;