c3d / db48x

RPL runtime for the DM42 calculator, in the spirit of HP48/49/50
http://48calc.org
GNU Lesser General Public License v3.0
63 stars 9 forks source link

Compiling on Linux #999

Closed JohnRobson closed 1 week ago

JohnRobson commented 1 week ago

I appreciate any support. I'm trying to compile the simulator on Arch Linux.

I installed: arm-none-eabi-binutils arm-none-eabi-gcc arm-linux-gnueabihf-gcc arm-linux-gnueabi-gcc

I did: git clone --recursive git@github.com:c3d/db48x.git

But I'm getting this error: https://paste.debian.net/1321504

Thank you so much.

JohnRobson commented 1 week ago

I found that "those particular options are only available on the 32bit compiler, and this is the aarch64 gcc, so they do not apply. So if you are trying to port an "old" project to 64bit you'd want to remove them from your make environment."

so I replaced: #CPUFLAGS += -mthumb -march=armv7e-m -mfloat-abi=hard -mfpu=fpv4-sp-d16 to: CPUFLAGS += -march=armv7e-m

but still with several errors, like: /usr/bin/ld: cannot open linker script file src/dm42/stm32_program.ld: No such file or directory

But the file is there: $ ls -lha src/dm42/stm32_program.ld -rw-r--r-- 1 4.8K Jun 25 15:24 src/dm42/stm32_program.ld

I think the author should compile it on Linux at least one time and fix these issues, I'm interested in building the simulator to run on Linux and share it.

prismv commented 1 week ago

With a fresh checkout I can confirm that simply make sim does not work (anymore). There are several files in .gitignore that were once compiled successfully, but make clean does not delete them to get a completely virgin compilation:

If I start with fresh clone (here using depth to get only a shallow copy) without full git credentials there might be also problems with submodule pulling (so simple https access does not work for all submodules ...).

ssh-agent bash -c 'ssh-add ~/.ssh/whatever_id; git clone --recursive --depth 1 git@github.com:c3d/db48x.git'
cd db48x
for d in {recorder,tools/ttf2font,tools/decimize}; do pushd $d && make && popd; done

Now make sim should work, but there seems to be no proper rule to generate sim/gcc111libbid.a. @c3d I have a several months old version of this file in my older clone, but I don't know anymore how to generate this. @JohnRobson Sorry, at this point I have to give up due to other tasks.

dm42/stm32... files belong to the build of the firmware for the DM42 calculator. If I am not mistaken this should not belong to simulator code.

JohnRobson commented 1 week ago

Thank you so much @prismv .

Yes, still with errors: https://paste.debian.net/1321598/

recorder.c:1997:20: error: conflicting types for ‘sigaction’; have ‘void(int, void (**)(int), void (**)(int))’

I hope @c3d helps to fix these compiling issues.

c3d commented 1 week ago

But I'm getting this error: https://paste.debian.net/1321504

Indeed, it looks like there is a problem rebuilding ttf2font.

For now, the workaround is to first build it explicitly:

cd tools/ttf2font
make
cd ../..
cd recorder
make clean
make
cd ..
make
make sim

That sequence worked for me. Of course, it should not be necessary, and I will fix it.

c3d commented 1 week ago

I found that "those particular options are only available on the 32bit compiler, and this is the aarch64 gcc, so they do not apply. So if you are trying to port an "old" project to 64bit you'd want to remove them from your make environment."

so I replaced: #CPUFLAGS += -mthumb -march=armv7e-m -mfloat-abi=hard -mfpu=fpv4-sp-d16 to: CPUFLAGS += -march=armv7e-m

No, this is wrong. The options in question are for the cross compiler, the arm-none-eabi-gcc that is used to build a 32-bit executable for the DM42 or DM32. So you should leave them as is.

The simulator uses other options, which are defined by the sim/db48x.pro file, and is built using whatever Qt picks up for your particular distro, either gcc or clang.

but still with several errors, like: /usr/bin/ld: cannot open linker script file src/dm42/stm32_program.ld: No such file or directory

If you see that, then you are not building the simulator, you are (incorrectly) building the binary for the DM42. That's the context where you need tht script.

But the file is there: $ ls -lha src/dm42/stm32_program.ld -rw-r--r-- 1 4.8K Jun 25 15:24 src/dm42/stm32_program.ld

I think the author should compile it on Linux at least one time and fix these issues, I'm interested in building the simulator to run on Linux and share it.

I think you presume incorrectly that the author does not build on Linux "at least one time" ;-) See for example https://github.com/c3d/db48x/issues/853.

The problem is that I do not build from scratch. I had to do a git clean -dfx to reproduce your problem in my build environment.

c3d commented 1 week ago

I confirmed that these build dependency problems also exist with a clean build on macOS. I'm investigating, since normally the dependencies are there in the makefile so that it should work, and I'm pretty sure it used to work.

c3d commented 1 week ago

This should be fixed on dev now. There was an easy problem and a subtle one.

The easy problem was that there was still a reference to the Intel decimal library in the db48x.pro file. Unless you start with a clean directory or git clean -dfx, that library file was never removed, notably by make clean, so I never noticed that I was depending on it.

The more subtle problem is a bad interaction between the environment variables that the outer Makefile sets and the expectations of the inner make-it-quick makefiles used for the tools. The invokation of the sub-makefiles with TARGET= on the command-line was supposed to workaround that, but the correct workaround is to pass TARGET=opt to force an optimized build of the tool. Otherwise, the rebuild of the tool would only happen if the tool source code changed, not if the target binary was missing.

(The underlying problem being that TARGET means two different things for the outer makefile and the inner make-it-quick based ones)

JohnRobson commented 1 week ago

Indeed, it looks like there is a problem rebuilding ttf2font.

For now, the workaround is to first build it explicitly:

cd tools/ttf2font
make
cd ../..
cd recorder
make clean
make
cd ..
make
make sim

Thanks, is improving, but still with error:

recorder.c:1997:20: error: conflicting types for ‘sigaction’; have ‘void(int, void (**)(int), void (**)(int))’

https://paste.debian.net/1321706/

JohnRobson commented 1 week ago

still not working:

recorder.c:1997:20: error: conflicting types for ‘sigaction’; have ‘void(int, void ()(int), void ()(int))’

g++: error: unrecognized command-line option ‘-mthumb’

g++: error: unrecognized command-line option ‘-mfloat-abi=hard’

g++: error: unrecognized command-line option ‘-mfpu=fpv4-sp-d16’

Would be nice to see a video of this compilation process for Linux.