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

SDL backend!

Here's a fix that adds the missing initializer validation (disallow non-constant initializers): https://github.com/freebasic/fbc/pull/87 I think allowing initialization of a global ref from another ref by duplicating the other's initree is possible, and should be done in hCheckAndBuildByrefInitializ...

For this case: dim shared a as integer = 5 dim shared byref as integer b = a dim shared byref as integer c = b '' fbc crash print a, b, c src/compiler/ast-node-typeini.bas(550): assertion failed at HFLUSHEXPRSTATIC: (expr->class =AST_NODECLASS_CONST) the problem in fbc is that hCheckAndBuildByrefIni...

Hi, it should be noted that some of the .bi files from the 32bit install were excluded from the 64bit version, because they do not support 64bit yet. So it's not safe to use them on 64bit. As far as I remember not all .bi files in fbc repository itself were fixed up yet. The main problem usually is ...

It's nice to see this being used/noticed, because it was intended to work this way. Parallel installation of libraries for easy cross-compiling, and shared headers. Also a note that's interesting for fbc development: The commands "fbc32 -arch 64" and "fbc64", aswell as "fbc6...