arm-gen.c missing from libtcc
paulwratt opened this issue · comments
[ 98%] Building C object CMakeFiles/lobster.dir/external/libtcc/libtcc.c.o
In file included from /home/pi/build/lang/lobster/lobster/dev/external/libtcc/libtcc.c:21:
/home/pi/build/lang/lobster/lobster/dev/external/libtcc/tcc.h:324:11: fatal error: arm-gen.c: No such file or directory
# include "arm-gen.c"
hmm.. here it is from a slightly older version of the same fork you got yours from, and it says ARMv4 at the top
Since I saw cmake pick up the RPi stuff OK, I presumed Lobster had been tested on RPi (and Vivante?)
I have personally never tested it with RPi (don't have one), and not sure anyone else has.. it must simply work well with "generic" CMake.
I left out the arm file because the TCC mode is meant during development (on desktop platforms, which so far has meant x86), whereas mobile platforms (arm) should build with the C++ output mode (--cpp).
I'd recommend using that mode for RPi too, its faster, and it doesn't need libtcc at all. You'd compile your .lobster to .cpp with a desktop version of lobster (and --cpp), see also the docs, then build the RPi exe using -DLOBSTER_TOCPP=ON for CMake.
That said, if you want to try making the libtcc version work, you could try adding the arm files from the latest https://bellard.org/tcc/ to dev/external/libtcc and see if that builds.
Yeah, I am going through a diff of dev/externel/libtcc and tinycc (from https://github.com/TinyCC/tinycc) now. Did you modify anything in there specifically for Lobster?
If you didnt change anything specifically, then it looks like it will just drop in (after I figure out which files can be included), in which case Lobster will/should build for RISC-V and ARMv8/Aarch64 as well, as a side affect (Note that although arm-gen.c says ARMv4, it works with all ARM 16/32bit)
thanx for the --cpp and how to build it (CMake still confuses me alot)
That's not the official site, I got the files from https://bellard.org/tcc/
I did not make any changes to the files in dev/externel/libtcc
ok, thanx
(yeah its a mirror, I'll pick up the real deal later, as I found a couple of things that need fixing, and maybe 1 bug)
Apart from the refactored section bounds checking (for inline ASM) and bunch of stuff related to symbol tables, there does not seem much different, in which case I should be able to post a PR sometime soon (I'll test it first). It doesn't look like I have to change anything for CMake either (there is only one reference to libtcc)
EDIT: oh they added backtrace
I added (and updated) from tinycc/. I can get it to compile if I add -L/opt/vc/lib before -lbcm_host in the end of ./dev/CMakeFiles/lobster.dir/link.txt (althought it already contains the correct rpath flag)
NOTE: the included SDL2 builds fine without that hack AND it correctly detects RPI & GLES
Although it does not crash (segfault), I only get the following (with and without --cpp):
pi@raspberrypi:~/build/lang/lobster/lobster-new $ bin/lobster samples/pythtree.lobster
pythtree.lobster(27): error: arguments match no overloads of float
got: xy_i
overload: float(i:int)
overload: float(v:[int])
pi@raspberrypi:~/build/lang/lobster/lobster-new $ bin/lobster --cpp samples/pythtree.lobster
pythtree.lobster(27): error: arguments match no overloads of float
got: xy_i
overload: float(i:int)
overload: float(v:[int])
pi@raspberrypi:~/build/lang/lobster/lobster-new $ bin/lobster --cpp samples/guitest.lobster
gui.lobster(94): error: arguments match no overloads of float
got: xy_i
overload: float(i:int)
overload: float(v:[int])
in gui.lobster(177): position(v:xy_i, f:function130) { }, r:xy_i
in gl.lobster(16): function129() { size:xy_i, interact:bool, num_interactive_elements_hit:int, render_pass:bool, size_list:[elem], overalsize:xy_i, id:int, size_index:int, alignv:int}
in gui.lobster(185): gl_blend(mode:blend_mode, body:function129) { }, old:int
in guitest.lobster(66): gui_start(size:xy_i, alignh:int, alignv:int, interact:bool, f:gui_fun) { }, id:int
pi@raspberrypi:~/build/lang/lobster/lobster-new $ bin/lobster samples/guitest.lobster
gui.lobster(94): error: arguments match no overloads of float
got: xy_i
overload: float(i:int)
overload: float(v:[int])
in gui.lobster(177): position(v:xy_i, f:function130) { }, r:xy_i
in gl.lobster(16): function129() { size:xy_i, interact:bool, num_interactive_elements_hit:int, render_pass:bool, size_list:[elem], overalsize:xy_i, id:int, size_index:int, alignv:int}
in gui.lobster(185): gl_blend(mode:blend_mode, body:function129) { }, old:int
in guitest.lobster(66): gui_start(size:xy_i, alignh:int, alignv:int, interact:bool, f:gui_fun) { }, id:int
pi@raspberrypi:~/build/lang/lobster/lobster-new $
EDIT: yes it does segfault with: bin/lobster tests/parsertest.lobster. actually everything in tests/ segfaults (import testing?) where as the ones in samples/ just fail on any line the includes xy.
EDIT: bin/lobster samples/wavtest.lobster almost works (a window frame flashes on screen), but fails:
bin/lobster samples/wavtest.lobster
Unable to create OpenGL context: Could not create GL context: GLXBadFBConfig
fatal error: Unable to create OpenGL context: Could not create GL context: GLXBadFBConfig
VM error: graphics system not initialized yet, call gl_window() first
in function: __top_level_expression
msg = "Unable to create OpenGL context: Could not create "..
so maybe SDL2 didnt compile properly - none of the SDL_* driver or renderer settings work, although they seem to be processed
pi@raspberrypi:~/build/lang/lobster/lobster-new $ SDL_VIDEODRIVER=RPI bin/lobster samples/wavtest.lobster
Unable to create window: Invalid window
fatal error: Unable to create window: Invalid window
VM error: graphics system not initialized yet, call gl_window() first
in function: __top_level_expression
msg = "Unable to create window: Invalid window"
It appears that Lobster would work on ARM Linux with just some configuration massage (and maybe testing on 32bit Linux first). Things maybe different under 64bit ARM Linux.
However, CMake does not like me, so I dont really know what else to do, as trying to get cmake to work properly is a no-go for me without hacking (as opposed to setting options and overides in a regular Makefile)
Which version of Lobster is this? you should be on latest master.
For me, error: arguments match no overloads of float is not happening on any platforms, so either that would indicate an older version, or some severe miscompile somehow.
That -L/opt/vc/lib seems very RPi specific.. we can't add it to that file though, since it is generated. We'd need to find out what to add to CMake to make these things compile for RPi.
Can you get me a stacktrace what it segfaults on?
Unable to create OpenGL context doesn't surprise me, as it has never done OpenGL on this platform.
First thing to do would be to add whatever preprocessor symbol indicates we're compiling for RPi to these lines:
lobster/dev/src/lobster/platform.h
Lines 104 to 107 in 6182eea
That will make it target OpenGL ES 3. Without that, it probably thinks its "generic linux" and target OpenGL 3.2.
If such a define doesn't exist, you'll need to add your own, by adding something like -D__RASBERRYPI___ or whatever to CMake.
Or for now you can use the existing __arm__ though that will eventually not be correct anymore when we get arm macs.
There may be other things in platform.h/.cpp we want to do differently for RPi, but most should be fine as is.
The Unable to create window: Invalid window may go away once you fix the platform stuff above.
I am using the repo master branch. If I wasn't using an RPi4 I would say "GLES3 hmm.. cant do that", but according to Vulkan development RPi4 is already doing 3.1 (3.2 to come), so a fix in src/lobster/platform.h will probably help.
I'll see what I can do about the stacktrace. I am woundering if it is a 64bit assumption thing (because the OS is 32bit). At some point I have to run up an x86 version of RaspberryPi OS for another piece of code I am working on, and as far as I know that is also 32bit, so I can include Lobster build tests when I do that. I'd also like to try this on aarch64 but I dont have an OS installed atm (Ubuntu 2010 is now available for RPi).
I have seen some other projects have there own blah.cmake files that often need to be patched to "not forget/skip the RPi stuff" (like the one in the SDL2 external directory does, it knows about RPi), but it could also be that the version of CMake in Buster is just not upto par for the RPi4 (hardware is only 6 months old).
thanks for suggestions BTW. I just finished reading your page on memory management, so I'd like to be able to play with Lobster natively.
Lobster should still build for 32-bit platforms, as we have CI to build for wasm32 for example. But yes, everything else is 64-bit.
64-bit RPi is apparently happening, cool :) https://www.raspberrypi.org/forums/viewtopic.php?t=275370
I don't have a RPi myself, otherwise I'd look into it.
If you'd just like to play with Lobster, then of course doing it on a desktop OS first may be quicker.
Personally I think every developer should have one on the desktop, especially since now you can OTG them (0/3A+/4) with one USB cable (no need for mouse, keyboard, screen or power cables) ie. 1 cable - I like them cos they work well off car battery
Can you point me to how that would work?
How would you work on this machine? I can imagine SSHing into it, but that would not be sufficient for testing things like the OpenGL code mentioned above.
use vnc or ssh -X pi@raspberrypi.local
RaspberryPi OS comes with VNC, and Avahi mDNS/Bonjour service pre-installed. OSX has Bonjour via iTunes. And on Windows you can get the Apple’s Bonjour Printer Service helper app - for details read this (and the headless ref. below - Quicktime?).
you can drop an empty ssh file on the root of the sd-card to get SSH to start on boot (headless), read docs here (incl. VNC link), and then run raspi-config if you want to make it permanent (SSH already has X11Forwarding=yes set).
Edit: I think it works like that (out of the box) for RPi Zero (uUSB), RPI 3A+ (uUSB), and RPi 4 (USB-C), I know it does with the 4, but you might have to set OTG mode for the others (or do it headless too) - alternately get a RPi 400 "Kit" + HDMI screen (the "kit" has everything else, incl. sd-card, cables, mouse, built-in keyboard - no need for a heat sink/fan then), which you can also connect OTG.
( here you can find the fastest sd-card available on RPi )
Ok, that sounds like a minimal enough investment that I could get a RPi 4 to try this out. I have a mac laptop with usb-c which sounds like it should work out of the box, but would be nice if it worked with my desktop.. but that only has USB-A (3.0).. are there any cables that work for that scenario (OTG/power over single cable) ? Googling didn't make that clear to me.
By now, Lobster JITs fine on ARM on the Mac, whatever issue is happening above may already be fixed, but would need to be tested by someone with a RPi, I don't have the bandwidth to do such testing myself. Please open another issue if you have specific things we can fix.