Checking whether llc --version works sounds interesting. Maybe it could even be used to decide which LLVM version to target, to adjust the code generation accordingly. If that doesn't work out for some reason, then yea, using clang only/always would certainly be easiest.

What is the correct way to translate a zero length array in a C struct to a FB type? You pass arrays of this type to certain functions, so they need to be the right size. True, it might be necessary to use only the header struct without a payload, so because of that it must have the same sizeof() a...

Last time I worked on this was, I think, around LLVM 3.2... the older release packages from llvm.org back then still included llc.exe. Nowadays it's not included for whatever reason, but it looks like you can get it from the llvm package in MSYS2 (might be using that because of MinGW-w64 anyways) or...

MrSwiss wrote:C:\DEV_TOOLS\FreeBASIC\source\FBFrog\src>c:\dev_tools\freebasic\1071_64\fbc *.bas -m FbFrog
It fails on: __FB_ARGC__

Maybe it works with -m fbfrog instead of -m FbFrog, unfortunately it seems that the -m option is case-sensitive (it needs to match the file name fbfrog.bas).

Yea pretty much that. Or maybe a test that checks whether a custom module-level constructor was invoked. (unless those are emitted in different sections than fb_hRtInit)

Maybe I can help out with this... fbc uses the same basic layout for structs and vtables as g++ (and msvc and COM), but some parts are skipped since FB doesn't support the full C++ features. Regarding fbc's vtable layout: https://github.com/freebasic/fbc/blob/1.06.0/src/compiler/symb-comp.bas#L150 F...

Wow, that's unfortunate... I wonder, does the fbc test suite already have a test case that would detect this?

If you would like to see the .asm file produced by fbc, there is an fbc command line option for that: -RR

for example: fbc -v -RR foo.bas
or: fbc -v -rr -m foo foo.bas

That should generate foo.asm next to foo.bas.

Yea go ahead, if I can help out a bit that's fine for me. I got no plans to make any big improvements though. For symbol naming conflicts usually the solution is to do something like declare function shell_ alias "shell" ... . There is an fbfrog option for that, -rename_ shell , or -rename...

Yea it allows # comments. The *.fbfrog files can also include others recursively, which can be useful to extract and reuse common parts.

No, it's unfinished, so not really useful. It's a mix of two ideas - 1) using libclang in fbfrog instead of a custom parser. Good, except it can't parse #define bodies, so it still needs some custom parsing for that. 2) making a "just-in-time bindgen" (for 1 target only instead of all targ...

Maybe we need to add "-target cygwin-x86_64" to the FBC variable above (in the fbc cross-compile step). Looking at the makefile, it doesn't add it automatically. With that you will probably also need FreeBASIC-win64/bin/cygwin-x86_64/{as,ar,ld,gcc}.exe and cc1.exe etc. plus the Cygwin libr...

Keep in mind that cygwin and mingw-w64 are different toolchains, and FB uses either win64 (mingw-w64, 64bit) or cygwin-x86_64 (cygwin, 64bit), which cannot be mixed. It has to be treated as if cross-compiling (even though it's both 64bit Windows). It should work something like this: 1. get win64 fbc...

Ok, interesting. Crashes are strange, that needs to be debugged. Some parts are understandable, such as ./configure build system invocation being different on the different target. It's really unfortunate that some packages generate some headers at build-time... this is not handled nicely at all cur...

Hi, the last time I worked on fbfrog+fbbindings, it was on Linux only, so maybe it is broken for Windows/Cygwin... but I'm sure that can be fixed. So if you've got useful changes, send a pull request, I can review + merge it. Also I'm not surprised if the download links used in the scripts are dead ...