Threaded Mode | Linear Mode

HP67 · (This post was last modified: 03-03-2014 01:10 PM by HP67.)

Today I tried getting the hptools built on a UNIX box. After making a few dumb source changes to avoid name conflicts that weren't present in the developer's system it built ok.

It seems to compile Sys RPL and assemble, but the linker is not resolving symbols. I grabbed a copy of entries.a from hpcalc.org somewhere and assembled it and put it in the search path. From the listing it seems to be located ok.

Before I go into too much detail I was wondering if anybody is using hptools 3.0.8 on Linux or UNIX and has any words of wisdom. C and UNIX are most definitely not my thing.

Dave Frederickson · 03-02-2014, 05:33 PM

Is this what you're looking for - hptools-3.0.8-linux-i586.tar.gz?

HP67 · (This post was last modified: 03-02-2014 05:47 PM by HP67.)

No, I have that but I was talking about building the source version on UNIX.

The Linux version has the executables already built but does not include entries.o. I ASSume that can be built from entries.a and I have done that already and it seems to be found ok in my UNIX test environment. That was progress, because at first the listing was a big blank but with the entries.o found things got better until the link step.

I am not trying to do this on Linux, although if I can't get the UNIX source built and the Linux version works here then I can live with the Linux version. However my first preference would be to use the source version because I have a bunch of UNIX boxes and would like to run it there.

My question is to anybody who tried to build and use the source version on UNIX, not Linux. And, if any Linux user of hptools remembers what they had to do to get it to work, that information would also be appreciated.

Raymond Del Tondo · 03-02-2014, 06:47 PM

You could also try the Win32 binaries with wine;-)

HP67 · 03-02-2014, 06:50 PM

(03-02-2014 06:47 PM)Raymond Del Tondo Wrote: You could also try the Win32 binaries with wine;-)

Wink noted!

Thomas Ritschel · (This post was last modified: 03-02-2014 08:17 PM by Thomas Ritschel.)

About two years ago I tried to compile the HPtools on a 64 bit Linux system. I can't remember all the details anymore, but I got a lot of compiler errors. Somehow I managed to get a working rplcomp and makerom, but for sasm I had to use a precompiled 32 bit binary found somewhere else.

Regarding your Linker problem I remember similar problems with ENTRIES.O due to the distinction between lower and upper case file names/extensions. The file generated by sasm from ENTRIES.A will get the name ENTRIES.o (note the lower case). For proper use with the other tools I had to rename it to the upper case extension.

HP67 · 03-03-2014, 06:51 AM

(03-02-2014 08:16 PM)Thomas Ritschel Wrote: About two years ago I tried to compile the HPtools on a 64 bit Linux system. I can't remember all the details anymore, but I got a lot of compiler errors. Somehow I managed to get a working rplcomp and makerom, but for sasm I had to use a precompiled 32 bit binary found somewhere else.

Regarding your Linker problem I remember similar problems with ENTRIES.O due to the distinction between lower and upper case file names/extensions. The file generated by sasm from ENTRIES.A will get the name ENTRIES.o (note the lower case). For proper use with the other tools I had to rename it to the upper case extension.

Thanks a lot for the comment on .o vs. .O

I don't know whether this is hardcoded in the linker or whether adjusting the .M file to point to .o (which is what I did earlier) should work. Anyway, I will try your suggestion asap and let you know. Thanks a lot for the comments.

HP67 · 03-03-2014, 12:39 PM

Thomas, that was it. Thank you for pointing out the problem with .o vs. .O.

As far as I can see, as long as the .M file specifies the correct case everything works. It doesn't appear after testing very briefly, that the extension must be upper case, only that the .M file must specify it exactly.

As far as your compilation errors go, I also had problems compiling. I guess some point after the code was written, the system header files changed and there were collisions between variable names used in the code and variables used in the header files. I'm no C programmer, and I don't want to be one, so I tried changing the clashing variables to some other name. Now my Linux executables work (because of your pointing out the problem with filenames) and my UNIX executables work after "fixing" the source.

I don't have a cable so I can't test this yet but the listings look good, much better than before.

Thanks!