[Feature Request] Official RaspberryPi Package

[carlsmith]

A lot of people are interested in running fantasy consoles on RPi, as an easy way of creating games that will run well on limited hardware. Something similar, based on C, could be popular.

[carlsmith]

Just realised TCC doesn't support ARM.

[anael-seghezzi]

Actually the current repo of TCC does support ARM partly, though I'm not sure of it's completion level. Code written for CToy should compile easily to RasperryPi with GCC but I don't have the hardware to test all this. Volunteer welcomed :)

[carlsmith]

Thanks for getting back to me. Good to know it's not a lost cause.

I'm happy to test anything and report back on the result. I have the 3B+ and the RPi Zero, so could test perf at both ends of the spectrum, assuming I can get CToy up and running. I would need a few pointers though.

To be honest, I'm a bit of a script wizard. I've been coding nearly ten years, but it's all very high level languages and full-stack Web stuff. I make the money, but feel like a bit of a fraud. I'm learning C now, but am still new to it all, so it may be more trouble than it's worth to guide me through this stuff. I'll obviously understand if you're too busy to hold my hand right now.

Assuming I go with the GCC option, should I try and edit CToy to use GCC instead of TCC and use CToy as normal, or should I compile main.c with GCC after each edit and run the binary manually? I'm happy either way (as long as the API and libraries work).

[carlsmith]

Sorry for the confusion. I just worked out that CToy already supports using other compilers; I just don't know how that works??

[anael-seghezzi]

Let's first try to compile tcc, download this fork of tcc on your rasbi :
https://github.com/anael-seghezzi/tcc-0.9.26

Follow the instructions, it should be something like :
mkdir _build
cd _build
../configure
make

Eventually what is needed for CToy is to get a build of "libtcc" as a dynamic library.
That may require some experience with linux build system.

[raysan5]

@carlsmith, just in case TCC doesn't work on Raspberry Pi and you still want to develop on that platform, you can take a look to raylib, it's similar to CToy in several aspects...

[carlsmith]

Thank guys. I'll spend some time trying to get CToy working, and see how that goes (keeping raylib in mind as a fallback).

[carlsmith]

I couldn't get TCC to build on my RPi, and didn't really understand the error messages, and gave up.

I can use CToy on my Mac for now, so I'm cool personally. I can try this again once I have a better idea of what I'm doing. It's a shame though; it'd be nice to see CToy on RPi at some point.

[carlsmith]

Looking through the log, it looks like the make install command requires root, but the docs didn't say anything about that. I'll try again tomorrow or something. A lot of things failed, but if I can at least get closer, I might be able to narrow the issue down to something specific.

[wedge1020]

I stumbled upon this thread, basically attempting to do the same thing: would like to run CToy on a raspberry pi.

Set about cloning the repository and building it per the instructions. Choked when it hit libtcc.so

A quick google search found me: https://github.com/Alex2804/libtcc-cmake (looks to be a fork of tcc 0.9.27)

Cloned and built that (default is to build a static libtcc.a, a cmake config option can change that to shared libtcc.so).

Copied that libtcc.so into 3rdparty/libtcc/linux, replacing the x86_64 instance of the library that was there, mimicked the architecture subdirectory and placed the static lib there.

CToy still fails, but on linking CToy_player:

/usr/bin/ld: CMakeFiles/CToy_player.dir/ctoy_tcc.c.o: in function `ctoy__tcc_symbols':
ctoy_tcc.c:(.text+0xe0ec): undefined reference to `tcc_run'
/usr/bin/ld: ctoy_tcc.c:(.text+0xe0f4): undefined reference to `tcc_relocate'
/usr/bin/ld: CMakeFiles/CToy_player.dir/ctoy_tcc.c.o: in function `ctoy__tcc_init':
ctoy_tcc.c:(.text+0xe448): undefined reference to `tcc_relocate'
collect2: error: ld returned 1 exit status
make[2]: *** [src/CMakeFiles/CToy_player.dir/build.make:124: src/CToy_player] Error 1
make[1]: *** [CMakeFiles/Makefile2:269: src/CMakeFiles/CToy_player.dir/all] Error 2
make: *** [Makefile:149: all] Error 2

I've dealt with linking libraries before, but I guess I need some better awareness of this project: I'm far less familiar with cmake and its inner-workings... in traditional builds I'd just find the particular gcc line in question, copy it, manually edit it to suit my needs, and accomplish said step, and resume the make.

But here in CToy I am struggling to locate the individual actions instantiated by the build system. I ran make --debug=v and got some more information, but still nothing concrete.

Basically: if I managed to build an architecture-specific libtcc.so that I desire to use in building CToy for said architecture (Raspberry Pi), how do I convince the existing CToy build system to see and use that?

[wedge1020]

An update: after diving through the labyrinth of CMake files, I finally located the link.txt file responsible for the above linking error:

/usr/bin/cc   -O3 -fPIC -DLINUX -fopenmp -O3 -DNDEBUG -rdynamic CMakeFiles/CToy_player.dir/__/3rdparty/glad/src/glad.c.o CMakeFiles/CToy_player.dir/ctoy_tcc.c.o -o CToy_player   -L/home/${USER}/Downloads/CToy/src/../3rdparty/libtcc/linux  -Wl,-rpath,"\$ORIGIN/" ../3rdparty/glfw/src/libglfw3.a ../3rdparty/tinycthread/libtinycthread.a -ltcc -lopenal -lpthread -lXxf86vm -lX11 -lXrandr -lXi -ldl -lm -lrt -lm -lX11 -ldl```

And I've been trying, unsuccessfully, to massage this into linking me a binary.

Definitely isn't seeing reference to what seem like some fundamental bootstrapping symbols in libtcc (tcc_run, tcc_relocate)... and I've confirmed it sees the libtcc.so that I placed there, but either has auto-discarded the library due to finding no symbol match, or my freshly compiled library simply lacks these symbols (thinking the latter, as I rearranged the compiler arguments to no avail).

Might be a config option on the libtcc repository I cloned, I'll dive back in there and investigate. It seems that if I had a compliant libtcc.so (all needed symbols), this should just breeze through needing no manual intervention.

[anael-seghezzi]

First you need to use this fork of tcc : https://github.com/anael-seghezzi/tcc-0.9.26
(I made some specific modifications for CToy)

You can build libtcc.so and libtcc1.a using make

mkdir _build
cd _build
../configure --disable_static
make

you should copy libtcc.so and libtcc1.a in a new folder, for example CToy\3rdparty\libtcc\rpi
and modify some lines in CToy\src\CMakeLists.txt, maybe something like

IF(UNIX AND NOT APPLE)
  IF(${CMAKE_SYSTEM_PROCESSOR} MATCHES "x86_64")
    INSTALL(FILES ../3rdparty/libtcc/linux/x86-64/libtcc1.a DESTINATION ${MTCL_INSTALL_DIR}/x86-64)
    INSTALL(FILES ../3rdparty/libtcc/linux/libtcc.so DESTINATION ${MTCL_INSTALL_DIR})
  ELSEIF(${CMAKE_SYSTEM_PROCESSOR} MATCHES "aarch64")
    INSTALL(FILES ../3rdparty/libtcc/rpi/aarch64/libtcc1.a DESTINATION ${MTCL_INSTALL_DIR}/aarch64)
    INSTALL(FILES ../3rdparty/libtcc/rpi/libtcc.so DESTINATION ${MTCL_INSTALL_DIR})
  ENDIF()
ENDIF(UNIX AND NOT APPLE)

[wedge1020]

First of all: thank you for your response. I know this thread, and the overall repository, haven’t been active in a while. I only stumbled upon CToy a couple months ago, and only got around to actually playing with it this week. I hope it can be made to work, and then can be made to work in the manner I am intending (one issue at a time, though).

Actually I think I first tried this one, as you had mentioned it earlier in the thread. Seems to get near the end, then:

tcc-0.9.26/_build$ gcc -shared -Wl,-soname,libtcc.so.1.0 -o libtcc.so.1.0 libtcc.o tccpp.o tccgen.o tccelf.o tccasm.o tccrun.o arm64-gen.o 
/usr/bin/ld: tccpp.o:tcc-0.9.26/_build/./../tcc.h:1165: multiple definition of `tcc_io'; libtcc.o:tcc-0.9.26/_build/./../tcc.h:1165: first defined here

With the exact same issue for what looks like each of the other .o files trying to be linked:

tccgen.o, tccelf.o, libtcc.o, tccasm.o, tccrun.o, arm64-gen.o

Which of course stops the build:

collect2: error: ld returned 1 exit status

I checked tcc.h and you’ve got the #ifndef guards in place.

Compiling with:

• gcc (Raspbian 10.2.1-6+rpi1) 10.2.1 20210110
• ld from GNU Binutils for Raspbian version 2.35.2

I want to say I experienced a somewhat issue with some code of mine where I was trying to build libraries at the end (static AND shared), and it was with some change introduced in gcc 10; versions prior didn’t have the issue.

If memory serves, I needed to use -fcommon, as that was apparently the old default with gcc, and the default had changed to -fno-common with gcc-10. Unfortunately, this only seemed to resolve my issue for the static library (I mean, they’re just ar archives), whereas I couldn’t figure out how to get gcc-10 to cooperate to build a shared object library.

I suppose I could try installing gcc-9 to see if that’ll work without complaint; sure would love to know what other detail I’m missing with gcc-10 though. Anyway… off to try it with gcc-9, I’ll report back when I have something to report.

[wedge1020]

gcc-9 (and gcc-8) also not faring well. I end up with different failures; in the case of gcc 8 and 9, mislocated header files, and ultimately missing header files. Chasing these down feels like the wrong approach.

QUESTION: do I need to be building both tcc and CToy WITH tcc?

Admittedly, the thought only just occurred to me.

I did try to build tcc with tcc (the raspiOS package tcc, which provides:

• tcc version 0.9.27 (ARM Hard Float Linux)

Build failures still occur, but after a static, then shared library were able to be built.

Attempted integration into CToy, but still failed on linking CToy_Player with similar missing symbols as above.

I likely am still trying to build CToy with gcc so at least for the moment I will explore convincing it to use tcc instead for that (might clear up all my issues).

[wedge1020]

okay; excellent thing about this endeavour is that I’m finally learning about cmake, which was once some monolithic thing I poked at from a distance. Admittedly, it is warming on me.

I managed to produce a libtcc1.a, libtcc.so.1.0, build WITH tcc.

I copied these files into CToy/3rdparty/, although modelling things after your x86_64 naming under linux (ie amd64/). Made backups of the libtcc.so library (x86_64 version).

I dug around the CMakefiles… actually I grepped through the ENTIRE source tree, found any and all references to x86_64, and replaced them with arm64 for the linux logic.

I then proceeded to do a fresh build of CToy with tcc. CToy_Player still fails to link.

The same two missing symbols:

• tcc_relocate
• tcc_run

Using strings, and also perusing with xxd, I can verify that YOUR provided libtcc.so DOES have these two symbols (looks like they’re packed up in the ELF header at the start).

Your x86_64/libtcc1.a does not have any mention. Guessing this is a shared object thing (makes sense, since static linking would likely take care of these issues).

The libtcc.so/libtcc.so.1 I built from your forked tcc repository also lacks these symbols.

I had a thought to actually try building CToy with the tcc binary also produced from your forked tcc, but trying to run that results in a segmentation fault (yes, I put libtcc.so.1 in the library path, and yes, it is finding it, because I was getting that missing library error previously).

I guess at this point I could confirm whether or not a fresh build of tcc on a linux/x86_64 machine yields a libtcc.so.1 that includes those symbols (initial suspicion: that it doesn’t).

I’ve never dived that deep into ELF headers, I’m assuming it is acting as a sort of table of contents, so they are merely representing an offset to some other code. Although I would guess rather specific code, so I wouldn’t expect it to be already existing, and I could just force in some symbols to point at.

I don’t feel that well versed in x86_64 assembly (nor arm64 assembly) to try and attempt crafting the necessary logic, editing/wrangling on the binary libtcc.so.1

Not sure if the build is shortly done after CToy_player; I’ve not yet tried to trick it into thinking success to see what is next, but I’d assume the exact same issue would be present for the main CToy binary I’d actually need.

I suppose I can try and sort through the tcc code in your fork to verify tcc_run and tcc_relocate are there, and see if I can figure out why those symbols aren’t showing up in the final library. Maybe that gets added in the step that fails?

[wedge1020]

x86_64 tests: I was able to build your tcc fork on a linux/x86_64 machine, although only with tcc. And yes, the produced libtcc.so.1 DOES indeed have those symbols.

I have seen them in the code as well, which leads me to wonder:

• is there some arch-specific condition or code locking this into x86_64?

I have been doing some scans through the code looking for any obvious signs, an #ifdef/#ifndef for x86_64 that involves tcc_run/tcc_relocate, but I’ve not yet found any likely candidates as yet.

Thinking it may be something as simple as this. Find it, write some conditional to include it in arm64 (or all) builds, and away we go.

Assuming said change isn’t based on any architecture-specific assembly.

[anael-seghezzi]

It's possible that if tcc_relocate and tcc_run are missing you are trying to cross-compile libtcc.
It may not be that, but you need to compile natively only so that TCC_IS_NATIVE is active.

Both libtcc and CToy are to be compiled with gcc (or clang), no need to compile with tcc itself

[wedge1020]

SUCCESS!

Although, not sure which variable did the trick (I’ll attempt a clean build of everything again later).

For now, the two seemingly significant things I did:

• I was further chasing down the source of continued build-process failures in tcc… although it had made the static, and shared, libraries (lacking tcc_run and tcc_relocate symbols), it was still trying to do more, perhaps create some documentation? I was missing makeinfo which I installed the texinfo package to fix.
• I manually added a #define for TCC_IS_NATIVE to the generated config.h file.

Next thing I knew, tcc was able to finish properly, a strings search of the shared object library revealed the symbols I was missing.

I replaced them in the CToy source tree, continued my build there, where it quickly linked CToy_player, built CToy, and some other things, before bombing on libcimgui.so, saying that -soname wasn’t a valid compiler option, then yelling about libcimgui.so not existing, because -soname was ignored.

I edited them out (as follows), and it then worked:

/usr/bin/c++ -fPIC   -O3 -fPIC -DLINUX -O3 -DNDEBUG -Wl,--as-needed,--allow-multiple-definition,--build-id -shared -o libcimgui.so CMakeFiles/cimgui.dir/src/cimgui/cimgui.cpp.o CMakeFiles/cimgui.dir/src/cimgui/imgui/imgui.cpp.o CMakeFiles/cimgui.dir/src/cimgui/imgui/imgui_draw.cpp.o CMakeFiles/cimgui.dir/src/cimgui/imgui/imgui_widgets.cpp.o

I now have a working raspberry pi build of CToy!

Thank you so much for your help.

I will attempt another fresh build from scratch, to verify my ability to build with known details and understanding and confirm.

[wedge1020]

Okay, I think I’ve gotten the bulk of build details successfully figured out and verified.

You were right:

• it apparently was trying to do a cross-compile; on the raspberry pi, while they are still largely rooted in 32-bit userspace, a transition is underway to 64-bit. The standard distribution has a 32-bit userspace but users can (as a /boot/config.txt option), elect to boot a 64-bit kernel on a 32-bit userspace. I was doing this. This was tricking tcc into thinking some sort of cross-compile was happening, as kernel was reporting architecture as aarch64 whereas userland was still very much armv7l.
• Using the TCC_IS_NATIVE define, in config.h, this satisfied some major build hurdles when compiling with tcc on the 64-bit kernel (not needed when booting off 32-bit kernel).
• Ultimately, building CToy with tcc on the pi is actually problematic: depending on the version, there’s no assembly in place for 32-bit ARM, so it fails. On a 64-bit kernel convinced to do a native compile, I can actually build the libraries, and can build the CToy binaries, but they always result in a segmentation fault. So, after trying quite a few things (including hunting down the very latest version of tcc, 0.9.28rc, I gave up and returned to using gcc-10.

I was right:

• as of gcc-10, the -fno-common option is enabled by default, this causes your tcc fork build to fail with tcc_io “multiple definition” errors.
• without changing the code, this can be fixed by instead specifying the -fcommon argument to gcc-10 when building the individual C files.

Here’s a good thread talking about the issue: freeglut/freeglut#86

Line 232 on the tcc base Makefile just needs -fcommon appended and this causes everything to work fine (and with a 32-bit kernel booted on the pi, no need to fuss with the TCC_IS_NATIVE define).

This may actually impact ANYONE trying to build CToy with gcc-10, as it isn’t an ARM thing but a gcc thing. Compiler versions prior to gcc-10 may still have the old behaviour enabled by default, in which case systems with those older compilers would be able to build tcc without issue.

Onwards into the CToy build:

• the -soname libcimgui.so issue mentioned in an earlier post still stands. That needs to be removed from the link.txt in ressources/CMakeFiles/cimgui.dir/ under the build directory.
• this is likely ALSO a “feature” of gcc-10, as it uses c++, which will more than likely come from the same installed compiler suite (gcc version 10, therefore g++ version 10).
• copying and setting up subdirectories in 3rdparty/libtcc/linux/ is actually trivial: cmake actually seems smart enough to detect the architecture and select the right one. I merely had to copy the files in place and it automatically went with the right one.
• on 32-bit kernels on the pi (modern ones, at least… 3+), architecture is: armv7l
• on 64-bit kernels on the pi, architecture is aarch64

I wrote myself a fetch and build script, so it performs all these workarounds, and gets everything built.

I’m now at the point of trying to run CToy, and it is acting much more like it is trying to run versus wanting to crash. Two issues (one easily solved, one I’m still exploring):

• libtcc.so.1.0 created during the tcc build needs to be installed into the system library path. I put mine in /usr/local/lib, made sure proper permissions were set, and refreshed the linker cache (ldconfig) as root. This may NOT have been needed if make install was run from the finished tcc build, but if that fork is only needed for the shared and static libraries, I don’t want to mess with the tcc I’ve got on the system, so I did not install it.
• CToy is having trouble finding src/main.c. I tried the obvious (running it from just outside of the directory to allow the relative path to light up and work), no dice.

Actually, I satisfied the src/main.c issue.. looks like I have to run it from within CToy/bin/, where I discovered another issue (probably stemming back to a manual CMake change you previously mentioned):

• on install, it copies the x86_64 libtcc stuff from 3rdparty/ but nothing else. So, I manually copied the needed files into place (arm/libtcc1.a for a 32-bit kernel).

Ran it and… “Hello, World!” printed to the console, then illegal instruction and back to prompt.

So close.

I’ve booted back up with my 64-bit kernel, and am going to try the build again (tcc support for arm64 in your 0.9.26 fork may be much better than that for arm32).

I’ll… report back again should this be successful or not.

[wedge1020]

Successful build, 32- and 64-bit ARM on raspberry pi, but no love on actually running it.

I get the same result, regardless of kernel:

CToy/bin/MTCL$ ./CToy
src/main.c:1: warning: Support for FPA is deprecated and will be removed in next release
src/main.c:1: warning: Support for OABI is deprecated and will be removed in next release
Hello World!
Illegal instruction

At this point this seems like a deeper code-related issue. There were certainly a number of warnings during build, including one file with what looked like an else missing braces but having misleading indentation. I may try as a next order of business on my end to clean up those warnings; who knows, evolution of compiler versions and changing behaviours could have made once-working code now compile into less working code.

Seems really close though. Be a shame not to get this going.

I may also try and look up what modifications you made in your tcc-0.9.26 fork, and port them over to that tinycc-0.9.28rc version that seems to be the latest and greatest (and what looks like better 32-bit ARM support).

Just to collect related/useful information in one place, this raspberry pi forums thread was quite helpful with respect to sussing out some of the tcc issues: https://forums.raspberrypi.com/viewtopic.php?t=329647&sid=deda8e9921aa490025e261eea716fd55&start=25

Anything else and I’d have to start knowing more specifics about how CToy is working.

Thanks for the feedback. Any other suggestions? As I said, I’d really love to see this going. I’d like to put it to use in the classroom. Be a great instant feedback sort of thing as students are learning and experimenting.

[anael-seghezzi]

Thanks a lot for the effort and the report. It's good progress !

For the crash, I'm thinking that the local paths are not set properly, so it could be that when hello_world.c is trying to load "data/hello_world.png" it breaks, although it should print the error "ERROR CTOY: unable to read image".
->to test this, open main.c and change the first line to run sample 6 (one that don't rely on external files).

The other possibility is that tcc on ARM is just not complete... The "Illegal instruction" error is worrying.
If you want to try the last version of tcc, you don't need my fork if you only compile "CToy_player" (CTOY_PLAYER define). It will miss some features but it's good enough for testing.

[anael-seghezzi]

I'm also not sure you should try to build aarch64 if your processor is 32 bit, regardless of the kernel.
Which raspberry pi are you running ?

[wedge1020]

Thank you again for the continued suggestions.

I will try sample demo 6 and report back.

If that fails, I will try the latest tcc, targeting just CToy_player.. certainly a good place to start.

My pi is the 4B model, 64-bit CPU, it is just that the stable raspiOS still uses a 32-bit user land (32-bit libc). I suspect the 64-bit kernel on 32-bit userland is somewhat similar to the old intel PAE extensions allowing greater memory addressing, during similar hardware/OS transitional phases in the past.

The full 64-bit kernel + userland distro is still in testing. I’d personally run it, but all my students are still running the 32-bit distro due to stability, so for now I’m definitely needing to compile it for 32-bit userland.

Typically this causes no problems: when running in 64/32, binaries compiled work with other 32-bit resources, although it thinks it is aarch64 enough to trick file and other tools into reporting that. Yet, if I build on a full 64/64 system, those binaries would be incompatible.

But, the issue could well be tcc versions from so long ago had very scant ARM support (looks like 0.9.26 came out well over 10 years ago). So, certainly worth giving a shot, if only to prove or disprove some variables.

As always, I will try and report back.

[wedge1020]

Further environment details: It seems tcc gets confused when I try to build while running my 64-bit kernel (which reports aarch64 architecture) atop the 32-bit userspace. So, I have reverted to the 32-bit (armv7l) kernel and will only attempt building it with this scenario.

Okay, a change: I seem to have gotten rid of the illegal instruction with the rebuild of tcc with the latest version (0.9.28rc).

Sample 1, sample 6, using CToy_player (the only one that would build), runs, but nothing is displayed.

Not even the “Hello, World!” to the console.

Although there’s a new issue I am having to troubleshoot- during runtime, it now pops up a message:

tcc: error: libtcc1.a not found

Which considering its likely importance, is needing to be addressed. Thing is: I’ve put it in place. Not getting any path information, so I don’t know where it is trying to source it from.

I compiled everything with debug support and have been following the execution in gdb, no clear indication of what spawns that error. Must be from some other thread than the one I am viewing.

But: CToy_player with tinycc 0.9.28rc on armv7l (32-bit kernel/32-bit userspace) is no longer giving the SIGILL/illegal instruction that it previously was with your forked tcc 0.9.26.

I seem to remember there being a kernel trace tool that reports system calls used (Dtrace or some such thing)… I might try and track that down and check to see where exactly CToy_player is expecting to open libtcc1.a from, which would at least allow this vein of experimentation to continue.

[wedge1020]

CToy_player SUCCESS!

Looks like strace can do the trick of tracing system calls. So I poured CToy_player into it, and it was looking (or I guess trying) all sorts of places, just never in where it was placed. I guess it was trying the system library path, as it was trying to look in /usr/local/lib during one of its many failing attempts.

Easy enough! Copied libtcc1.a there, ran CToy_player, and I have the graphical and wavy “Hello World” sample 1 demo playing without issue.

So, a successful build and execution of CToy_player on the raspberry pi (32-bit kernel/32-bit userland), with tcc 0.9.28rc.

In the attempt to build CToy, it fails due to a few undefined reference errors, which I suspect are related to your changes made in your forked tcc 0.2.26:

/usr/bin/ld: CMakeFiles/CToy.dir/ctoy_tcc.c.o: in function `ctoy__io_replace':
/home/${USER}/Downloads/CToy/src/ctoy_tcc.c:92: undefined reference to `tcc_set_io_open'
/usr/bin/ld: /home/${USER}/Downloads/CToy/src/ctoy_tcc.c:93: undefined reference to `tcc_set_io_read'
/usr/bin/ld: /home/${USER}/Downloads/CToy/src/ctoy_tcc.c:94: undefined reference to `tcc_set_io_lseek'
/usr/bin/ld: /home/${USER}/Downloads/CToy/src/ctoy_tcc.c:95: undefined reference to `tcc_set_io_close'
collect2: error: ld returned 1 exit status

Question: how involved were your changes to tcc? Were they additional functions that tapped into existing tcc functionality, or did you significantly change some tcc functionality?

I’ve started looking through your changes (simultaneously learning to use the git diff tool, so I may still be suffering from unnecessary information overload), but have yet to attempt porting any changes over.

Am I right in that you added TCCIO as the CToy-specific tweak for functionality? And most of your changes hinge of the utilization of that?

For example, this from tcc.h:

/* IO */
struct TCCIO
{
    int (*open)(const char *filename, int access, ...);
    size_t (*read)(int fh, void *dst, size_t max);
    off_t (*lseek)(int fh, off_t offset, int origin);
    int (*close)(int fh);
};

struct TCCIO tcc_io;

I’m assuming that CToy_player is lacking that auto-update functionality upon saving changes to the source file.

[anael-seghezzi]

Good ! The most important modification I made is a hack to detect file change (tcc_set_io_read, tcc_set_io_lseek, tcc_set_io_close) > not very complicated to replicate.

I also made some minor changes to tcc compilation to avoid calls to exit(0) when compilation fails, but it's not as essential.

[markusbkk]

First you need to use this fork of tcc : https://github.com/anael-seghezzi/tcc-0.9.26 (I made some specific modifications for CToy)

You can build libtcc.so and libtcc1.a using make

mkdir _build
cd _build
../configure --disable_static
make

you should copy libtcc.so and libtcc1.a in a new folder, for example CToy\3rdparty\libtcc\rpi and modify some lines in CToy\src\CMakeLists.txt, maybe something like

IF(UNIX AND NOT APPLE)
  IF(${CMAKE_SYSTEM_PROCESSOR} MATCHES "x86_64")
    INSTALL(FILES ../3rdparty/libtcc/linux/x86-64/libtcc1.a DESTINATION ${MTCL_INSTALL_DIR}/x86-64)
    INSTALL(FILES ../3rdparty/libtcc/linux/libtcc.so DESTINATION ${MTCL_INSTALL_DIR})
  ELSEIF(${CMAKE_SYSTEM_PROCESSOR} MATCHES "aarch64")
    INSTALL(FILES ../3rdparty/libtcc/rpi/aarch64/libtcc1.a DESTINATION ${MTCL_INSTALL_DIR}/aarch64)
    INSTALL(FILES ../3rdparty/libtcc/rpi/libtcc.so DESTINATION ${MTCL_INSTALL_DIR})
  ENDIF()
ENDIF(UNIX AND NOT APPLE)

Having issues getting this to compile on a Macbook Air M2.

No matter what compiler I pick, conftest.c fails to compile during the configure step and make itself errors out with ./../tccelf.c:606:46: error: expected expression before '>=' token 606 | blx_avail = (TCC_ARM_VERSION >= 5);

[wedge1020]

Having issues getting this to compile on a Macbook Air M2.

No matter what compiler I pick, conftest.c fails to compile during the configure step and make itself errors out with ./../tccelf.c:606:46: error: expected expression before '>=' token 606 | blx_avail = (TCC_ARM_VERSION >= 5);

My initial guess is that you are likely running into the same issues I was trying to get this built on the pi: ARM support for that modified fork of tcc is limited. ARM64 is certainly better than ARM, but whether it is up to snuff with x86_64 is the question.

In my view, after the many back and forths with Anael in this thread, what may be the ideal path forward is to take a more recent version of tcc and implement the TCC_IO struct and related support. I’ve since gotten busy so I haven’t been able to follow up on this (although it hasn’t fallen off my list as yet).

You should be able to get the CToy_player built and running, however.

I also have a MacBook air M2, and dusting off my notes and trying a build on my Mac shouldn’t take too long, and I should have some time today to attempt this (unless I get overrun with a surge of students having questions during finals week).

I will report back after I have poked at it.

[wedge1020]

Okay, just pulled up my notes and attempted a build on my Macbook air M2 (macOS 14.2, Xcode command line tools clang 1500.1.0.2.5)... and I encountered the same error you did.

blx_avail = (TCC_ARM_VERSION >= 5);

Looking in broader context, it looks like it is attempting to capture the boolean result of that comparison (ie "do we have a capable-enough ARM processor"). I short-circuited this by simply forcing it to true (I assume 1 is true):

blx_avail = 1; //(TCC_ARM_VERSION >= 5);

I went and looked further into this TCC_ARM_VERSION macro. Seems it another similarly old tcc codebase, it is being defined to 5, so my assumption we wanted that expression to result in true seems correct. Apparently a cleaner way would be to set it in config.h... and oh, I FOUND THE ACTUAL PROBLEM:

Looks like TCC_ARM_VERSION is already being defined in config.h, but it isn't being set to anything. This is why that error is taking place.

To fix it, edit config.h (in your build directory), locate the define for TCC_ARM_VERSION and make sure it is set to 5:

#define TCC_ARM_VERSION 5

It then built through to the final attempt to produce the library then failed, not liking a few of the options. I tried to salvage it in similar ways I was trying on the pi, and got it to produce a libtcc.so.1.0 with the following line:

gcc -shared -W -o libtcc.so.1.0 libtcc.o tccpp.o tccgen.o tccelf.o tccasm.o tccrun.o arm-gen.o

Then attempted to built CToy, and was pleasantly surprised at how far it got (similar to the pi, by default it choked due to lack of an ARM library being present... this is where I started manually copying files and editing configurations on the pi to get it to see the ARM version over the x86_64 version).