User:Compyx: Difference between revisions

From vice-emu
Jump to navigation Jump to search
Line 24: Line 24:


Use gmake when building VICE! Use normal make when installing from the ports system.
Use gmake when building VICE! Use normal make when installing from the ports system.


===== Ports =====
===== Ports =====

Revision as of 13:02, 13 October 2016

Who am I

I'm an old C64 scener, look me up at csdk.dk if you don't believe me ;)

Personal devlog

TODO list

  • 2016-09-xx: Try to build VICE on Minix 3.2.x (2016-10-05: Minix' own ports systems fails miserably building subversion)
  • 2016-09-29: Test Android SDL2 build
  • 2016-09-29: Fix build system for *BSD ports (2016-10-03: Done for FreeBSD, NetBSD, DragonflyBSD)
  • 2016-10-02: Gtk2 crashes NetBSD VirtualBox VM, why? Logging doesn't help, empty log
  • 2016-10-08: Clean up resource/cmdline code, using some kind of memory management/free list.
  • 2016-10-09: Clean up c1541 and update man page.
  • 2016-10-12: Update build systems with checks for minimum version required for autoconf and automake

BSD build system adventures

FreeBSD/PC-BSD

Version(s) tested: PC-BSD 10.3 amd64 (PC-BSD which is a preconfigured X11 install of FreeBSD)

Use gmake when building VICE! Use normal make when installing from the ports system.

Ports
  • Xaw: builds and runs
  • Gtk2: builds and runs
  • Gtk3: builds and runs
  • SDL1: builds and runs
  • SDL2: builds and runs (very well even, best performance of the ports I've tested, most likely thanks to VirtualBox using HW rendering on my host)

(Tested in VirtualBox VM with guest additions). Still need to do a write-up on which libraries should be installed for building and for each specific port.

NetBSD

Version(s) tested: 7.0.1 amd64 (on VirtualBox 5.1.6)

Use gmake!

Some notes/observations:

  • It has few weird conflicts with library interdependencies: a lot of foo.so.x needed but foo.so.y found, etc. May need to test the pkgsrc system, see if that behave any better, and perhaps run the system on bare metal.
  • /dev/joy0 and /dev/joy1 can't be opened, <machine/joystick.h> is there and compiling against it works, same goes for USB joysticks, after installing libusb, usbhidapi and some others, configure sees the USB joystick support, but it doesn't work. Most likely a VirtualBox problem.
  • HW rendering failed to build (failed at libdrm) while installing MesaLib7 through pkgsrc. So some ports had horrible performance.
  • Sounds seems to work, but VBox doesn't output anything, most likely again a VBox issue, there are no guest-additions for NetBSD, there is an effort started in 2013 to port FreeBSD's guest additions to NetBSD, but that was abandoned.

All issues are related to properly configuring NetBSD, not something for VICE to worry about.

Ports
  • Xaw: builds and runs
  • Gtk2: builds and runs
  • Gtk3: builds, starts, but hangs on initializing the Gtk3 widget for displaying the actual screen ("Gtk-WARNING **: Allocating size to GtkWindow 0x7f7ff493cd20 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate?")
  • SDL1: builds and runs, no HW acceleration yet, needs Mesa, which fails to build
  • SDL2: builds and 'runs' (5fps, most likely due to Gallium using software rendering)
In-tree libraries

--enable-static-ffmpeg fails when building src/lib/libx264 => configure script needs bash, standard shell fails.

OpenBSD

Version(s) tested: 6.0 amd64

Can't get the bloody X server to behave :) (Again in VBox VM)

OpenBSD doesn't provide guest additions for VirtualBox, so for me sound output failed.

Ports

  • Xaw: builds and runs
  • Gtk2: builds and runs
  • Gtk3: builds and runs
  • SDL1: builds and runs
  • SDL2: doesn't build, problem with uncompilable SDL2 headers

For some reason the SDL2 configure fails on the SDL2 headers. Need to figure out why?

Dragonfly BSD

Version(s) tested: 4.6 amd64 (inside a VirtualBox 5.1.6 VM, configured as FreeBSD)

Use gmake when building VICE.

Sound in VirtualBox

VB's default emulated audio device 'ich' causes some problems, so I set it to 'Intel HD Audio'. I had to add snd_hda_load="YES" to /boot/loader.conf to tell the kernel to load the Intel HD Audio driver to get access to dev/dsp for sound output. I then installed the alsa-utils package to get access to alsamixer to set proper volume. alsamixer needed to be called with its full path `/usr/local/bin/alsamixer` since Dragonfly BSD doesn't include /usr/local/bin in PATH.

GNU gettext

Make in po/ will output an error: sed: ./vice.pot: No such file or directory, when GNU gettext isn't installed. Install gettext and gettext-tools to avoid this.

Ports

  • Xaw: builds and runs
  • Gtk2: builds and runs
  • Gtk3: builds and runs, same issues as the Gtk2 port, selecting an item in the GUI causes ALSA to overflow the sound buffer, and VICE hangs
  • SDL1: builds and runs
  • SDL2: builds and runs

Minix build system

Minix 3.3.0 doesn't provide X11 out of the box (eg binary packages), so I'll start with 3.2.1. I have no experience with Minx, except for installing it once about ten years ago, and deciding it sucked.

Minix 3.2.1

Useless. Subversion must be built from source through pksrc, but building fails with circular dependencies with libtool. GCC is 2.95(!), which is ancient.

Minix 3.3.0

Perhaps I'll look a this when I have absolutely nothing better to do, or am very drunk.

Preparing for removing Gtk2 in favour of Gtk3

Since most modern operating systems used for VICE have support for Gtk3 and Gtk2 is no longer maintained, it makes sense to prepare VICE for using Gtk3 in stead of Gtk2. This means, for now, using a gtk2legacy wrapper module Groepaz started. This provided wrappers around Gtk2 code using the Gtk3 API.

The idea is to use the Gtk3 API in all Gtk/Gnome code while providing wrappers in gtk2legacy that translate those Gtk3 API calls into equivalent Gtk2 API calls. Once the Gtk2 API has finally been deprecated, we can simply remove gtk2legacy and use pure Gtk3.

The minimum Gtk3 version supported should be 3.16, since that introduces GtkGlArea, which should replace GtkGlExt.


GTk3 support for various operating systems
OS distro/version arch Gtk2 version Gtk3 version date checked notes
Linux Debian Jessie 8.6 amd64 2.24.25 3.14.5 2016-10-09
Linux Fedora 24 amd64 2.24.31 3.20.9 2016-10-05
Linux Mint 17.3 amd64 2.24.3 3.10.18 2016-10-05
Linux Mint 18.0 amd64 2.24.30 3.18.9 2016-10-05
BSD FreeBSD 10.3 amd64 2.24.29 3.18.8 2016-10-05 used the ports collection
BSD FreeBSD 11.0 amd64 2.24.29 3.18.8 2016-10-12
BSD NetBSD 7.0.1 amd64 2.24.30 3.20.6 2016-10-05 used binary (pkgin) packages
BSD OpenBSD 6.0 amd64 2.24.30 3.20.6 2016-10-12 used binary packages
BSD DragonflyBSD 4.6 amd64 2.24.29 3.18.8 2016-10-13
Minix 3.2.1 i386 n/a n/a 2016-10-05 the whole Minix build system is broken


Porting Gtk2 container types to Gtk3 container types

The current advise of Gtk3 is to use GtkGrid for any kind of layout container. Even GtkBox will someday be deprecated in favour of GtkGrid. For now, I'll use GtkBox untill the Gtk2 port has been completely removed, then we can tackle this.

GtkHBox and GtkVBox

GtkHBox and GtkVBox have been deprecated in favour of GtkBox.

I wrote a wrapper in gtk2legacy.c so Gtk2 code can use GtkBox while using the underlying GtkHBox/GtkVBox widgets. Naturally these calls aren't fully compatible, gtk_hbox_new() and gtk_vbox_new() use a `homogeneous` argument which determines if all widgets should be the same size. Since all VICE code use FALSE for this, gtk_box_new() works without having to set the homogeneous property afterwards.

GtkTable

GtkTable has been deprecated in favour of GtkGrid, porting this should be too much hassle, but lets see.