building in clean state pi3

[Larswad]

Just tried to see if I could fix myself the issue that I mentioned before, about freeze shortcuts etc.
I think I got the toolchain up and changing path's according to my own locations.

If I try to build the pi3 kernel from a clean state there are failures, among other a missing include path. (viceapp.h:40:10: fatal error: circle_glue.h: No such file or directory)

If I build the pi2 kernel FIRST it seems as if it goes away (if I answer no to the patches). There is one line less for the configure part in the pi3 case in the make_all.sh script. Maybe one line is missing there?

Then again, even if does build for pi3 after that, I am not yet sure if I got the patches right because I can't re-patch after having done that once since the build (as mentioned) is not meant for rebuilding without running clean_all.sh. But I will test the pi3 and see what happens.

Just wanted to mention all this, I hope you can reproduce it.
BTW, I'm using the "gcc-arm-none-eabi-8-2018-q4-major" toolchain. Not sure if you've tested the latest one.

[lroby74]

With last 2 versions (1.5 and 1.6) i was no longer able to compile (using Lubuntu) the Kernel for the Raspberry 2 or the one for the 3 neither, infact i use only precompiled kernel now

[randyrossi]

Im using rpi-tools/arm-bcm2708/arm-rpi-4.9.3-linux-gnueabihf when I compile. I tried a clean checkout and the make_all.sh script worked for me. I'm not sure why include paths seem to not be set properly when you build. Try using this compiler on your path and first run clean_all.sh, then make_all.sh pi3 Do you have spaces in the path to wherever you checked out the source? I'm wondering if that makes the script fail. It's not very robust. I have no spaces in any dir to the path that holds the source.

…

On Sun, Apr 21, 2019 at 6:50 PM lroby74 ***@***.***> wrote: With last 2 versions (1.5 and 1.6) i was no longer able to compile (using Lubuntu) the Kernel for the Raspberry 2 or the one for the 3 neither, infact i use only precompiled kernel now — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#38 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAI3HKFH2IP4QHRLKRTLQRDPRTVS3ANCNFSM4HHMRMAQ> .

-- Randy Rossi C:(+1)416-605-5112 (Canada) - "There are only two things that are hard about computer science; Naming things, Cache Invalidation, and Off-by-one errors."

[Larswad]

ok, many thanks for the tips!
I am not sure, but I seem to need to have the "rpi-tools/arm-bcm2708/arm-rpi-4.9.3-linux-gnueabihf/bin" in the PATH variable. Not sure really what the recommended way is for that for the toolchain.

Then, one important thing was: It seems as though my ubuntu (18.04) uses automake 1.15.1, (not 1.15 which the configure files are based on).
So, cd'ing into the vice-3.3 and running "autoreconf -f -i" and just upgrading the m4 and .in files to the new version did the trick.
My additions compiled also so I'm gonna test that tomorrow.

If it works, I guess this can be closed, maybe with some clarifications in the readme about the automake version, and that the pi3 build uses the other toolchain. But I understand, don't waste any of time on this when there are more important things.

BTW, There's a lot of C-mindset in that old vice code (and I'm since many years back mostly a C++ guy), so I'm a bit horrified about the abundance of preprocessor relying code (lots #defines instead of enums etc).
Anyhow, it is what it is.

[Larswad]

Well, so I got the features that I wanted working.
CBM+F1 / F9 = Joyswap
CBM+F3 / F10 = Hard Reset
CBM+F5 / F11 = Cartridge Freeze
With menu items for enabling / disabled each individually.
Maybe it would also be possible to map some shifted keys like CBM+F2,
by combining CBM + CTRL + F2. Hmmm

Kind of the brute and ugly way I did this, since I realize it is better to list the menus
based on the keys, and then make it possible to let the user map freely each key to any
of some set of common actions.
That would also reduce the duplication in the code, especially in the kbd.c file.

So, I guess I'm very happy now.
A little annoyed that I have to do clean_all every time, then autoreconf -f -i and then rebuild.
Well at least I got all cores compiling for all make statements in the make_all.sh.

closing this issue!