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

Looks like SourceForge bugs can have "labels", which could be used for this. Then it would also make sense to enable the "labels" column in the list view. Also new fields can be added (currently we have the "Component" one).

It sounds like: https://sourceforge.net/p/fbc/bugs/798/

Nah, that's dead since fbfrog 1.0. It was fun to make, but there was just no point in having it...

We should merge the changes anyways, because what else can you do when Travis randomly starts failing. I mean, it would most likely fail to build the current master too, with or without the changes. For fbc, I don't think Travis builds passing or reviews on every change can be made mandatory, due to...

Looks like "refreshing the repository" (sf.net/p/fbc - Code - Admin - Code - Refresh Repository) fixed it.