building v17 on MacOS

Support and general discussion.
Post Reply
StLouisCPhT
Posts: 4
Joined: Thu 19 Nov, 2020 5:18 pm

building v17 on MacOS

Post by StLouisCPhT »

I'm wondering if anyone here has successfully managed to compile v17 for macOS using the previously posted directions at https://pcem-emulator.co.uk/phpBB3/view ... 863#p13863.

I gave it a shot but ran into a lot of new errors regarding wx, so I'm still hanging out on v16.
Last edited by StLouisCPhT on Sat 16 Jan, 2021 11:28 pm, edited 1 time in total.
User avatar
davide78
Posts: 9
Joined: Sat 22 Aug, 2020 12:36 pm

Re: v17 on MacOS

Post by davide78 »

I've managed to compile v17 under Mac OS catalina and the latest XCode by adding

Code: Select all

#include <sys/time.h>
to wx-threads.c, and

Code: Select all

#include <stdint.h>
to slirp/slirp.h

Oddly, now I have to add the includes event to compile v16, while the last time I worked on the code (before the v17 feature freeze) they where not needed.
TonyM
Posts: 20
Joined: Fri 15 Jul, 2016 8:11 pm

Re: v17 on MacOS

Post by TonyM »

I was able to compile v17 on Mac OS with no additional changes from the original instructions (I'm on OSX 10.14.6) but I've noticed that some of my machines now run dog slow. If I copy the pcem executable v16 back over everything runs normal again. It seems to affect the PMMX class machines.
StLouisCPhT
Posts: 4
Joined: Thu 19 Nov, 2020 5:18 pm

Re: v17 on MacOS

Post by StLouisCPhT »

davide78 wrote: Mon 07 Dec, 2020 9:40 am I've managed to compile v17 under Mac OS catalina and the latest XCode by adding

Code: Select all

#include <sys/time.h>
to wx-threads.c, and

Code: Select all

#include <stdint.h>
to slirp/slirp.h

Oddly, now I have to add the includes event to compile v16, while the last time I worked on the code (before the v17 feature freeze) they where not needed.
Your addition to wx-thread.c got rid of the time error.

Adding #include <unistd.h> to slirp/slirp.h dealt with clang reporting implicit declaration of function close(s) errors in the following spots:

slirp/debug.c
slirp/misc.c
slirp/socket.c
slirp/top_subr.c
slirp/tftp.c
slirp/udp.c

Just a heads up: #include <stdint.h> exists at line 80 in slirp/slirp.h, so you shouldn't need to add it yourself.

Now to figure out how to get my finished build of v17 to stop having a fit about where wx is at over on my ARM MacBook Pro.
User avatar
davide78
Posts: 9
Joined: Sat 22 Aug, 2020 12:36 pm

Re: v17 on MacOS

Post by davide78 »

StLouisCPhT wrote: Wed 09 Dec, 2020 12:43 am Adding #include <unistd.h> to slirp/slirp.h dealt with clang reporting implicit declaration of function close(s) errors in the following spots:

.....

Just a heads up: #include <stdint.h> exists at line 80 in slirp/slirp.h, so you shouldn't need to add it yourself.
You are right. Indeed, in the actual code I added #include <unistd.h>. I copy-pasted the wrong line of code in my previous message.
StLouisCPhT
Posts: 4
Joined: Thu 19 Nov, 2020 5:18 pm

Re: v17 on MacOS

Post by StLouisCPhT »

.
Last edited by StLouisCPhT on Fri 15 Jan, 2021 12:01 am, edited 1 time in total.
caiot5
Posts: 3
Joined: Sat 09 Jan, 2021 3:41 am

Re: v17 on MacOS

Post by caiot5 »

TonyM wrote: Mon 07 Dec, 2020 5:11 pm I was able to compile v17 on Mac OS with no additional changes from the original instructions (I'm on OSX 10.14.6) but I've noticed that some of my machines now run dog slow. If I copy the pcem executable v16 back over everything runs normal again. It seems to affect the PMMX class machines.
The reason for some of your machines are behaving so freaking slow is that the Dynamic Recompiler is completely broken on macOS with (pcem) v17, so every machine that relies only on Dynarec (like Pentium-class CPUs) are unusablely slow.
All that is left for us is downgrade to v16 again and hope that someday someone could fix the dynarec for macOS (which I would not expect much since there is such a low interest in porting properly Pcem for macOS).
StLouisCPhT
Posts: 4
Joined: Thu 19 Nov, 2020 5:18 pm

Re: v17 on MacOS

Post by StLouisCPhT »

caiot5 wrote: Wed 13 Jan, 2021 9:21 pm (which I would not expect much since there is such a low interest in porting properly Pcem for macOS).
That comment is not exactly going to encourage Sarah or anyone else to help out.

And making a post that is not even relevant to the post topic (building v17 on macOS) is bad form also.
Last edited by StLouisCPhT on Sat 16 Jan, 2021 11:26 pm, edited 1 time in total.
caiot5
Posts: 3
Joined: Sat 09 Jan, 2021 3:41 am

Re: v17 on MacOS

Post by caiot5 »

I wasn't trying to motivate anyone. It's up to her to code whatever she wants to. I just wanted to give a technical approach to this topic since no one ever mentioned that the problem was with the Dynamic Recompiller before.
So yes, it was quite relevant from the technical point of view.
It's your comment just to criticize me that didn't added anything relevant to this discussion.
Kthxbye.
oberon8
Posts: 1
Joined: Mon 15 Feb, 2021 12:17 pm

Re: building v17 on MacOS

Post by oberon8 »

I got the following error messages when do the compiling, any suggestion?
Undefined symbols for architecture x86_64:
"_azt1605_device", referenced from:
_sound_cards in pcem-sound.o
"_azt2316a_device", referenced from:
_sound_cards in pcem-sound.o
"_azt2316a_enable_wss", referenced from:
_sb_exec_command in pcem-sound_sb_dsp.o
"_codegen_timing_cyrixiii", referenced from:
_cpu_set in pcem-cpu.o
"_codegen_timing_p6", referenced from:
_cpu_set in pcem-cpu.o
"_creative_voodoo_banshee_device", referenced from:
_video_cards in pcem-video.o
"_cs8230_init", referenced from:
_at_cs8230_init in pcem-model.o
(maybe you meant: _at_cs8230_init)
"_ddc_i2c_change", referenced from:
_mach64_ext_writeb in pcem-vid_ati_mach64.o
_s3_virge_mmio_write in pcem-vid_s3_virge.o
"_ddc_init", referenced from:
_mach64_common_init in pcem-vid_ati_mach64.o
_s3_virge_init in pcem-vid_s3_virge.o
_s3_virge_375_init in pcem-vid_s3_virge.o
"_ddc_read_clock", referenced from:
_mach64_ext_readb in pcem-vid_ati_mach64.o
_s3_virge_mmio_read in pcem-vid_s3_virge.o
"_ddc_read_data", referenced from:
_mach64_ext_readb in pcem-vid_ati_mach64.o
_s3_virge_mmio_read in pcem-vid_s3_virge.o
"_f82c710_upc_device", referenced from:
_models in pcem-model.o
"_i440bx_init", referenced from:
_at_ga686bx_init in pcem-model.o
"_i440bx_reset", referenced from:
_at_ga686bx_init in pcem-model.o
"_i440fx_init", referenced from:
_at_vs440fx_init in pcem-model.o
"_i440fx_reset", referenced from:
_at_vs440fx_init in pcem-model.o
"_mvhd_calc_size_sectors", referenced from:
_hdnew_dlgproc in pcem-wx-config.o
"_mvhd_close", referenced from:
_hdd_load_ext in pcem-hdd_file.o
_hdd_close in pcem-hdd_file.o
_hd_file in pcem-wx-config.o
_hdnew_dlgproc in pcem-wx-config.o
_create_drive_vhd_fixed in pcem-wx-config.o
"_mvhd_create_ex", referenced from:
_hdnew_dlgproc in pcem-wx-config.o
"_mvhd_create_fixed", referenced from:
_create_drive_vhd_fixed in pcem-wx-config.o
"_mvhd_diff_update_par_timestamp", referenced from:
_hd_file in pcem-wx-config.o
"_mvhd_errno", referenced from:
_hdd_load_ext in pcem-hdd_file.o
"_mvhd_file_is_vhd", referenced from:
_hdd_load_ext in pcem-hdd_file.o
_hd_file in pcem-wx-config.o
"_mvhd_format_sectors", referenced from:
_hdd_format_sectors in pcem-hdd_file.o
"_mvhd_get_geometry", referenced from:
_hdd_load_ext in pcem-hdd_file.o
_hd_file in pcem-wx-config.o
_hdnew_dlgproc in pcem-wx-config.o
"_mvhd_open", referenced from:
_hdd_load_ext in pcem-hdd_file.o
_hd_file in pcem-wx-config.o
"_mvhd_read_sectors", referenced from:
_hdd_read_sectors in pcem-hdd_file.o
"_mvhd_strerr", referenced from:
_hdd_load_ext in pcem-hdd_file.o
_hd_file in pcem-wx-config.o
"_mvhd_write_sectors", referenced from:
_hdd_write_sectors in pcem-hdd_file.o
"_mystique_device", referenced from:
_video_cards in pcem-video.o
"_pc87307_init", referenced from:
_at_vs440fx_init in pcem-model.o
"_piix_pm_init", referenced from:
_piix4_init in pcem-piix.o
"_piix_pm_pci_read", referenced from:
_piix_read in pcem-piix.o
"_piix_pm_pci_write", referenced from:
_piix_write in pcem-piix.o
"_scamp_init", referenced from:
_at_scamp_init in pcem-model.o
(maybe you meant: _at_scamp_init)
"_scsi_ibm_device", referenced from:
_hdd_controllers in pcem-hdd.o
"_superxt_init", referenced from:
_pc5086_init in pcem-model.o
"_upc_set_mouse", referenced from:
_mouse_ps2_init in pcem-mouse_ps2.o
_mouse_intellimouse_init in pcem-mouse_ps2.o
"_vl82c480_init", referenced from:
_ps1_m2133_init in pcem-model.o
"_voodoo_3_2000_device", referenced from:
_video_cards in pcem-video.o
"_voodoo_3_3000_device", referenced from:
_video_cards in pcem-video.o
"_voodoo_banshee_device", referenced from:
_video_cards in pcem-video.o
"_voodoo_callback", referenced from:
_voodoo_card_init in pcem-vid_voodoo.o
_voodoo_2d3d_card_init in pcem-vid_voodoo.o
"_voodoo_codegen_close", referenced from:
_voodoo_card_close in pcem-vid_voodoo.o
"_voodoo_codegen_init", referenced from:
_voodoo_card_init in pcem-vid_voodoo.o
_voodoo_2d3d_card_init in pcem-vid_voodoo.o
"_voodoo_fb_readl", referenced from:
_voodoo_readl in pcem-vid_voodoo.o
"_voodoo_fb_readw", referenced from:
_voodoo_readw in pcem-vid_voodoo.o
"_voodoo_fifo_thread", referenced from:
_voodoo_card_init in pcem-vid_voodoo.o
_voodoo_2d3d_card_init in pcem-vid_voodoo.o
"_voodoo_flush", referenced from:
_voodoo_readl in pcem-vid_voodoo.o
"_voodoo_generate_filter_v1", referenced from:
_voodoo_card_init in pcem-vid_voodoo.o
"_voodoo_generate_filter_v2", referenced from:
_voodoo_card_init in pcem-vid_voodoo.o
_voodoo_2d3d_card_init in pcem-vid_voodoo.o
"_voodoo_pixelclock_update", referenced from:
_voodoo_writel in pcem-vid_voodoo.o
_voodoo_speed_changed in pcem-vid_voodoo.o
"_voodoo_queue_command", referenced from:
_voodoo_writew in pcem-vid_voodoo.o
_voodoo_writel in pcem-vid_voodoo.o
_voodoo_snoop_writew in pcem-vid_voodoo.o
"_voodoo_recomp", referenced from:
_voodoo_add_status_info in pcem-vid_voodoo.o
"_voodoo_render_thread_1", referenced from:
_voodoo_card_init in pcem-vid_voodoo.o
_voodoo_2d3d_card_init in pcem-vid_voodoo.o
"_voodoo_render_thread_2", referenced from:
_voodoo_card_init in pcem-vid_voodoo.o
_voodoo_2d3d_card_init in pcem-vid_voodoo.o
"_voodoo_render_thread_3", referenced from:
_voodoo_card_init in pcem-vid_voodoo.o
_voodoo_2d3d_card_init in pcem-vid_voodoo.o
"_voodoo_render_thread_4", referenced from:
_voodoo_card_init in pcem-vid_voodoo.o
_voodoo_2d3d_card_init in pcem-vid_voodoo.o
"_voodoo_threshold_check", referenced from:
_voodoo_writel in pcem-vid_voodoo.o
"_voodoo_wake_fifo_thread", referenced from:
_voodoo_readl in pcem-vid_voodoo.o
_voodoo_writel in pcem-vid_voodoo.o
"_voodoo_wake_fifo_thread_now", referenced from:
_voodoo_readw in pcem-vid_voodoo.o
_voodoo_readl in pcem-vid_voodoo.o
"_voodoo_wake_fifo_threads", referenced from:
_voodoo_writel in pcem-vid_voodoo.o
"_voodoo_wake_timer", referenced from:
_voodoo_card_init in pcem-vid_voodoo.o
_voodoo_2d3d_card_init in pcem-vid_voodoo.o
"_w83977tf_init", referenced from:
_at_ga686bx_init in pcem-model.o
"_x87_timings", referenced from:
_opFADDs_a16 in pcem-386_dynarec.o
_opFMULs_a16 in pcem-386_dynarec.o
_opFCOMs_a16 in pcem-386_dynarec.o
_opFCOMPs_a16 in pcem-386_dynarec.o
_opFSUBs_a16 in pcem-386_dynarec.o
_opFSUBRs_a16 in pcem-386_dynarec.o
_opFDIVs_a16 in pcem-386_dynarec.o
...
"_x87_timings_287", referenced from:
_cpu_set in pcem-cpu.o
"_x87_timings_387", referenced from:
_cpu_set in pcem-cpu.o
"_x87_timings_486", referenced from:
_cpu_set in pcem-cpu.o
"_x87_timings_8087", referenced from:
_cpu_set in pcem-cpu.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [pcem] Error 1
make: *** [all-recursive] Error 1
RichCini
Posts: 6
Joined: Thu 11 Mar, 2021 10:08 pm

Re: building v17 on MacOS

Post by RichCini »

First off, great emulator. I love the ability to emulate specific models of vintage PCs. I mostly use Macs, and I to am having some challenges building an OSX Catalina version, but it seems like a UX (user interface) issue with missing menus.

There is a fork of PCemv17 that the OSX changes noted above are already done, so I started from that. If you look at the terminal, it says "Menu item not found:" followed by various menu_ids (mostly 1403 and 1404). The emulation seems to run OK other than those errors. I did stumble upon another thread which mentions right-clicking on the screen to bring up the menus, which indeed worked (so that's good) but I didn't know if the error signified anything important or that needed to be fixed somewhere.

Thanks!

Rich
Post Reply