HP Forums

Full Version: wp34s builds
You're currently viewing a stripped down version of our content. View the full version with proper formatting.

How do I build calc.bin from source?

I am sure this question pops up every time, but I still cannot find reasonable answer.

Here is what I've done so far:

I used wiki4hp link as a guide, but that seems to be dated and mentions files that are no longer in the tree.

I checked out source tree from SVN, installed Express 2010, MinGW, MSYS and managed to build gui and console emulators by hitting F7 on 'wp34s'.

It said that build failed, but updated "_d" executables. Here is last few lines in output.

10>  wp34s.vcxproj -> C:\Users\nsg\calc\wp34s\windows\bin\wp34s_d.exe
9> wp34sgui.vcxproj -> C:\Users\nsg\calc\wp34s\windows\bin\wp34sgui_d.exe
9> The system cannot find the path specified.
9>C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(113,5): error MSB3073: The command "copy ..\..\..\doc\Manual_wp_34s_2_2.pdf C:\Users\nsg\calc\wp34s\windows\bin\wp34s_Manual.pdf
9>C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(113,5): error MSB3073: :VCEnd" exited with code 1.
========== Build: 3 succeeded, 3 failed, 6 up-to-date, 4 skipped ==========

Then I looked for a way to build a calc.bin. I downloaded and installed yagarto-20121222 I even found the magic line

Quote:
make REALBUILD=1 all

But I am still missing some important configuration pieces. It looks like mingw does not know how to find yagarto or something.
Or there is something else I am missing?

cd windows32_realbuild \
&& ./compile_consts.exe "../" "../windows32_realbuild/obj/" \
&& mingw32-make "CFLAGS=-mthumb -mcpu=arm7tdmi -Os -fira-region=
one -Wall -Werror -g -fno-common -fno-exceptions -DREALBUILD -Dat91sam7l128 -Ia
tmel -DNO_BACKUP_INIT -DNO_RAM_COPY -I../.." -j2 -C consts
mingw32-make[1]: Entering directory `c:/Users/nsg/calc/wp34s/windows32_realbuild
/consts'
process_begin: CreateProcess(NULL, arm-none-eabi-gcc -mthumb -mcpu=arm7tdmi -Os
-fira-region=one -Wall -Werror -g -fno-common -fno-exceptions -DREALBUILD -Dat91
sam7l128 -Iatmel -DNO_BACKUP_INIT -DNO_RAM_COPY -I../.. -c -o const_NaN.o const_
NaN.c, ...) failed.
process_begin: CreateProcess(NULL, arm-none-eabi-gcc -mthumb -mcpu=arm7tdmi -Os
-fira-region=one -Wall -Werror -g -fno-common -fno-exceptions -DREALBUILD -Dat91
sam7l128 -Iatmel -DNO_BACKUP_INIT -DNO_RAM_COPY -I../.. -c -o const_inf.o const_
inf.c, ...) failed.
make (e=2): The system cannot find the file specified.
mingw32-make[1]: *** [const_NaN.o] Error 2
mingw32-make[1]: *** Waiting for unfinished jobs....
make (e=2): The system cannot find the file specified.
mingw32-make[1]: *** [const_inf.o] Error 2
mingw32-make[1]: Leaving directory `c:/Users/nsg/calc/wp34s/windows32_realbuild/
consts'
make: *** [consts.h] Error 2

Had to put yagarto's bin directory in the path with

Quote:
export PATH=$PATH:/c/bin/yagarto-20121222/bin

Now it fails at xrom build phase -- wp34s_asm.pl cannot find wp34s_pp.pl

tools/wp34s_asm.pl -pp -op tools/wp34s.op -c -o xrom.c xrom_pre.wp34s
// WARNING: Unrecognized O/S (msys). Some features may not work as expected.
// WP 34S assembly preprocessor enabled: '-pp'
// Opcode map source: tools/wp34s.op (specified)
// Opcode SVN version: -- unknown --
ERROR: c:\Users\nsg\calc\wp34s\tools\wp34s_asm.pl::run_pp: Cannot locate the ass
embly preprocessor in 'wp34s_pp.pl' or './wp34s_pp.pl'
mingw32-make[1]: *** [xrom.c] Error 2
mingw32-make[1]: Leaving directory `c:/Users/nsg/calc/wp34s'
make: *** [realbuild/calc.bin] Error 2

Edit:Now that I think about it, it is rather strange. Why would perl have no trouble finding _pp.pl with console emulator build, and not finding it with REALBUILD=1?


Edited: 20 June 2013, 8:58 p.m.

I'm interested in the answers you get to these questions. I wrestled with this about a year ago and got one or two successful builds, but then I got a new computer and I've not been able to build since. I have a few tweaks I like to make but now I just live with my year-old build. I am more successful building the emulator, although even that isn't straightforward.

It is an odd coincidence that this topic has come up because it is something that I just happened to be thinking about.

I decided that I wanted to make my own build, not because I had made changes, but because I wanted to be comfortable making reliable builds before I decided to try any changes.

It wasn't too difficult but it was a bit of a chore. I eventually figured it out and was able to build everything, including the library, and flash my calculator with the build. However, between mingw where I started, cygwin, and an ubuntu machine, it took me a number of missteps to figure out the right environment to do the build and the correct process to follow. I don't know whether this is because I did not find the right documentation, or didn't look hard enough, but it was what it was and it wasn't the smoothest of experiences.

Even now, I am not really sure whether the build is good. Just because it succeeded, is it OK?

The wp-34s project seems to have moved into a "bug-fix" mode and at some point in the not too distant future it will probably wind down completely. It seems that now is the time to think about how this project should be left for future generations. It only took me an hour or two to figure out how to build it this week, but a couple of years from now it will take longer and a couple of decades from now, I am sure it will be quite a struggle.

With most software, it probably doesn't matter. The software is either maintained, or it fades into obscurity without anyone caring. However, calculator fans are interested in machines from 40+ years ago and there is no reason to believe that 40 years from now, there won't be someone who will want to build the software and reflash a wp-34s. Is the project in a state that they will be able to do it easily?

I believe that there are a lot of things that could be done to bundle this project up into a form that would not only make it much easier for people to build today, but also that would leave it easier for people to build way down the road in the future.

Things like having local copies of all the correct version of all the open source tools and dependencies necessary to build the project, detailed documentation about process, configuration files to validate/configure the build based on the current environment, etc. Maybe even virtual machine images where you can just push a button and build....

I actually don't think that it would be a huge task. This is not that large a project and it is a relatively simple build process. It's certainly something that I would be willing to help with.

It gets stranger. I traced it to a perl script not being able to parse its own name. Sometimes.

I added the warn to tools/wp34s_asm.pl:

my $script_executable = $0;
my ($script_name, $script_dir, $script_suffix) = fileparse($script_executable);
warn "sys=$^O parse=$script_name, $script_dir, $script_suffix \n";

Now when I start it as "make REALBUILD=1 xrom.c" I get this:

echo tools
tools
tools/wp34s_asm.pl -pp -op tools/wp34s.op -c -o xrom.c xrom_pre.wp34s
// WARNING: Unrecognized O/S (msys). Some features may not work as expected.
sys=msys parse=wp34s_asm.pl, tools/,
// WP 34S assembly preprocessor enabled: '-pp'
// Opcode map source: tools/wp34s.op (specified)
// Opcode SVN version: -- unknown --
// Running WP 34S preprocessor from: tools/wp34s_pp.pl

When I start it as "make REALBUILD=1 all" I get this:

echo tools
tools
tools/wp34s_asm.pl -pp -op tools/wp34s.op -c -o xrom.c xrom_pre.wp34s
// WARNING: Unrecognized O/S (msys). Some features may not work as expected.
sys=msys parse=c:\Users\nsg\calc\wp34s\tools\wp34s_asm.pl, ./,
// WP 34S assembly preprocessor enabled: '-pp'
// Opcode map source: tools/wp34s.op (specified)
// Opcode SVN version: -- unknown --
ERROR: c:\Users\nsg\calc\wp34s\tools\wp34s_asm.pl::run_pp: Cannot locate the ass
embly preprocessor in 'wp34s_pp.pl' or './wp34s_pp.pl'
mingw32-make[1]: *** [xrom.c] Error 2
mingw32-make[1]: Leaving directory `c:/Users/nsg/calc/wp34s'
make: *** [realbuild/calc.bin] Error 2

Why at first invocation $0 gets relative path with "/" as a delimiter and next time it gets full path with "\" as a delimiter is beyond me. What is the difference between these 2 cases?

Andrew: I wrote an article about building the firmware on Windows 7 some time ago. Here it is: link to article. You may find this useful if you haven't already read it.

I still regularly build the firmware, so it can be done!

Nigel (UK)

Have you tried a different Perl implementation? I'm using ActivePerl for Windows on my build systems.

Marcus, any WP34s emulator update in sight?

There have already been 3 bugfixes this week, but still no new build ... :-(

Franz

I'm just too sick for any serious work. Maybe the upcoming weekend...

This all seems very familiar. I stumbled from one problem to the next for a couple of weeks. Tried this on a linux machine as well as windows and eventually gave up.
But then again, software isn't my strong point.

Edited: 21 June 2013, 8:26 a.m.

I has been WAY too long since I looked at or ran this but I suspect that your Perl implementation has something to do with it. What Perl are you running?

What is happening is that the assembler has been asked to run the preprocessor (the -pp switch spawns another Perl script called wp34_pp.pl) and the assembler is trying to locate that script (line 1798-1803). This is failing for your system. Oddly, the standard package File::Basename function 'fileparse' seems to returning paths in 2 distinct formats: one with back slashes and the other with a forward slash. I have no idea why this might be. You can see this in your added debug statement (warn ...).

You could try adding an explicit location to look for the preprocessor script to the makefile by using the "-pp_dir some_dir" switch on the assembler. It is undocumented in the script's help screen but you can find the code to read it in at line 2149 of the assembler (2150 of yours, I would guess). This should satisfy the test at line 1798.

Note that the tool was developed on Linux and has worked on the several systems I/we have tried thus far (including Windows 95!!). Unfortunately, the systems I developed this on are dismantled and in storage somewhere. That includes the Windows boxes I used as well. That limits the testing I am able to do.

Quote:
// WARNING: Unrecognized O/S (msys). Some features may not work as expected.

This warning can be safely ignored since all it is doing is enabling or disabling colour output on the screen ($use_ansi_colour). I think I originally had bigger plans for this test but they either were never put in or were removed -- can't recall.

BTW: This may or may not make a difference but when I grabbed a copy of the ZIP files, these Perl scripts get extracted without the executable flag being set in Linux. Might have some bearing on the problem -- I am not sure.

If you solve the problem, feel free to commit the fix.

Cheers...

Quote:
I'm just too sick for any serious work.

Oh, sorry to hear that.

Gute Besserung,

Franz

Looking at my wp34s_asm.pl file I find that I've made one change in it that I don't seem to have mentioned in my article (see my post below). I've changed line 186

my $preproc_fallback_dir = "";
to
my $preproc_fallback_dir = "C:/Users/nd/wp34s/new_wp34s/wp34s-code-nd/trunk/tools/";
which is simply the full path to the tools directory on my system.

I don't know whether this will help with your problem. I have ActivePerl installed on my system.

Nigel (UK)

I think I would prefer him using the command line option method to the change you have suggested since yours:

1) hard wires the path to a specific O/S (Windows), and

2) sets the path to a very specific directory tree used by your particular installation.

I think the method I suggested should be fairly universal (and it was obviously allowed for in the tool so I must have been thinking ahead a wee bit :-).

However, I do think this is pointing to the root cause of the problem.

Oddly, I am fairly sure I did test this setup using ActivePerl so it is a bit of a surprise that there are issues. When on Windows I tend to use cygwin -- and its Perl -- since I am more familiar with the Unix style of commands and really miss them when they are not there.

Cheers...

Sorry too but I've uploaded Qt emulators for svn revision 3414.
As I'm working on the iOS emulator, I do not always check if the Qt emulators are up to date but should you need a new build, you can ask me: building them is automated and takes me no time.

I have strawberry perl installed when I was running this. But I am pretty sure make runs whatever perl comes with MINGW/MSYS, the one in MSYS's /bin directory, so it does not make any difference. I probably should have mentioned that I start MinGW's bash-like console, cd to checked out wp34s directory and run the make there.
Is this the intended way? Or should I run make from window's cmd.exe?

I eventually worked around it by inserting 'perl' before script name, like this:

	perl $(TOOLS)/wp34s_asm.pl -pp -op $(OPCODES) -c -o xrom.c xrom_pre.wp34s
Why this makes any difference and why $0 was different at different invocations before -- I do not understand.

And it is not just random, it does it every single time: when the original line (without "perl") is called manually from command line (mingw's msys shell) or as 'make REALBUILD=1 xrom.c' it works as expected. $0 in perl is "tools/wp34s_asm.pl" and everything is fine. But when I call 'make REALBUILD=1 all' then something happens and $0 is 'c:\Users\nsg\calc\wp34s\tools\wp34s_asm.pl' which surprises File::Basename.

Anyway, here is a patch for Makefile that seems to fix it for me.

Index: Makefile
===================================================================
--- Makefile (revision 3412)
+++ Makefile (working copy)
@@ -398,7 +398,7 @@

xrom.c xrom_labels.h: xrom.wp34s $(XROM) $(OPCODES) Makefile features.h data.h errors.h
$(HOSTCC) -E -P -x c -Ixrom -DCOMPILE_XROM xrom.wp34s > xrom_pre.wp34s
- $(TOOLS)/wp34s_asm.pl -pp -op $(OPCODES) -c -o xrom.c xrom_pre.wp34s
+ perl $(TOOLS)/wp34s_asm.pl -pp -op $(OPCODES) -c -o xrom.c xrom_pre.wp34s

xeq.h:
@touch xeq.h

Thank you for writing this article. This was one of the sources I consulted when I was setting up my build. Somehow I missed the warning about changing the perl file. I did not recognize it as something that applies to me -- after all whenever I ran the wp34s_asm.pl manually script it found wp34s_pp.pl with no problem.

Not having the executable flag set on those Perl scripts (re my BTW) could account for having to use "perl" in front. What is the state of the permission flags?

(I strongly suspect you already know this but just in case, run 'ls -rtl *.pl' and make sure that there is at least 1 "x" in the permission bits. If not run 'chmod +x *.pl' to make these executable.)

Wonderful you were able to get it running!

Cheers...

The execute flag is set on these scripts in subversion so they should be executable when downloaded.


- Pauli

Quote:
I probably should have mentioned that I start MinGW's bash-like console, cd to checked out wp34s directory and run the make there.
Is this the intended way? Or should I run make from window's cmd.exe?

I didn't install Mingw Perl and I'm not using its Bash command shell but cmd.exe instead. Try the Flash.cmd commandfile in the Root (above Trunk).

I used the ZIP bundle since I don't know how to access the subversion any more and the box I was using did not seem to have subversion on it anyway. The executable attributes were not set when the ZIP was expanded on a Linux box. I don't know a lot about how ZIP behaves with those attributes.

I haven't used MinGW and its bash-like shell so I can't say much more than that.

It also could be that the Windows system needs to have the "attrib" and "assoc" programs run to allow Windows to associate the Perl scripts as executables. As I mentioned in the Assembler doc:

Quote:
The Strawberry Perl installer does not setup the file associations for Perl scripts (as Active State
does). There are many good reference for “correcting” this oversight.

Hopefully that is all it is.