-
Notifications
You must be signed in to change notification settings - Fork 84
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Oasis (swc, vis, xz) not compiling under cproc (use of volatiles & flexible array members) #62
Comments
This is a tool used to generate sources, so is typically compiled for the system building oasis rather than the target system. I typically leave The problem is that the
The volatile error can be worked around by adding qbe doesn't yet support volatile loads and stores, but it is pretty safe to work around it this way since I don't think qbe will optimize out non-stack loads/stores (which is where volatile is typically used, and is indeed the case for the above uses).
The best way to test with cproc is to modify the
set('cc', tc.cc or (tc.platform and tc.platform..'-cc') or 'cc') So if you don't set |
Thanks! I now managed to get the cproc toolchain to compile itself, and (sort of) self-host. I haven't done anything further swc/velox/wayland yet. (At this stage I'm doing more testing of toolchain itself) I have also managed to get the musl-gcc wrapper to bootstrap the 1st cproc executable, so I avoided the need to build/use the musl cross compiler. A few of the patches I needed to make to get the cproc-based toolchain to compile were:
I replaced the above with a loop to initialise the -1 value across the 0...MAX_OPERANDS range instead of relying on the GNU extension. This is new to v2.39, it's not present in v2.38 and seems to be the only GNU C extension used in binutils. I don't know if it is worthwhile contacting the binutils (and gcc!) team to alert them to this? It seems to go against the rest of the binutils code base, which doesn't rely on GNU extensions (maybe it was something that slipped in accidentally?). In theory gcc -std=c17 should be reporting an error for this code, but when I use gcc -std=c17, the gcc compiler doesn't complain. This seems to be a bug in gcc, unless I have missed the introduction of array range initializers in the C standard spec? |
Hi, I'd like to help where I can with getting oasis to compile with cproc, as it preserves the traditions of "original" unix which otherwise have been lost in modern linux (excessive use of dynamic linking, excessive focus on optimising machine code to the zillionth degree, excessive use of c++, excessive use of binary distribution as source code for complex packages are no easily longer comprehensible).
I get the following cproc compiler errors for xz, vis & swc, which I understand are meant to compile with cproc:
pkg/swc/src/cursor/convert_font.c:109:15: struct member contains flexible array member
pkg/xz/src/src/xz/message.c:97:31: volatile store not yet supported
pkg/vis/src/vis.c:832:24: volatile store not yet supported
(There might be more errors but I stopped there).
My cproc version is 995d5b48b1, swc is 32905f16ca, xz is 5.2.5
Also, I don't fully understand the oasis build system yet (not sure where $cc is being set), so at the moment I am activating cproc by replacing the rules.ninja cc rule (line 7 in rules.ninja) to directly execute cproc. Is there a better way to configure the oasis build system to use cproc instead of gcc and do I need to make any changes to CFLAGS (at present set to -Os -pipe)?
The text was updated successfully, but these errors were encountered: