Where can I get a Recent-Git-Build of FreeBASIC?

[coderJeff]

@St_W, there's a few new build updates merged in with fbc/master now. I also changed the opening post for this thread so you can edit if you want.

[srvaldez]

@St_W, thank you for the arm64 version
I just installed Ubuntu 64-bit on the PI 4 and installed FB and built the latest from the Git repo without any problems :-)

[MrSwiss]

Build system seems to be broken. Last builds (except FreeBSD32) are from: 2020-11-01.
Not certain about the doc build: 2020-11-02 (last).

[fxm]

I was going to make the same point regarding Jeff's latest successive updates.
I will see tomorrow if it is the same for the documentation.

[edit]
This morning:
The same frozen state for the documentation (freebasic_manual.chm).

[St_W]

Thanks for the hints. Build currently fails with the following error:

Code: Select all

LINK bin/fbc
mkdir -p lib/freebasic/linux-x86
cp lib/fbextra.x lib/freebasic/linux-x86/fbextra.x
CC lib/freebasic/linux-x86/fbrt0.o
In file included from src/rtlib/static/../fb.h:322:0,
                 from src/rtlib/static/fbrt0.c:7:
src/rtlib/static/../fb_math.h: In function ‘hRnd_FillFAST32’:
src/rtlib/static/../fb_math.h:43:2: error: ‘for’ loop initial declarations are only allowed in C99 or C11 mode
  for( uint32_t i = 1; i < length32; i++ ) {
  ^
compilation terminated due to -Wfatal-errors.
makefile:600: recipe for target 'lib/freebasic/linux-x86/fbrt0.o' failed
make: *** [lib/freebasic/linux-x86/fbrt0.o] Error 1

Looks like a newer C compiler version is required? Maybe coderJeff can give some insights? Last working build is from end of october.
Same issue for Windows/Linux/DOS builds.

Documentation build is a different issue. Updated some Jenkins plugin a while ago which seems to have caused a dependency conflict. Unfortunately cannot fix that right now cause currently no Jenkins downloads are available as they are having some server issues:

Disk quota failures on Azure file storage have broken the Jenkins download mirror system. The storage timeout and mounting issues on Microsoft Azure from yesterday have been resolved but the quota failures keep the download mirror system offline. Downloads of Jenkins core and Jenkins plugins are failing with a 503 error. The Jenkins infrastructure team is working with Azure support to resolve the issue.

[coderJeff]

Sorry about that.

Sometime in last months Travis-CI changed the default build environment
- previously Ubuntu 14.04 Trusty which uses gcc 4.8.4.
- currently Ubuntu 16.04 Xenial which uses gcc 5.4.0

I have only been testing on Ubuntu 16.04 x86_64 lately.

An easy fix though and should have it pushed soon.

EDIT: fix pushed to fbc/master now.

[St_W]

Thanks a lot coderJeff for the fix. All platform builds succeed now again.
I saw that it was some convenience feature, declaring a loop variable within the for loop, which makes the code a bit shorter and easier to read. At some point in time we definitely should get rid of supporting older compilers. It's up to you to define that day, I'll update the build systems then :-)
Currently my builds use GCC 4.x (Linux builds on Debian Jessie 8 use GCC 4.9 for example), which is pretty old already. Debian 9 uses GCC 6.3, Debian 10 uses GCC 8.3. Not sure which GCC versions are available from DJGPP (DOS builds), but according to wikipedia more recent GCC versions should be available as well.

Regarding documentation builds: upgraded Jenkins to the latest version and fixed the plugin issues. Builds should be working again (already triggered one build manually)

[fxm]

The build for the documentation (.chm) seems frozen again.

[St_W]

You're right :-(
Cannot reach the build server, I guess the internet connection is broken again.

[coderJeff]

At some point in time we definitely should get rid of supporting older compilers. It's up to you to define that day, I'll update the build systems then :-)

Indeed. A couple of weeks ago I built a full release version for the Raspberry PI.
- RPI 3 (32-bit) Raspbian 9 - w/ gcc 6.3
- RPI 4 (64-bit) Ubuntu 20.10 - w/ gcc 10.2
I think the 64-bit version had one test-suite failure so I didn't publish packages yet.
I am hoping to do a full fbc-1.07.2 version soon, which can then be used for 1.08.0 release.

[fxm]

Will all present changes of the current version 1.08 be included in future version 1.07.2?
In the documentation, should we refer to 1.07.2 as delimiter rather than 1.08?

[coderJeff]

Will all present changes of the current version 1.08 be included in future version 1.07.2?
In the documentation, should we refer to 1.07.2 as delimiter rather than 1.08?

1.07.2 is a small set of changes cherry picked from 1.08, in a separate branch of the project. The intent of 1.07.2 release is that it is fully compatible with 1.07.1 and is only meant to fix a few bugs or release / packaging issues. Documentation for 1.07.2 will be same as 1.07.1. There may be some minor mismatches in documentation, however, the number of changes for 1.07.2 is relatively small.

1.08 should be the delimiter (where / if needed) in documentation as we are changing both binary and source compatibility in several instances.

Version 1.07.2

[changed]
- warning level for all warnings is increased by 1. Default warning level is 1. Previously, default warning level was 0 and some warnings had level of -1.
- reverted changes due sf.net #832: Fix bug allowing QB style suffixes on all keywords, regardless of -lang
- suffixes in '-lang fb' reverted to fbc-1.05.0 behaviours
- rtlib: internal fb_MemCopyClear() argument types changed to expect unsigned lengths (UINTEGER => size_t)
- github #256: gfxlib2: enable frame buffer on linux-arm targets
- gfxlib2: X11 driver - set the window title for both the frame window and the client window

[added]
- gas64 emitter for x86_64 (SARG), added '-gen gas64' command line option to select
- github #256: gfxlib2: add vga16_blitter for linux-arm targets to pack 2 pixels per byte and write to linear frame buffer
- makefile: add arm and aarch64 targets to the bootstrap package
- release: add arm and aarch64 targets as an option to the contrib/release.build.sh script

[fixed]
- sf.net #921: gfxlib: horizontal line drawing on 8-bit image was using wrong bpp
- github #258: on windows directx and gdi drivers, only show window after intialization is complete (adeyblue)
- sf.net #925: CSIGN/CUNSG preserve size when converting pointers on 64-bit and implict conversion of STEP value in FOR...NEXT statement
- github #122: gfxlib2: linux GFX_NO_FRAME + GFX_OPENGL freezing at exit due to a dead lock between exit routines
- use the multi-byte & wide character functions wctombs() & mbtowcs() when converting between string and wstring (Skyfish)
- fbc: read objinfo for elf format files on arm32 and arm64 (aarch64) to allow automatic options and linking of libraries
- fbc: name mangling for cva_list name mangling with arm32 and arm64 (aarch64) targets

I don't think there is any easy way to branch the documentation as I have not been making regular wiki snapshots past several months. 1.07.2 should be the last 1.07 release and we can move on to 1.08 where the documentation and fbc are both most up to date versions and in sync.

[fxm]

Currently, the documentation is up to date (unless omitting), referring to the last build of St_W (2020-12-06).

[edit]
I have a habit of updating the documentation if possible on a daily basis when I could test the changes a bit from a build by St_W.
I'm referring to a version delimiter (like the 1.08 today), not for new keywords (because the change is obvious) but only for those that already exist but whose behavior has just changed.
After the official release of the 1.08, I will remove all these delimiters (1.08) by showing only the new behaviors of the 1.08.

[St_W]

The build for the documentation (.chm) seems frozen again.

Builds (including documentation builds) are working again since about a week now.

[UEZ]

@St_W: any chance to release an updated pcre version? I can find only v8.39...

Thx.