Building FreeBASIC 1.06 Release

[coderJeff]

I've starting working on 1.06 release packages. I am using similar versions of tool chains as fb 1.05 to give a base line and compare differences. Pretty much if you take 1.05 binary release + St_W daily build binaries, you would have close to the next 1.06 release, though St_W is using newer versions of tool chains, I think.

I am using ./contrib/release/build.sh as my starting point just to see what I can build with the hardware I have readily available.

TARGETS (I can build releases on/for these targets):
[x] linux-x86 (TinyCore9, i686, binutils 2.29.1, gcc 7.2.0)
[x] linux-x86 (ubuntu 14.04, i686, binutils 2.24, gcc 4.8.4)
[x] linux-x86 (slackware 14.2, i686, gcc 5.3.0)
[x] linux-x86_64 (ubuntu 14.04, x86_64, binutils 2.24, gcc 4.8.4)
[x] linux-x86_64 (slackware 14.2, x86_64, gcc 5.3.0)
[x] win32-mingworg (mingw, MINGW32_NT-6.1, mingw, binutils 2.25.1, gcc 4.8.1)
[x] win32-mingworg (winxp, mingw, i686, binutils 2.25.1, gcc 4.8.1)
[x] win32 (mingw-w64, MSYS_NT-6.1-WOW, i686, binutils 2.25.1, gcc 5.2.0)
[x] win64 (mingw-w64, MSYS_NT-6.1, x86_64, binutils 2.25.1, gcc 5.2.0)
[x] dos (winxp, djgpp, binutils 2.29, gcc 7.1.0)
[ ] dos (msdosdjgpp, i586, mingw-w64-x86_64-cross-djgpp, bnu 2.31.1, gcc 5.5.0 ) WIP

I haven't started testing the packages yet, but at least I can make some of them. For testing, need to use the binary package to build the source package, to run the test-suite, proving that the released package can build itself.

MAYBE TARGETS (looks like St_W has made a bootstrap):
[ ] freebsd-x86 (freebsd 12.0, i386, binutils 2.27, gcc, 5.3.3) WIP
[ ] freebsd-x86_64 (freebsd 12.0, amd64, binutils 2.27, gcc, 5.3.3)

OTHER TARGETS (no bootstrap, and/or have not been able to configure build environment):
[ ] cygwin (no)
[ ] xbox (no)
[ ] netbsd-x86 (netbsd 8.0, i386, binutils 2.27, gcc, 5.5.0)
[ ] netbsd-x86_64 (netbsd 8.0, amd64, binutils 2.27, gcc, 5.5.0)
[ ] openbsd-x86 (openbsd 6.4, i386, binutils 2.17, gcc 4.2.1)
[ ] openbsd-x86_64 (openbsd 6.4, amd64, binutils 2.17, gcc 4.2.1)
[ ] darwin (can't do, no hardware)

ARCHITECTURES:
[ ] i386/i486 (probably not)
[x] i586 (dos only)
[x] i686 (yes, see targets above)
[x] x86_64/amd64 (yes, see targets above)
[ ] armv6 (can't do, no hardware)
[ ] armv7a (can't do, no hardware)
[ ] arm (can't do, no hardware)
[ ] aarch64 (can't do, no hardware)

I probably won't work on anything I can't actually test myself. Maybe if I get other hardware in future. I see St_W has some ARM builds available.

BACKENDS:
[x] gas x86
[x] gcc x86, various targets/arch
[x] gcc x86_64, various targets/arch
[ ] llvm, various targets/arch

I haven't had any success with LLVM. I don't know where to start. I have tried many versions on many platforms. Need help.

There is also the fbc/emscripten branch which I rebase on to master from time to time. https://github.com/jayrm/fbc/tree/emscripten I have never used it. Anyone working with this?

WINDOWS (x86, x86_64):
My primary build environment is win7sp1-64bit, with:
- mingw-org (WoW-32 bit host, 32 bit target)
- mingw-w64/mingw32 (64 bit host, 32 bit target)
- mingw-w64/mingw64 (64 bit host, 64 bit target)

I made a few changes to fbc's makefile & build.sh to recognize some of the combinations of host/target with mingw*. In the past I tried out TDM and win-builds, but mingw is giving best success.

LINUX (x86, x86_64):
Slackware, Ubuntu, Tinycore9 ... easy. Pretty much just ./contrib/release/build.sh and it works magic to build a release. I use VMWARE to create virtual machines for each distro installed from .iso boot disks.

I use a LAN connected NAS to hold a copy of the development repo. By pushing commits to my LAN git repo, I can share revisions in each virtual machine without having to go through github. It's faster to clone the full fbc repo from LAN also.

DOS (i586, or i786?):
Building for DOS for me right now is painful and slow, slow, slow.

I do not have a real 32-bit windows. I have a Win98 virtual machine that can build fbc from sources. It is painful, though I think it's about the oldest dos/win thing that can build fbc, having long file name support and networking. But I can't connect Win98 directly to my NAS, and there is no git. So I have to share a drive on the VM and manipulate the git repo from the HOST. It's stupid.

I also have a WinXPsp1 virtual machine from about 2007 that I imaged from a real laptop. It has a really old version of mingw-org (cvs/svn & gcc 3.x era). So to set-up a MinGW/DJGPP development environment, I would be starting from scratch. It has better networking support though, so I can connect directly to NAS repo. A recent version of git is still a problem though.

Ideally, I would just have a cross compiler on Mingw-w64/64bit. After having tried to build my own mingw-cross-djgpp tool chain, I am currently trying out:
https://github.com/jwt27/build-gcc
https://github.com/andrewwutw/build-djgpp

So, the DOS port is very slow going, having spent many many days (or weeks? over last year) on it, without success so far.

FreeBSD, NetBSD, OpenBSD (i386, amd64):
I don't know if I used any *BSD before. They remind me of computer lab at school.

FreeBSD 12.0 was easy to install, connect to my NAS, and install git using pkg tool. Have not tried it yet, but looks like St_W has made a bootstrap binary version for FreeBSD. It would be nice if we could create a bootstrap-from-source download and add a ./contrib/release/build-FreeBSD.sh script.

NetBSD 8.0 was OK to install, and connect to my NAS. Installing git not going so well.

OpenBSD 6.4 was OK to install. Did not get much further. I couldn't figure out how to install mount_smbfs (to connect to NAS) or git.

CURRENT STATE OF fbc/master
When the bugfix/feature branches get merged in to fbc/master, they have already been tested quite a bit, with code review from other developers. Most merge commits in the fbc/master revision history could be a stable (enough) release.

The varargs feature is still only a pull request, so it would be possible to leave until after the next release. It has some fairly aggressive internal changes, so might do that.

HELP WANTED
For reference, I will point back to an old post Working towards FreeBASIC 1.06 release.

So, I think for "official" releases, I can do the main ones, but we need to look at another way to share some of the other builds fbc users are creating and using. Like patches or pull requests for code updates or build scripts back to fbc/master.

NEXT
I started a release branch on my own fork at https://github.com/jayrm/fbc/tree/1.06.0

The short term goal is to get a release packaged and announced. I have some ideas what should come next, but for now, I am concentrating on the release.

[St_W]

For OpenBSD there is an inofficial FreeBasic package. Maybe the package maintainer could be notified when the release is finished. Should be only a matter of changing the download URL in the ports file to the latest FB sources ZIP file.
http://openports.se/lang/freebasic

For FreeBSD maybe my old notes can help:
viewtopic.php?f=17&t=19095&p=199906#p199906
viewtopic.php?f=17&t=19095&p=199908#p199908
The 32-bit build is a bit broken, though, AFAIR (I think I had to create a symlink for the correct dynamic loader). 64-bit build should be fine.
When you use the bootstrapped fbc something like that should work (haven't modified the script since the 0.91 days):

Code: Select all

#!/bin/tcsh -xe
gmake clean MULTILIB=64 || true
gmake rtlib gfxlib2 MULTILIB=64 CC=gcc47
gmake compiler MULTILIB=64 CC=gcc47 FBC='GCC=gcc47 ~/fbc/bin/fbc64 -i inc'

# rebuild fbc with previous fbc build
mv bin/fbc bin/fbc_new
gmake clean-compiler MULTILIB=64
gmake compiler MULTILIB=64 CC=gcc47 FBC='GCC=gcc47 bin/fbc_new -i inc'

I use a XP VM for the DOS build. Haven't invested that much time as it's not a very relevant target IMHO. But I'd also favor a cross build env, so please let us know about you're findings if you get it to work.

Many of my nightly builds currently use very old toolchains that I never updated since originally setting it up. I'll update them to match the versions/builds you're using for the next official release.

Having official ARM builds would be nice. I've a RPi 3 to test ARMv6/ARMv7a.

[marcov]

Note that Ubuntu 14.04 goes out of support in April 2019.

[Haubitze]

for the RPiv3 i wish ARMv8 support where nice. but ARMv7 are good for now to test it on a ARM SoC.

[coderJeff]

Note that Ubuntu 14.04 goes out of support in April 2019.

I used Ubuntu 14.04 as a starting point because it is currently default build environment for Travis-CI. It makes sense to me that I test locally on same version that we test publicly. Travis-CI also has Ubuntu 16.04 Xenial build environment (using gcc 5.4.0) so should expect we would be moving to that next.

Thanks, marcov, this helps me decide some things:
- next release will be based on the older tools
- fbc 1.07, tool updates, some bindings (header) updates
- fbc 1.08, more bindings (header) updates

[St_W]

for the RPiv3 i wish ARMv8 support where nice. but ARMv7 are good for now to test it on a ARM SoC.

Unfortunately software support for ARMv8 on RPI is quite bad, for example there's no ARMv8 version of Raspbian, the official distro for the RPI. I once built a aarch64 (=armv8) but never could test it as I did not have a aarch64 operating system for the RPI. Which OS (or Linux distribution) are you using?
Btw 64-bit ARM only make limited sense on the RPI as it has only 1GB of memory, so ARMv7 should be fine for the general audience.

Ubuntu 14.04 is probably a good choice as the binary will be compatible with future versions of Ubuntu (future versions of libc). If one would use a newer version it probably would require a new version of libc and thus wouldn't work on older Linux versions anymore.

[coderJeff]

St_W, thanks for the info. And also thank you for creating the on going compiler builds.

Yeah, I don't have much interest in the DOS port. A few times I thought of just giving up on it. For now, I will give it my best effort to make it work for this next release. After that, I don't know, I may leave it to others to maintain.

For 1.06 release, I am going to use the tool versions posted in the opening post. Unless someone gives a reason to use some other version, or I find a reason I must use some other version, that's my starting point.

I am thinking of doing another release soon after 1.06 just for tool updates. That may be the time you will want to update your nightly build system.

[Haubitze]

@ST_W yeah you are absolutly right with the argument of using ARM v7 on the RPi, i also use the official Raspian that is only 32 bit.
but here i found a experimental OS based on Debian. i dont have test it so far but eventualy you will take a look at it.
https://github.com/bamarni/pi64

my RPi currently in my garden used as a lightweight wetterstation so i cant test it today with this OS.

Salute

[coderJeff]

my RPi currently in my garden used as a lightweight wetterstation so i cant test it today with this OS.

LOL, ... wetterstation = weather station. At first I thought you meant "to water", as in bewässern. Because in english, "wetter" means to have more water.

In 1998, i wrote a QB program, running on a 386 laptop, to control a parallel port, to control solid-state relay to operate a solenoid, to turn on a garden water sprinkler, to water my garden. Including the laptop, needed 3 power sources to operate. Over engineering FTW. Not used in 20 years, I still have the hardware and software, here's the hardware (minus laptop):



Maybe in 2019 I can recreate using RPi and fbc port, 64-bit of course. :)

[Provoni]

Amazing work coderJeff and other people involved. Thank you very much for keeping FreeBASIC going.

[St_W]

I saw that meanwhile also more common distros like Fedora offer aarch64 builds for the RPI. I'll try one of these when I have some time. My RPi has only KODI (media center application) installed is just lying around most of the time.

[coderJeff]

BUILDING FOR DOS VERSION
If any other interested person wants to join in on this ... :)

I use a XP VM for the DOS build. Haven't invested that much time as it's not a very relevant target IMHO. But I'd also favor a cross build env, so please let us know about you're findings if you get it to work.

I hear ya. Well, I wasn't able to get mingw-w64-x-msdosdjgpp to work.

I was able to get some success with a mingw-org ming32 cross i586-pc-msdosdjgpp build of binutils 2.27 and gcc 7.1.0 using sources from gnu.org.

1) mingw.org installed at c:\mingw (binutils 2.23.2 & gcc 4.8.1)
2) msys installed at c:\mingw\msys\1.0
3) djgpp installed at d:\dj

4) Build a ming32 cross i586-pc-msdosdjgpp tool chain and install it to --prefix=/djgpp (c:\mingw\msys\1.0\djgpp)

Code: Select all

# binutils
tar -xzf binutils-2.27.tar.gz
mkdir -p bu-dos
cd bu-dos
../binutils-2.27/configure CFLAGS=-O2 \
	--prefix=/djgpp --build=mingw32 --host=mingw32 --target=i586-pc-msdosdjgpp \
	--disable-nls --disable-shared
make
make install
cd ..

# gcc
tar -xzf gcc-7.1.0.tar.gz
cd gcc-7.1.0
./contrib/download_prerequisites
cd ..

mkdir -p gcc-dos
cd gcc-dos
../gcc-7.1.0/configure CFLAGS=-O2 \
	--prefix=/djgpp --build=mingw32 --host=mingw32 --target=i586-pc-msdosdjgpp \
	--disable-nls --with-gnu-as --with-gnu-ld --disable-libstdcxx-pch \
	--disable-libstdcxx-debug --disable-multilib --disable-sjlj-exceptions \
	--enable-languages=c,c++
make all-gcc
make install-gcc
make all-target-libgcc
make install-target-libgcc
cd ..

Have some warnings, but otherwise finishes.

5) I am using a modified ./fbc/makefile that uses "./src/compiler/obj/$TARGET" for object files. And writes the EXE name as "fbc-$TARGET.exe". That's so I can have 32bit/64bit windows and 32bit-DOS in the same build tree.

6) I am working with STANDALONE builds only, so I think at this point I copied the cross binaries in to ./bin/dos

7) make a new fbc-dos.exe using newly installed mingw cross djgpp tool chain.

Code: Select all

	make TARGET=dos TARGET_OS=dos TARGET_ARCH=x86 ENABLE_STANDALONE=1 \
	CC=c:/mingw/msys/1.0/djgpp/bin/i586-pc-msdosdjgpp-gcc.exe \
	AR=c:/mingw/msys/1.0/djgpp/bin/i586-pc-msdosdjgpp-ar.exe \
	AS=c:/mingw/msys/1.0/djgpp/bin/i586-pc-msdosdjgpp-as.exe \
	LD=c:/mingw/msys/1.0/djgpp/bin/i586-pc-msdosdjgpp-ld.exe \
	djgpplibc=d:/dj/lib/libc.a \
	'FBC=fbc-win32.exe'

Some glitches/warnings with pthreads/sockets headers.

8) can actually do a '$ make bindist' here to create a package, except the build tree is not clean (get lots of extra files) and the wrong binaries are sitting in ./bin/dos. Once that's corrected ... (currently manually)

9) The newly build fbc-dos package can be unzipped on Win98/DOSBOX and can build dos exe's

10) I ran the test-suite on Win98 VM. And assuming we have f:/fb.git, f:/dj, can run
make SHELL=f:/dj/bin/sh.exe FBC=f:/fb.git/fbc.exe DIRLIST=pretest TARGET=dos unit-tests

---
It makes a little easier. In fact, can just build DOS exes from windows, and not bother building on DOS all together.

Problems/todo
- need to fully script
- integrate in to ./contrib/release/build.sh or create a new ./contrib/release/build-dos.sh
- pthreads/sockets warnings (nothing seems correct, either trying to keep sockets or remove them)
- console examples generally work in Win98/DOSBOX, but GFX examples maybe crash depending on GFX mode. I don't know if that's just available drivers in VMware+Win98. VirtualBox seems a little better. Needs more testing
- did not take any steps for the dos DLL support (dxegen)
- build needed DJGPP tools from sources
- build DJGPP's libc from sources (regardless, we still do a binary patch of _main.o module)

Not impossible, it just seems endless. :|

So this is probably best I'll be able to do with this, I think, create a build, with repeatable results from (mostly) sources, and some currently available djgpp binaries. Not sure I can guarantee the quality running only on VM's.

[rexxitall]

Hi Coder Jeff

<emscripten is definitly cool for various reasons.
In my case i have a lot of VBA macros which i want to use inside the browser.
Same would be for peoples who have to transcode their old activex stuff too.
FB is very near to VB whatever. so this is definily more the just a toy.

There are also a lot of ACAD peoples. ACAD can also be driven with Javascript.
Also those guys can now port nearly painless their existing VBA code

So please do not drop it !

Warm regads and thanks for you work
Thomas

[coderJeff]

Hi, rexxitall. I have no specific plans to drop or support emscripten target. It exists only as a development branch and has not been merged in to the fbc/master version. The only thing I've done is, every once in a while I will rebase the emscripten changes on top of fbc/master and push it out to my own emscripten branch. Other than that, I've never done anything with it, only resolving conflicts so fbc itself will compile. It won't be added in 1.06, but it's not lost though. Have you tried it, or know anyone working with emscripten branch of fbc?

[coderJeff]

After a long fight with dos version, I think I might be getting somewhere. In the end, I decided to get a mingw/djgpp development environment set up on a winxp virtual machine. In the top post I added these targets to the list:

Added TARGETS:
[x] dos (winxp, djgpp, binutils 2.29, gcc 7.1.0)
[x] win32-mingworg (winxp, mingw, i686, binutils 2.25.1, gcc 4.8.1)

For each target listed with a [x]:
1) build the release using ./contrib/release/build.sh
2) test the binary package by building the source package
3) test the newly built compiler by running the test-suite