C++ Programming for Lich...where to start?

OWL
#6

Like the Readme says, you need GCC ARM compiler. It’s a separate software project and should be installed for building patches that will run on OWL.

MinGW includes only x86 version of GCC. But you will use other GNU tools that MinGW installs (make command among them). This is all described in makefile format and you don’t have to figure it out how it works - just run a commands or two to rebuild patches or libraries. It’s also possible to use x86 version of GCC to build native executables if you’ll want to troubleshoot code later.

You’ll also need FirmwareSender executable to convert patch binaries into sysex format and send to device. There’s a binary release of older version on github, it might still work. Otherwise you’ll have to built it too (or maybe @mars can make builds of newer release for Win/Mac)

#7

OK, thanks again…progress(sorry it’s slow)…so far.

I’m going to document for anyone who reads the thread.
ARM GCC compiler downloaded from

…be careful, default location for installation is in Program Files folder, that’s no good because it contains space characters.
I put it in C:\GNUArm for simplicity

C:\GNUArm\bin is now location of arm-none-eabi-gcc.exe

I’ve edited compile.mk so the TOOLROOT variable points to those ( i think, not seen absolute address elsewhere in compile.mk)

TOOLROOT ?= C:/GNUArm/bin/

I have the FirmwareSender.exe executable downloaded (no installation)

So what’s the next step?
“issue the appropriate make command”? …how?
the only make.exe I see is in the MinGW

#8

No worries, I think you’re almost there.

So you can’t run this in windows shell as it won’t see APIs provided by MinGW/MSYS. A part of MSYS is bash shell, so you should launch bash.exe and that should let you run commands for building everything (make and friends).

There might be some shortcut installed for running bash or there are a few terminal emulators you could use to run bash, but this is optional.

#9

thanks for persisting
OK I found Bash.exe in MinGW.
It opens a console.
It runs make but can’t find “makefile” (not surprising)

I made a shortcut for bash.exe so I could run it from the folder with the compile.mk in it.

From bash I can then run make and I assume it finds “makefile” as that error is gone.

It then produces a lot of line numbers and says they have syntax errors.

#10

Well it sounds like you can run “make libs” now to build static libraries (ignoring errors caused by emcc not installed) and then build/upload patches as the README file describes.

#11

Well, yes, something happens, and I appear to have the prerequisites in place (in not necessarily configured).

I can run make lib, but
All I get is a list of syntax errors.
(and the same if I just run make)

but then I don’t really know what I’m doing.

The problem is with the term “run”.
What method do I use to run it, and where in the directory structure do I run it from?

Using Bash seems to be no different to using command prompt (in terms of result)

(in other news EMCC install and activate seemed to go ok, and the OpenWareLab docs for how the C++ code works are looking good)

#12

Runs means literally type in terminal for bash to execute. So in case of “make libs”, “make” is the command and “libs” is the target that is defined in makefile. Naturally you should be running this from OwlProgram root.

So what are you trying to run and what’s the error you get?

#13

Thanks again.
Yes, if “OwlProgram Root” is the location of compile.mk (etc.) then that’s indeed where I’m running it from.
I start the bash console (with shortcut edited to use that location) and type make libs.
I get a list of error messages, mostly “syntax error”.
Exactly the same happens if I just run make lib from the DOS Prompt.

If I run from a different location I get the response “can’t find makefile”
I just checked, and if I remove the file “makefile” from the folder then make won’t find it.
So make is looking at that “makefile” file and seeing syntax errors.
…but opening ‘makefile’ doesn’t reveal anything that looks like a syntax error.
(first 4 error of syntax reported on lines 4,5,7,9,

#14

I would suggest to post output of “make libs” here, it’s not clear what the actual error is.

Also, if you’re not using OwlProgram from develop branch, it may be better to do that. And make sure to install git submodules like README instructs.

#15

bash.exe"-3.1$ make libs
MAKE Version 5.4 Copyright (c) 1987, 2010 Embarcadero Technologies, Inc.
Error makefile 4: Command syntax error
Error makefile 5: Command syntax error
Error makefile 7: Command syntax error
Error makefile 9: Command syntax error
Error makefile 10: Command syntax error
Error makefile 12: Command syntax error
Error makefile 14: Command syntax error
Error makefile 19: Command syntax error
Error makefile 25: Command syntax error
Error makefile 31: Command syntax error
Error makefile 37: Command syntax error
Error makefile 43: Command syntax error
Error makefile 49: Command syntax error
Error makefile 51: Command syntax error
Error makefile 53: Command syntax error
Error makefile 56: Command syntax error
Error makefile 60: Command syntax error
Error makefile 65: Command syntax error
Error makefile 79: Command syntax error
Error makefile 80: Command syntax error
Error makefile 81: Command syntax error
Error makefile 82: Command syntax error
Error makefile 83: Command syntax error
Error makefile 84: Command syntax error
Error makefile 92: Colon expected
Error makefile 93: Command syntax error
Error makefile 94: Command syntax error
Error makefile 95: Command syntax error
*** 28 errors during make ***
bash.exe"-3.1$

#16

OK, there’s the error messages ^

I think issue is that the bash is picking up a different make executable that is on the windows system paths, while the one that’s at C:\MinGW\msys\1.0\bin .is hidden. Although bash is located also in C:\MinGW\msys\1.0\bin I’m running it from OwlProgram-develop.
So bash can’t see the correct version of make.exe

This is why I had real doubts about the setup working, because there are different elements of the system in completely different directory structures.

I’ve tried to follow the readme, but I don’t think it’s intended as a cookbook for Windows installation.

#17

Yes, that’s wrong “make” apparently, you should see something like this from version prompt (make -v):

$ make -v
GNU Make 4.3
...other stuff

I think you need to modify PATH variable to something like this:
PATH=C://wherever/correct/make/is/installed/:${PATH}

Yes it’s not heavily used on Windows. An alternative is to use Windows Subsystem for Linux, this basically gives you a virtualized Linux kernel and necessary software, so you would be able to follow instructions intended for Linux. That’s in theory, I don’t know if anyone used it with OWL (but I’ve heard WSL2 works quite well).

#18

I think that’s not the make that is installed with ming. Look for ming32-make.exe, ie try
ming32-make libs
You might have to give a full absolute path to ming32-make or add the ming bin directory to your path.

#19

Thanks again, progress at last.

Text from bash console.
Yes, it was picking up a different version of make, connected with Delphi.
with comments

bash.exe"-3.1$ make -v
MAKE Version 5.4 Copyright (c) 1987, 2010 Embarcadero Technologies, Inc.

the one I want is here

bash.exe"-3.1$ C:/MinGW/msys/1.0/bin/make -v
GNU Make 3.81

some time later…tell bash where it is (and also the other stuff it needs)
the " are needed .

bash.exe"-3.1$ export PATH=“C:\MinGW\msys\1.0\bin”

check that PATH is now correctly defined

bash.exe"-3.1$ export
declare -x !::="::\"
declare -x ALLUSERSPROFILE=“C:\ProgramData”
declare -x APPDATA=“C:\Users\Andy\AppData\Roaming”
declare -x COMMONPROGRAMFILES=“C:\Program Files (x86)\Common Files”
declare -x COMMONPROGRAMFILES(X86)=“C:\Program Files (x86)\Common Files”
declare -x COMMONPROGRAMW6432=“C:\Program Files\Common Files”
declare -x COMPUTERNAME=“ANDY-PC”
declare -x COMSPEC=“C:\WINDOWS\system32\cmd.exe”
declare -x FP_NO_HOST_CHECK=“NO”
declare -x HOMEDRIVE=“C:”
declare -x HOMEPATH="\"
declare -x IBREDISTDIR=“C:\Users\Public\Documents\InterBase\redist\InterBa
seXE3”
declare -x LOCALAPPDATA=“C:\Users\Andy\AppData\Local”
declare -x LOGONSERVER="\\ANDY-PC"
declare -x NUMBER_OF_PROCESSORS=“4”
declare -x OLDPWD
declare -x OS=“Windows_NT”
declare -x PATH=“C:\MinGW\msys\1.0\bin”
declare -x PATHEXT=".COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC;.PY;.P
YW"
declare -x PROCESSOR_ARCHITECTURE=“x86”
declare -x PROCESSOR_ARCHITEW6432=“AMD64”
declare -x PROCESSOR_IDENTIFIER=“Intel64 Family 6 Model 58 Stepping 9, GenuineIn
tel”
declare -x PROCESSOR_LEVEL=“6”
declare -x PROCESSOR_REVISION=“3a09”
declare -x PROGRAMDATA=“C:\ProgramData”
declare -x PROGRAMFILES=“C:\Program Files (x86)”
declare -x PROGRAMFILES(X86)=“C:\Program Files (x86)”
declare -x PROGRAMW6432=“C:\Program Files”
declare -x PSMODULEPATH=“C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules
\”
declare -x PUBLIC=“C:\Users\Public”
declare -x PWD="/c/OwlProgram-develop/OwlProgram-develop"
declare -x SESSIONNAME=“Console”
declare -x SHLVL=“1”
declare -x SYSTEMDRIVE=“C:”
declare -x SYSTEMROOT=“C:\WINDOWS”
declare -x TEMP="/tmp"
declare -x TERM=“cygwin”
declare -x TMP="/tmp"
declare -x USERDOMAIN=“Andy-PC”
declare -x USERDOMAIN_ROAMINGPROFILE=“Andy-PC”
declare -x USERNAME=“Andy”
declare -x USERPROFILE=“C:\Users\Andy”
declare -x VS120COMNTOOLS=“C:\Program Files (x86)\Microsoft Visual Studio 12.0
\Common7\Tools\”
declare -x VS80COMNTOOLS=“C:\Program Files (x86)\Microsoft Visual Studio 8\Co
mmon7\Tools\”
declare -x WINDIR=“C:\WINDOWS”

now see if it actually works…it does

bash.exe"-3.1$ make libs
/bin/sh: emcc: command not found
make[1]: *** [Build/web/ColourScreenPatch.o] Error 127
make: *** [libs] Error 2

So that’s as you predicted, just an error for emcc

EMCC is installed though, so would be good to get that working.

I put FirmwareSender.exe in the OwlProgram-develop\Tools firectory,
because “Makefile” has the following line in it

FIRMWARESENDER ?= Tools/FirmwareSender

#20

Yeah it looks like emcc is installed somewhere not on the PATH variable and it’s not visible to bash and make. It’s ok because you only need it to build web versions of patches that can run in the browser.

You can check contents of Libraries directory, if it has those 2 files then the libraries are built: libdaisysp.a and libowlprg.a. As your error only mentioned lack of emcc, they should be there.

You could run something like make clean load PATCHNAME=Awesome to build a patch from PatchSource/AwesomePatch.hpp . This would load patch into memory and the README describes how to store them on device and other targets defined in Makefile. So I think you could try running actual code now.

#21

Hey, THAT WORKS :slight_smile:

I have to enter
export PATH=C:\MinGW\msys\1.0\bin\
every time I open the Bash console.

that may not apply to every Windows user, they may be able to put it on the system PATH,
I can’t do that because I can’t risk conflicting with Delphi, which I use for commercial programming.

Thanks for all your help,

#22

Glad to know that it ended up with a success. Normally it takes less effort, but whatever. You might be able to configure bash to add any necessary variables when it starts if you add export PATH=C:\MinGW\msys\1.0\bin\ to .bashrc file in your home directory, so at least it would be less annoying. Generally on Linux you would modify this variable rather then replace it complitely, so it would be something like export PATH=C:\MinGW\msys\1.0\bin\:$PATH

#23

There isn’t a .bashrc, and bizarrely windows won’t let me make one with that name.
Just a note for future explorers:-
On windows export PATH=C:\MinGW\msys\1.0\bin\ won’t work, must be.
export PATH=C:\MinGW\msys\1.0\bin\
or
export PATH=“C:\MinGW\msys\1.0\bin”

There’s a bash.bat instead, but doesn’t look promising at first glance. It’s really not a problem to set the PATH once at the start of a session.

Well if there is a “something like” that works I didn’t find it yet. I suspect the problem is with the : which is used as a de-limiter in Linux, burt also as part of the path ( C:\ ) in windows.

I’m still trying to find a way round this so I can put EMCC on the path.
Maybe that’s not the place to put EMCC on the path though, I wonder if it’s it’s possible to edit web.mk to tell it where to find emcc?

I know this has taken a while, I appreciate your help.
There’s a couple of other things I did to make it work, would you like me to document here?

#24

Not having .bashrc is fine - the point is that it gets read if it exists, but it doesn’t have to exist for bash to work. Bash.bat is just windows shell file that runs bash, however you could try to modify it to replace .bashrc with a different name that can be created. Then you would have something like bash ...current_arguments... --rcfile /path/to/new_rc_file.

Regarding emcc, you could add it’s directory to PATH the same way. Another option is to change web.mk to use absolute path like EMCC = C:\path\to\emcc. Also note that EMCC ?= x just sets default value to environment variable EMCC to x, but you can define EMCC outside of Makefile i.e. in .bashrc or another profile file using export or in bash.bat (probably using set command for windows shell)

Yeah, I think this may help someone else trying to use Windows, so feel free to add more info.

#25

OK.

"open compile.mk
and point TOOLROOT to your gcc installation directory, using a path string without
spaces (such as using 8.3 filenames)."

In my case

TOOLROOT ?=C:\GNUArm\bin is now location of arm-none-eabi-gcc.exe

In the directory I made for the OwlProgram stuff I created a shortcut to run bash.exe.
On my system it’s
C:\OwlProgram-develop\OwlProgram-develop
I put that directory as “Start In” for the shortcut.

FirmwareSender.exe needs to be put in the Tools folder
C:\OwlProgram-develop\OwlProgram-develop\Tools on my system
downloaded from
https://github.com/pingdynasty/FirmwareSender/releases/download/v0.1/FirmwareSender-windows.zip
as recommended above.

I run Bash, it then needs to be told where to find the stuff it needs:-

export PATH=C:\\MinGW\\msys\\1.0\\bin\\

(the double backslash is essential)
This has to be done every session, but could be added to the windows system path ( just can’t do that on my system because I already have a different ‘make’ used by Delphi)

Once that’s done things like
make libs
and
make clean load PATCHNAME=MidiModular
work as expected, and windows specific issues are over.

EMCC …I stopped bothering with it as I don’t need it. Running make loads the binary direct to the Lich.