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 ...

It's strange that fbc is trying to use 32bit libgcc even though it compiles for 64bit. What do you get when running these commands: gcc -m32 -print-file-name=libgcc.a gcc -m64 -print-file-name=libgcc.a It should give different output, but if it's the same, then maybe some packages are missing: gcc-m...

Try adding the -v option to the fbc compile command, then it should show the target system it's trying to compile for (maybe it's 64bit x86_64 instead of 32bit i686?).

As counting_pine said, since the library has _PNG_LoadLibrary@8, not @16, it's probably BYVAL AS STRING from old FB versions where it was broken and worked like BYREF AS ZSTRING. The declaration can be changed to BYREF AS ZSTRING or BYVAL AS ZSTRING PTR now and then new FB versions can use the old l...