FreeBASIC is a completely free, open-source, multi-platform BASIC compiler, with syntax similar to MS-QuickBASIC, that adds new features such as pointers, object orientation, unsigned data types, inline assembly, and many others.
Home Page: https://www.freebasic.net
FreeBASIC - A multi-platform BASIC Compiler
Copyright (C) 2004-2024 The FreeBASIC development team.
Official site: https://freebasic.net/
Forum: https://freebasic.net/forum/
Online manual: https://freebasic.net/wiki/DocToc
fbc project page: https://sourceforge.net/projects/fbc/
GitHub mirror: https://github.com/freebasic/fbc
Discord: https://discord.gg/286rSdK
IRC channel: ##freebasic at https://webchat.freenode.net
Features: https://freebasic.net/wiki/CompilerFeatures
Requirements: https://freebasic.net/wiki/CompilerRequirements
FreeBASIC consists of fbc (the command line compiler), the runtime libraries
(libfb and libfbgfx), and FreeBASIC header files for third-party libraries.
In order to produce executables, fbc uses the GNU binutils (assembler,
linker). When compiling for architectures other than 32bit, fbc depends
on gcc to generate assembly.
Documentation of language features, compiler options and many other details
is available in the FB manual. For help & support, visit the FB forum!
o Installation & Usage
FreeBASIC gives you the FreeBASIC compiler program (fbc or fbc.exe),
plus the tools and libraries used by it. fbc is a command line program
that takes FreeBASIC source code files (*.bas) and compiles them into
executables. In the combined standalone packages for windows, the main
executable is named fbc32.exe (for 32-bit) and fbc64.exe (for 64-bit)
fbc is typically invoked by Integrated Development Environments (IDEs) or
text editors, from a terminal or command prompt, or through build-systems
such as makefiles. fbc itself is not a graphical code editor or IDE!
Win32 (similar for Win64):
Combined 32-bit and 64-bit standalone packages:
Download and extract latest:
- FreeBASIC-x.xx.x-winlibs-gcc-9.3.0.7z or
- FreeBASIC-x.xx.x-gcc-5.2.0.7z
- fbc32.exe and fbc64.exe are used instead of fbc.exe
Separate 32-bit and 64-bit standalone packages (based on winlibs-gcc-9.3.0):
Download and extract latest:
- FreeBASIC-x.xx.x-win32.zip or FreeBASIC-x.xx.x-win32.7z for 32-bit
- FreeBASIC-x.xx.x-win64.zip or FreeBASIC-x.xx.x-win64.7z for 64-bit
Now you can use fbc.exe from the installation directory to compile FB
programs (*.bas files) into executables (*.exe files). Open a command
prompt (cmd.exe) and run fbc.exe from there, for example:
1. In the opened command prompt, type in the following command and
press ENTER:
> fbc.exe examples\hello.bas
2. This should have created examples\hello.exe in the FreeBASIC
installation directory. You can run it by entering:
> examples\hello.exe
A FreeBASIC-x.xx.x-win32.exe installer is also available but should
only be installed on win32 platforms.
1. Click Start -> FreeBASIC -> Open console (installer only)
2. In the opened command prompt, type in the following command and
press ENTER:
> fbc.exe examples\hello.bas
3. This should have created examples\hello.exe in the FreeBASIC
installation directory. You can run it by entering:
> examples\hello.exe
Optionally, you can install a text editor or IDE which will invoke fbc.exe
for you, for example:
WinFBE https://github.com/PaulSquires/WinFBE/releases
VisualFBEditor https://github.com/XusinboyBekchanov/VisualFBEditor/releases
Or even though is older and unmaintained will work (with some effort):
FBIDE: https://fbide.freebasic.net/
Linux (if FreeBASIC is not available through your package manager):
Download and extract the latest FreeBASIC-x.xx.x-linux.tar.gz. Open a
terminal and cd into the extracted FreeBASIC-x.xx.x-linux directory, and
run "sudo ./install.sh -i" to copy the FB setup into /usr/local.
To compile FB programs, please install the following packages (names may
vary depending on your Linux distribution):
Debian/Ubuntu:
gcc libncurses5-dev libffi-dev libgl1-mesa-dev
libx11-dev libxext-dev libxrender-dev libxrandr-dev libxpm-dev
libtinfo5 libgpm-dev
Fedora:
gcc ncurses-devel ncurses-compat-libs libffi-devel mesa-libGL-devel
libX11-devel libXext-devel libXrender-devel libXrandr-devel
libXpm-devel
If you want to use the 32bit version of FB on a 64bit system, it is
necessary to have the gcc 32bit multilib support and 32bit versions
of the libraries installed.
Debian/Ubuntu:
gcc-multilib lib32ncurses5-dev libx11-dev:i386 libxext-dev:i386
libxrender-dev:i386 libxrandr-dev:i386 libxpm-dev:i386 libtinfo5:i386
Now you can use fbc to compile FB programs (*.bas files) into executables.
For example:
$ cd FreeBASIC-x.xx.x-linux/examples
$ fbc hello.bas
This should have created the hello program. You can run it by entering:
$ ./hello
Optionally, you can install a text editor or IDE which will invoke fbc for
your, for example:
Geany: https://geany.org (sudo apt-get install geany)
DOS:
Download and extract the latest FreeBASIC-x.xx.x-dos.zip.
Now you can use fbc.exe from the installation directory to compile FB
programs (*.bas files) into executables (*.exe files). For example:
> fbc.exe examples\hello.bas
This should have created examples\hello.exe. You can run it by entering:
> examples\hello.exe
o Licensing
The FreeBASIC compiler (fbc) is licensed under the GNU GPLv2 or later.
The FreeBASIC runtime library (libfb and the thread-safe version, libfbmt)
and the FreeBASIC graphics library (libfbgfx and the thread-safe version,
libfbgfxmt) are licensed under the GNU LGPLv2 or later, with this exception
to allow linking to it statically:
As a special exception, the copyright holders of this library give
you permission to link this library with independent modules to
produce an executable, regardless of the license terms of these
independent modules, and to copy and distribute the resulting
executable under terms of your choice, provided that you also meet,
for each linked independent module, the terms and conditions of the
license of that module. An independent module is a module which is
not derived from or based on this library. If you modify this library,
you may extend this exception to your version of the library, but
you are not obligated to do so. If you do not wish to do so, delete
this exception statement from your version.
The FreeBASIC documentation is licensed under the GNU FDL.
Dependencies on third-party libraries:
The FreeBASIC runtime library uses LibFFI to implement the Threadcall
functionality. This means that, by default, FreeBASIC programs will be
linked against LibFFI when using Threadcall. LibFFI is released under
the MIT/Expat license, see doc/libffi-license.txt.
By default, FreeBASIC programs are linked against various system and/or
support libraries, depending on the platform. Those include the DJGPP
libraries used by FreeBASIC for DOS and the MinGW/GCC libraries used by
FreeBASIC for Windows.
o Included/used third-party tools and libraries:
- DJGPP http://www.delorie.com/
- GCC https://gcc.gnu.org/
- GNU binutils https://gnu.org/software/binutils/
- GNU debugger https://gnu.org/software/gdb/
- GoRC http://godevtool.com/
- LibFFI https://sourceware.org/libffi/
- MinGW https://osdn.net/projects/mingw/
- MinGW-w64 https://mingw-w64.org/
https://github.com/niXman/mingw-builds-binaries/
- OpenXDK https://openxdk.sourceforge.net/
- TDM-GCC https://jmeubank.github.io/tdm-gcc/
- WinLibs https://www.winlibs.com/
o Credits
Project members:
- Andre Victor T. Vicentini (av1ctor[at]yahoo.com.br)
Founder, main compiler developer, author of many parts of the runtime,
lead developer 2004 to 2010
FB headers (FBSWIG) & emscripten port
too many additions and improvements to list
- Angelo Mottola (a.mottola[at]libero.it)
Author of the FB graphics library, built-in threads, thread-safe
runtime, ports I/O, dynamic library loading, Linux port.
- Bryan Stoeberl (b_stoeberl[at]yahoo.com)
SSE/SSE2 floating point math, AST vectorization.
- Daniel C. Klauer (daniel.c.klauer[at]web.de)
lead developer 2010 to 2017
automatic header / bindings generation (fbfrog)
FB releases 0.21 to 1.05.0, C & LLVM backends, 64bit port,
dynamic arrays in UDTs, virtual methods, preprocessor-only mode,
many fixes and improvements.to compiler, rtlib & gfxlib2
too many additions and improvements to list
- Daniel R. Verkamp (i_am_drv[at]yahoo.com)
DOS, XBox, Darwin, *BSD ports, DLL and static library automation,
VB-compatible runtime functions, compiler optimizations,
miscellaneous fixes and improvements.
- Ebben Feagan (sir_mud[at]users.sourceforge.net)
FB headers, C emitter
- Jeff Marshall (coder[at]execulink.com)
FB releases 0.17 to 0.20, and later 1.06.0 and up
FB documentation (wiki maintenance, fbdocs offline-docs generator),
Gosub/Return, profiling support, dialect specifics, DOS serial driver,
miscellaneous fixes and improvements.to compiler, rtlib & gfxlib2
lead developer since 2017
- Mark Junker (mjscod[at]gmx.de)
Author of huge parts of the runtime (printing support, date/time
functions, SCR/LPTx/COM/console/keyboard I/O), Cygwin port,
first FB installer scripts.
- Matthew Fearnley (matthew.w.fearnley[at]gmail.com)
Print Using & Co, ImageInfo, and others, dialect specifics,
optimization improvements in the compiler, many fixes and improvements.
rtlib & gfxlib2 fixes and improvements
documentation and examples
forum administrator and moderator since forever
- Ruben Rodriguez (fbc[at]cha0s.io)
Var keyword, const specifier, placement new, operator overloading and
other OOP-related work, C BFD wrapper, many fixes and improvements.
- Simon Nash
AndAlso/OrElse operators, ellipsis for array initializers,
miscellaneous fixes and improvements.
Contributors:
- 1000101
gfxlib2 patches, e.g. image buffer alignment
- Abdullah Ali (voodooattack[at]hotmail.com)
Windows NT DDK headers & examples
- adeyblue
Direct2D windows driver
run time and gfx library improvements and fixes
- AGS
gdbm, zlib, Mini-XML, PCRE headers
- Angelo Rosina (angros47[at]gmail.com)
gfxlib2 extensions for OpenGL 2D rendering
integration of threading and dynamic libraries for DOS port (by monochromator)
integration of emscripten branch and improvements
- Claudio Tinivella (tinycla[at]yahoo.it)
Gtk tutorials
- Chris Davies (c.g.davies[at]gmail.com)
OpenAL headers & examples
- Dinosaur
CGUI headers
- D.J.Peters
ARM port, ODE headers & examples, Win32 API header fixes
- Dumbledore
wx-c headers & examples
- dr0p (dr0p[at]perfectbg.com)
PostgreSQL headers & examples
- Edmond Leung (leung.edmond[at]gmail.com)
SDL headers & examples
- Eric Lope (vic_viperph[at]yahoo.com)
OpenGL & GLU headers & examples, examples/gfx/rel-*.bas demos
- Florent Heyworth (florent.heyworth[at]swissonline.ch)
Win32 API sql/obdc headers
- fsw (fsw.fb[at]comcast.net)
Win32 API headers, Gtk/Glade/wx-c examples
- fxm
documentation writer and manager for many years
detailed technical articles, bug tracking and investigations
documentation forum moderator
- Garvan O'Keeffe (sisophon2001[at]yahoo.com)
FB ports of many NeHe OpenGL lessons, PDFlib examples
- Hans L. Nemeschkal (Hans.Leo.Nemeschkal[at]univie.ac.at)
DISLIN headers
- Jofers (spam[at]betterwebber.com)
ThreadCall keyword, libffi/libjit headers, FreeType examples
- Jose Manuel Postigo (postigo[at]uma.es)
Linux serial devices support
- Laanan Fisher (laananfisher[at]gmail.com)
FB test suite using CUnit
- Laurent Gras / SARG (debug[at]aliceadsl.fr)
gas64 backend emitter
improvements and fixes for stabs debugging
fbdebugger project https://users.freebasic-portal.de/sarg
- Luther Ramsey (luther.ramsey[at]gmail.com)
freebasic.net forums moderator
- Matthew Riley (pestery)
OpenGL, GLFW, glext, FreeGLUT, cryptlib headers
- Matthias Faust (matthias_faust[at]web.de)
SDL_ttf headers & examples
- Marzec
SDL headers, SDL_bassgl, SDL_opengl and SDL_key examples
First file routines for FB's rtlib
- MJK
big_int header fixes
- MOD
wx-c, BASS headers; -lang qb support for built-in macros,
"real" Rnd() algorithm
- Nek (dave[at]nodtveidt.net)
Win32 API headers
- Hung Nguyen Gia (gh_origin[at]zohomail.com)
Solaris and DragonFly porting and testing
- Paul Squires (support[at]planetsquires.com)
WinFBE IDE project and fbc compiler distribution bundle
- Plasma
FMOD and BASS headers & examples
- Ralph Versteegen
fixes / improvements to compiler, rtlib, gfxlib2, tests and headers
- Randy Keeling (randy[at]keeling.com)
GSL matrix example
- Saga Musix (Jojo)
BASS examples with sounds
- Sisophon2001
gfxlib2 fixes, Nehe OpenGL lesson ports
- Stefan Wurzinger (swurzinger[at]gmx.at)
compiler, runtime library and documentation generator improvements
daily development builds, documentation builds and testing
header/bindings updates
- Sterling Christensen (sterling[at]engineer.com)
Ex-project-member, author of FB's initial QB-like graphics library
- TJF (Thomas.Freiherr[at]gmx.net)
ARM port, GTK+, glib, Cairo, Pango headers & examples,
SQLiteExtensions headers
- zydon
Win32 API examples
Greetings:
- Plasma
Owner of the freebasic.net domain and main site hoster, many thanks to
him.
- VonGodric
Author of the first FreeBASIC IDE: FBIDE.
- Everybody that helped writing the documentation (and in special Nexinarus
who started it)
https://freebasic.net/wiki/ContributorList
- All users that reported bugs, requested features and as such helped
improving the compiler, language and run-time libraries.
The thread local data stored in rtlib can be left allocated in certain situations. That stored by Dir is the most easily noticable. Open Task Manager to the Details tab (Win10) or Processes tab (<=Win 7), turn on the Handles column, and run the code below. The count of handles will rise as the reported thread count does (well, as long as %ProgramFiles% has at least one directory in it).
It happens as Dir only closes the directory enumeration handle when everything has been enumerated. If you stop before the end, it is never closed. The same thing looks to happen with fds on Linux (I can't test on there, but the Linux Dir code is patterned the same way as the Windows one).
Memory can also leaked by the Input statement which stashes the typed input in a thread local structure (src/rtlib/con_input.c).
#include "crt/stdlib.bi"
#include "dir.bi"
Dim Shared g_threadCnt as Long = 0
Dim Shared g_countMutex as Any Ptr
Dim Shared g_stop As Long = 0
#ifdef __FB_WIN32__
#include "windows.bi"
Const ENV_VALUE As String = "ProgramFiles"
#else
Const ENV_VALUE As String = "HOME"
#endif
Private Function IncrementLong(ByRef count As Long) As Long
MutexLock(g_countMutex)
count += 1
Function = count
MutexUnlock(g_countMutex)
End Function
Private Sub ThreadProc(ByVal p As Any Ptr)
Dim threadId As Long = IncrementLong(g_threadCnt)
Dim pDirpath As String Ptr = p
Dim folder As String = Dir(*pDirPath, fbDirectory)
If Len(folder) = 0 Then
Print "Dir failed in thread id " & Str(threadId)
IncrementLong(g_stop)
End if
End Sub
#define THREADS_PER_LOOP 32
Private Sub Setup()
Dim zDirPath As ZString Ptr = getenv(ENV_VALUE)
If zDirPath = Null Then
Print "Couldn't find env var " & ENV_VALUE
Exit Sub
End If
Dim dirSpec As String = *zDirPath & "/*"
Dim threads(0 to (THREADS_PER_LOOP - 1)) As Any Ptr
Dim i As Long = 0
Dim created As Long = 0
Dim loopCount As Long = 0
Print "DirSpec = " & dirSpec
g_countMutex = MutexCreate()
Do
For i = 0 To (THREADS_PER_LOOP - 1)
threads(i) = ThreadCreate(@ThreadProc, @dirSpec)
If threads(i) = 0 Then
Print "Failed creating thread no " & Str((loopCount * THREADS_PER_LOOP) + i)
Exit For
End If
created = i
Next
For i = 0 To created
ThreadWait threads(i)
Next
If created <> (THREADS_PER_LOOP - 1) Then
Exit Do
End If
loopCount += 1
If (loopCount Mod 10) = 0 Then
Print "Threads done: " & Str(loopCount * THREADS_PER_LOOP)
#ifdef __FB_WIN32__
' Stop the thread stacks from ballooning memory usage
SetProcessWorkingSetSize(INVALID_HANDLE_VALUE, cast(SIZE_T, -1), cast(SIZE_T, -1))
#endif
End If
Loop While (Inkey = "") AndAlso (g_stop = 0)
MutexDestroy(g_countMutex)
End Sub
Setup()
The following build error occurs after executing make bootstrap-minimal in the FreeBASIC 1.07.0 bootstrap source release:
LINK bootstrap/fbc
/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: lib/freebasic/linux-x86_64/libfb.a(hinit.o): undefined reference to symbol 'tgoto'
/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /lib64/libtinfo.so.6: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
make: *** [makefile:1115: bootstrap/fbc] Error 1
However, this error is not related to the FreeBASIC 1.07.0 release: my ncurses library lacks the tgoto symbol.
On my system (Gentoo x86-64), the curses library (libncurses) sep is built from the low-level terminfo library (libtinfo). This effectively means that the tgoto symbol is provided by libtinfo instead of libncurses on my system.
Adding -ltinfo to line 1112 in the FreeBASIC makefile resolves the issue, but this may cause missing file errors for users who do not have libtinfo on their system. So this flag should instead be conditionally added in order to properly resolve this issue.
I'm trying to port FBC to FreeBSD on PowerPC64 using FreeBASIC-1.07.3-source-bootstrap from sourceforge and FreeBSD-x86_64.
I made what I believe are the necessary changes to the compiler source (.bas) files and created new bootstrap-dist for powerpc64. There are a couple of issues I haven't been able to resolve.
The first issue is when "fbc --version" is executed on the target system, the bootstrap compiler displays:
FreeBASIC Compiler - Version 1.07.3 (2021-02-16), built for freebsd-x86_64 (64bit)
Copyright (C) 2004-2019 The FreeBASIC development team.
This is not a major issue.
The major issue is when attempting to build the new fbc compiler, using the bootstrap, everything seems to go well until the linking. The following is displayed:
fbc -arch powerpc64 -e -m fbc -w pedantic -maxerr 1 -x bin/fbc-new src/compiler/obj/freebsd-powerpc64/ast-gosub.o src/compiler/obj/freebsd-powerpc64/ast-helper.o src/compiler/obj/freebsd-powerpc64/ast-misc.o src/compiler/obj/freebsd-powerpc64/ast-node-addr.o src/compiler/obj/freebsd-powerpc64/ast-node-arg.o src/compiler/obj/freebsd-powerpc64/ast-node-assign.o src/compiler/obj/freebsd-powerpc64/ast-node-bop.o src/compiler/obj/freebsd-powerpc64/ast-node-branch.o src/compiler/obj/freebsd-powerpc64/ast-node-call.o src/compiler/obj/freebsd-powerpc64/ast-node-check.o src/compiler/obj/freebsd-powerpc64/ast-node-const.o src/compiler/obj/freebsd-powerpc64/ast-node-conv.o src/compiler/obj/freebsd-powerpc64/ast-node-data.o src/compiler/obj/freebsd-powerpc64/ast-node-decl.o src/compiler/obj/freebsd-powerpc64/ast-node-idx.o src/compiler/obj/freebsd-powerpc64/ast-node-iif.o src/compiler/obj/freebsd-powerpc64/ast-node-macro.o src/compiler/obj/freebsd-powerpc64/ast-node-mem.o src/compiler/obj/freebsd-powerpc64/ast-node-misc.o src/compiler/obj/freebsd-powerpc64/ast-node-proc.o src/compiler/obj/freebsd-powerpc64/ast-node-ptr.o src/compiler/obj/freebsd-powerpc64/ast-node-scope.o src/compiler/obj/freebsd-powerpc64/ast-node-typeini.o src/compiler/obj/freebsd-powerpc64/ast-node-uop.o src/compiler/obj/freebsd-powerpc64/ast-node-var.o src/compiler/obj/freebsd-powerpc64/ast-optimize.o src/compiler/obj/freebsd-powerpc64/ast-vectorize.o src/compiler/obj/freebsd-powerpc64/ast.o src/compiler/obj/freebsd-powerpc64/dstr.o src/compiler/obj/freebsd-powerpc64/edbg_stab.o src/compiler/obj/freebsd-powerpc64/emit.o src/compiler/obj/freebsd-powerpc64/emit_SSE.o src/compiler/obj/freebsd-powerpc64/emit_x86.o src/compiler/obj/freebsd-powerpc64/error.o src/compiler/obj/freebsd-powerpc64/fb-main.o src/compiler/obj/freebsd-powerpc64/fb.o src/compiler/obj/freebsd-powerpc64/fbc.o src/compiler/obj/freebsd-powerpc64/flist.o src/compiler/obj/freebsd-powerpc64/hash.o src/compiler/obj/freebsd-powerpc64/hlp-str.o src/compiler/obj/freebsd-powerpc64/hlp.o src/compiler/obj/freebsd-powerpc64/ir-gas64.o src/compiler/obj/freebsd-powerpc64/ir-hlc.o src/compiler/obj/freebsd-powerpc64/ir-llvm.o src/compiler/obj/freebsd-powerpc64/ir-tac.o src/compiler/obj/freebsd-powerpc64/ir.o src/compiler/obj/freebsd-powerpc64/lex-utf.o src/compiler/obj/freebsd-powerpc64/lex.o src/compiler/obj/freebsd-powerpc64/list.o src/compiler/obj/freebsd-powerpc64/objinfo.o src/compiler/obj/freebsd-powerpc64/parser-assignment.o src/compiler/obj/freebsd-powerpc64/parser-comment.o src/compiler/obj/freebsd-powerpc64/parser-compound-do.o src/compiler/obj/freebsd-powerpc64/parser-compound-extern.o src/compiler/obj/freebsd-powerpc64/parser-compound-for.o src/compiler/obj/freebsd-powerpc64/parser-compound-if.o src/compiler/obj/freebsd-powerpc64/parser-compound-namespace.o src/compiler/obj/freebsd-powerpc64/parser-compound-scope.o src/compiler/obj/freebsd-powerpc64/parser-compound-select-const.o src/compiler/obj/freebsd-powerpc64/parser-compound-select.o src/compiler/obj/freebsd-powerpc64/parser-compound-while.o src/compiler/obj/freebsd-powerpc64/parser-compound-with.o src/compiler/obj/freebsd-powerpc64/parser-compound.o src/compiler/obj/freebsd-powerpc64/parser-decl-const.o src/compiler/obj/freebsd-powerpc64/parser-decl-def.o src/compiler/obj/freebsd-powerpc64/parser-decl-enum.o src/compiler/obj/freebsd-powerpc64/parser-decl-option.o src/compiler/obj/freebsd-powerpc64/parser-decl-proc-params.o src/compiler/obj/freebsd-powerpc64/parser-decl-proc.o src/compiler/obj/freebsd-powerpc64/parser-decl-struct.o src/compiler/obj/freebsd-powerpc64/parser-decl-symb-init.o src/compiler/obj/freebsd-powerpc64/parser-decl-symbtype.o src/compiler/obj/freebsd-powerpc64/parser-decl-typedef.o src/compiler/obj/freebsd-powerpc64/parser-decl-var.o src/compiler/obj/freebsd-powerpc64/parser-decl.o src/compiler/obj/freebsd-powerpc64/parser-expr-atom.o src/compiler/obj/freebsd-powerpc64/parser-expr-binary.o src/compiler/obj/freebsd-powerpc64/parser-expr-constant.o src/compiler/obj/freebsd-powerpc64/parser-expr-function.o src/compiler/obj/freebsd-powerpc64/parser-expr-unary.o src/compiler/obj/freebsd-powerpc64/parser-expr-variable.o src/compiler/obj/freebsd-powerpc64/parser-identifier.o src/compiler/obj/freebsd-powerpc64/parser-inlineasm.o src/compiler/obj/freebsd-powerpc64/parser-label.o src/compiler/obj/freebsd-powerpc64/parser-proc.o src/compiler/obj/freebsd-powerpc64/parser-proccall-args.o src/compiler/obj/freebsd-powerpc64/parser-proccall.o src/compiler/obj/freebsd-powerpc64/parser-quirk-array.o src/compiler/obj/freebsd-powerpc64/parser-quirk-casting.o src/compiler/obj/freebsd-powerpc64/parser-quirk-console.o src/compiler/obj/freebsd-powerpc64/parser-quirk-data.o src/compiler/obj/freebsd-powerpc64/parser-quirk-error.o src/compiler/obj/freebsd-powerpc64/parser-quirk-file.o src/compiler/obj/freebsd-powerpc64/parser-quirk-gfx.o src/compiler/obj/freebsd-powerpc64/parser-quirk-goto-return.o src/compiler/obj/freebsd-powerpc64/parser-quirk-iif.o src/compiler/obj/freebsd-powerpc64/parser-quirk-math.o src/compiler/obj/freebsd-powerpc64/parser-quirk-mem.o src/compiler/obj/freebsd-powerpc64/parser-quirk-on.o src/compiler/obj/freebsd-powerpc64/parser-quirk-peekpoke.o src/compiler/obj/freebsd-powerpc64/parser-quirk-string.o src/compiler/obj/freebsd-powerpc64/parser-quirk-thread.o src/compiler/obj/freebsd-powerpc64/parser-quirk-vafirst.o src/compiler/obj/freebsd-powerpc64/parser-quirk.o src/compiler/obj/freebsd-powerpc64/parser-statement.o src/compiler/obj/freebsd-powerpc64/parser-toplevel.o src/compiler/obj/freebsd-powerpc64/pool.o src/compiler/obj/freebsd-powerpc64/pp-cond.o src/compiler/obj/freebsd-powerpc64/pp-define.o src/compiler/obj/freebsd-powerpc64/pp-pragma.o src/compiler/obj/freebsd-powerpc64/pp.o src/compiler/obj/freebsd-powerpc64/reg.o src/compiler/obj/freebsd-powerpc64/rtl-array.o src/compiler/obj/freebsd-powerpc64/rtl-console.o src/compiler/obj/freebsd-powerpc64/rtl-data.o src/compiler/obj/freebsd-powerpc64/rtl-error.o src/compiler/obj/freebsd-powerpc64/rtl-file.o src/compiler/obj/freebsd-powerpc64/rtl-gfx.o src/compiler/obj/freebsd-powerpc64/rtl-gosub.o src/compiler/obj/freebsd-powerpc64/rtl-macro.o src/compiler/obj/freebsd-powerpc64/rtl-math.o src/compiler/obj/freebsd-powerpc64/rtl-mem.o src/compiler/obj/freebsd-powerpc64/rtl-oop.o src/compiler/obj/freebsd-powerpc64/rtl-print.o src/compiler/obj/freebsd-powerpc64/rtl-profile.o src/compiler/obj/freebsd-powerpc64/rtl-string.o src/compiler/obj/freebsd-powerpc64/rtl-system-thread.o src/compiler/obj/freebsd-powerpc64/rtl-system.o src/compiler/obj/freebsd-powerpc64/rtl.o src/compiler/obj/freebsd-powerpc64/stack.o src/compiler/obj/freebsd-powerpc64/symb-comp.o src/compiler/obj/freebsd-powerpc64/symb-const.o src/compiler/obj/freebsd-powerpc64/symb-data.o src/compiler/obj/freebsd-powerpc64/symb-define.o src/compiler/obj/freebsd-powerpc64/symb-enum.o src/compiler/obj/freebsd-powerpc64/symb-keyword.o src/compiler/obj/freebsd-powerpc64/symb-label.o src/compiler/obj/freebsd-powerpc64/symb-mangling.o src/compiler/obj/freebsd-powerpc64/symb-namespace.o src/compiler/obj/freebsd-powerpc64/symb-proc.o src/compiler/obj/freebsd-powerpc64/symb-scope.o src/compiler/obj/freebsd-powerpc64/symb-struct.o src/compiler/obj/freebsd-powerpc64/symb-typedef.o src/compiler/obj/freebsd-powerpc64/symb-var.o src/compiler/obj/freebsd-powerpc64/symb.o
error 23: File not found, crt1.o
error 133: Too many errors, exiting
/usr/local/bin/../bin/ld: warning: cannot find entry symbol _start; defaulting to 00000000102033c0
/usr/local/bin/../bin/ld: /lib/libc.so.7: undefined reference to __progname' /usr/local/bin/../bin/ld: /lib/libc.so.7: undefined reference to environ'
gmake: *** [makefile:582: bin/fbc] Error 1
I've looked at the code but cannot seem to find a solution. Can someone tell me what I've missed?
C:\FB\fbc -s console "zlib.bas"
C:\FB\bin\win32\ld.exe: skipping incompatible ./zlib1.dll when searching for -lzlib1
C:\FB\bin\win32\ld.exe: skipping incompatible ./zlib1.dll when searching for -lzlib1
C:\FB\bin\win32\ld.exe: cannot find -lzlib1
Hey all,
I'm trying to install the freebasic environment, but the official makefile ends up with errors -- it assumes I already have the fbc installed, which I think is bootstrapped
Also the official guide points to download from sourceforge, which I don't trust as it bundles spyware ..
I'd love to download and build from sources, no binaries at all.
The compiler accepts static libraries as input files (suffix '.a' on LINUX). But it doesn't allow dynamic libraries (suffix '.so' on LINUX), although the linker can handle them. fbc throughs the message "error 80: Invalid command-line option".
There's a simple workaround by just creating a proper symlink. But that complicates auto-build scripts for management systems like CMake. This looks unprofessional.
A solution is pretty simple: just allow dynamic libraries (files ending by .so) as input files and treat them like a static library.
Why is it important? -> When using fbc in a project that builds a shared library, the project may contain example code. In order to compile that code the project management system wants to link against the (uninstalled) fresh binary, but fbc currently doesn't allow that.
Regards
When invoking fbc with multiple -Wl flags, only the final -Wl flag is passed down to the linker.
To demonstrate the issue, I have run fbc in 4 different ways:
-Wl flags-Wl flag with two ld options (one defines symbol foo, other defines symbol bar)-Wl flags each with one ld option (foo symbol definition first)-Wl flags each with one ld option (bar symbol definition first)After each compilation I run nm on the resulting executable and grep for either of the foo or bar symbols:
$ fbc -g foobar.bas && nm foobar | grep "foo\|bar"
$ fbc -g -Wl --defsym=foo=0,--defsym=bar=0 foobar.bas && nm foobar | grep "foo\|bar"
0000000000000000 A bar
0000000000000000 A foo
$ fbc -g -Wl --defsym=foo=0 -Wl --defsym=bar=0 foobar.bas && nm foobar | grep "foo\|bar"
0000000000000000 A bar
$ fbc -g -Wl --defsym=bar=0 -Wl --defsym=foo=0 foobar.bas && nm foobar | grep "foo\|bar"
0000000000000000 A foo
As can be seen from the tests, only the last -Wl flag is sent down to the linker program. The expected behavior is to pass down all linker options specified by all -Wl flags, and not simply the final one; this would match the behavior described by ld documentation:
Note---if the linker is being invoked indirectly, via a compiler driver (e.g. gcc) then all the linker command line options should be prefixed by -Wl, (or whatever is appropriate for the particular compiler driver) like this:
gcc -Wl,--start-group foo.o bar.o -Wl,--end-group
This is important, because otherwise the compiler driver program may silently drop the linker options, resulting in a bad link.
gcc -o bootstrap/fbc lib/freebasic/linux-x86_64/fbrt0.o bootstrap/linux-x86_64/*.o lib/freebasic/linux-x86_64/libfb.a -lncurses -lm -pthread
gcc: error: bootstrap/linux-x86_64/*.o: No such file or directory
make: *** [makefile:1084: bootstrap/fbc] Error 1
eric@vanth:~/src/misc-sources/fbc(1)$ find . -iname linux-x86_64
./lib/freebasic/linux-x86_64
./src/gfxlib2/obj/linux-x86_64
./src/rtlib/obj/linux-x86_64
./tests/warnings/r/linux-x86_64
eric@vanth:~/src/misc-sources/fbc$ ls -l ./lib/freebasic/linux-x86_64/*.o
-rw-r--r-- 1 eric eric 1736 Sep 22 11:13 ./lib/freebasic/linux-x86_64/fbrt0.o
-rw-r--r-- 1 eric eric 1736 Sep 22 11:13 ./lib/freebasic/linux-x86_64/fbrt0pic.o
eric@vanth:~/src/misc-sources/fbc$
any pointer constants (those that are generated by the linker, fail to be recognized as constants if cast)
sub MySub()
print "Hello"
end sub
static shared as any ptr pSub = @MySub '<- works
static shared as any ptr pSub2 = cptr(any ptr,@MySub)
Dear specialists,
I Am visually impaired and because I have issues while designing forms by specifiing object position values, I would like to know, if I could simply use rapidq.inc file with Free Basic compiler. I do not know, but I think, that there are alligment constants and that I could use listboxes, nubuttons without number specifrication of width and hewight. Or those compilers Rapidq and Free Basic compiler are very different so I can not simply use my favourite Rapidq language and its .inc files with Free Basic compiler?
Nobody have created .inc file for Free Basic which would simply allow Me to use GUi based commands without adding object position values. I Am very sorry for this question, but I think, that you would inform
Hi FBC Team,
Where should I look to find information about the implementation of FBC Keywords? To be more specific: where can I find information about the C functions used to implement the FBC "open filename for Input" statement.
From looking at the runtime library, I see various functions that are related to the input statement like fb_InputByte and fb_InputInt. Are these used internally by another function?
Any information on this would be greatly appreciated!
Edit:
Also, perhaps I should specify why I am interested in this. As part of a research project, I am categorizing test case information for projects contained in a repository for Benchmarking Auto Program Repair systems. See my previous question for more details.
I am gathering test case information for fb_hStr2Double and a few other related functions and I believe the input statement eventually uses them for conversions from Strings to other data types (Double in the case of fb_hStr2Double). If my understanding of this is incorrect, please let me know.
FBC version 1.07.1.
Platform: linux amd64.
Distro: Linux Mint 18.3 Sylvia.
Compile this program:
open cons for input as #1
open cons for output as #2
dim shared lin as string
sub process()
print #2, chr(lin[0])
end sub
if not eof(1) then
line input #1, lin
end if
while not eof(1)
process()
line input #1, lin
wend
And try following:
$ ./test | ./test
$ cat >input
1234
^D
$ ./test <input
That isn't working.
Thanks. Downloaded from sourceforge and installed AArch64 binary using install.sh -i on Fedora 33. Calling fbc works, but executing Hello World results in
fbc: /lib64/libtinfo.so.6: no version information available (required by fbc)
hello.bas(1) error 146: Only valid in -lang deprecated or fblite or qb in '10 REM Hello World in BASIC'
hello.bas(2) error 146: Only valid in -lang deprecated or fblite or qb in '20 PRINT "Hello World!"'
The "Volatile" keyword indicates that the field can be changed in a way that is not controlled by the compiler, such as from another thread, signal, or interrupt. The compiler, runtime system, and even hardware can rearrange read and write operations to memory locations for performance reasons. Fields that are declared "Volatile" are not subject to this optimization.
"main@openindiana_1:~/fbc$ gmake
FBC src/compiler/obj/solaris-i86pc/ast-gosub.o
/bin/sh: line 1: fbc: not found
gmake: *** [makefile:527: src/compiler/obj/solaris-i86pc/ast-gosub.o] Error 127"
To do on Fedora 33, AArch64
sudo ./install.sh -i
I do not find in the git clone'd master that file.
Hello FBC devs,
I'm working on a research project that involves analyzing bugs and the specific input that generates them. I'm evaluating a previous version of FBC that is included in the ManyBugs repository (info for this can be found here, the specific version can be found in the scenario: fbc-bug-5251-5252). The bug in question has to do with the added functionality of octal support using '&'. There are two test files that I am particularly interested: tests/string/val.bas and tests/file/large_int.bas.
My question is this: In the large_int.bas test file, how can I determine which input causes one of the included assertions to fail?
When I run the executable created by compiling large_int.bas, it lists the assertions that fail like so,
1. file/large_int.bas:162 - CU_ASSERT_DOUBLE_EQUAL( check(i), n, check(i) \ 10000000 )
I would like to determine which specific input i, like "&2000000", leads to an assert failure. I have included sections of the code that may be pertinent to answering this.
This is the section of code that uses assertions:
#macro TYPE_TEST( t )
open "./file/large_int.csv" for input as #1
for i as integer = 0 to COUNT-1
dim n as t
input #1, n
#if t = single
CU_ASSERT_DOUBLE_EQUAL( check(i), n, check(i) \ 10000000 )
#elseif t = double
CU_ASSERT_DOUBLE_EQUAL( check(i), n, check(i) \ 1000000000000000ll )
#else
if( clngint( cast( t, check(i) ) ) = check(i) ) then
CU_ASSERT_EQUAL( check(i), clngint(n) )
end if
#endif
next i
close #1
#endmacro
This section uses the macro:
TYPE_TEST( byte )
TYPE_TEST( ubyte )
TYPE_TEST( short )
TYPE_TEST( ushort )
TYPE_TEST( integer )
TYPE_TEST( uinteger )
TYPE_TEST( long )
TYPE_TEST( ulong )
TYPE_TEST( longint )
TYPE_TEST( ulongint )
TYPE_TEST( single )
TYPE_TEST( double )
This section generates the input file that is being opened and tested:
sub generate_csv () constructor
dim n as longint
open "./file/large_int.csv" for output as #1
''decimal
n = 1
for i as integer = 1 to DEC_COUNT
write #1, n, -n, n * 10 - 1, 1 - n * 10
n *= 10
next i
write #1, n, -n
print #1, "9223372036854775807" '' 1ull shl 63 - 1
print #1, "-9223372036854775808" '' -1ll shl 63
''hex
n = 1
for i as integer = 1 to HEX_COUNT
print #1, "&h" & hex(n) & ", &h" & hex(n shl 3 - 1)
print #1, "&h" & hex(n shl 3) & ", &h" & hex(n shl 4 - 1)
n shl= 4
next i
''oct
n = 1
for i as integer = 1 to OCT_COUNT
print #1, "&o" & oct(n) & ", &o" & oct(n shl 3 - 1)
n shl= 3
next i
''bin
n = 1
for i as integer = 1 to BIN_COUNT
print #1, "&b" & bin(n) & ", &b" & bin(n shl 1 - 1)
n shl= 1
next i
''misc
print #1, "&b11, &B11, &o77, &O77, &77, &hff, &HFF" '' 3, 3, 63, 63, 63, 255, 255
print #1, "&hf, &hF, &Hf, &HF" '' 15, 15, 15, 15
print #1, "1.23d+2, 1.2D+1, 3.4e+1, 3.45E+2" '' 123, 12, 34, 345
print #1, " 1d1, 2D2, 3e3, 4E4" '' 10, 200, 3000, 40000
print #1, " 1.d1, 2.D2, 3.e3, 4.E4" '' 10, 200, 3000, 40000
print #1, " &h1d1, &h2D2, &h3e3, &h4E4" '' 465, 722, 995, 1252
print #1, "&h1.d1, &h2.D2, &h3.e3, &h4.E4" '' 1, 2, 3, 4
print #1, "&b12, &o78, &hfg, &HFG" '' 1, 7, 15, 15
close #1
end sub
Thanks for your time!
Just when I need them SF is down. Please, please, add binary releases on GitHub releases page.
I installed fbc 1.07.1 according to the directions on this site. (./install.sh -i). It apparently was successful but I am finding it doesn't work right. When compiling I get two errors:
fbc /lib64/libtinfo.so.5: no version information available (required by fbc)
This library is available, but is installed in /usr/lib64
fbc: Symbol 'ospeed' has different size in shared object, consider relinking.
VERSION: 1.07.1 DOS (32-bit)
ENVIRONMENT: DOSBox 0.74 (default DOS configuration)
Test program:
print "before sleep"
sleep 250
print "after sleep"
This issue is dependant on the CPU speed configured in DOSBox. When running at the default 3000 cycles the exception is thrown. When dropping the cycles to 300 the problem disappears. I cannot speculate why this happens, reporting it regardless for visibility's sake.
running at 3000 cycles
running at 300 cycles
Unnecessary multiple lookups:
I Am aware, that generating machine code instructions which produces reliable executable is The most complex task for every programmer. You have reached this goal by supporting X86 and X64 Bit INTEL compatible CPUS. Do you plan to add support for ARM cpus? I know, that generating Assembly instructions would be next complex task. So I Am only kindly asking you. If no, I will respect it, bešcause it is always much more better to support one CPU 100 % reliably than adding support for many CPUS but resulting machine code would produce chaos when run in target system.
Thank you very muct for yours answer.
fb_hPixelSetAlpha4 (gfxlib2/gfx_core.c) and fb_hPixelSetAlpha4MMX (gfxlib2/x86/gfx_mmx.s) give different results for the alpha portion of the output pixels. The MMX one being inconsistent among the same call. For instance:
Z:\src\gfxlib2\x86>test.exe 327 247 0xB279a52f
srcPixels are 0xb279a52f - dstPixels are 0xffed9564
C (f-0xb29ca03f, l-0xb29ca03f)
MMX (f-0x7b9ca03f, l-0xc99ca03f)
memcmp=1
With this code:
// gcc -m32 test.c -x assembler-with-cpp gfx_mmx.s -o test.exe
// test.exe 327 247 B279a52f
#include <stdlib.h>
#include <string.h>
#include <stdio.h>
#define MASK_RB_32 0x00FF00FF
#define MASK_G_32 0x0000FF00
#define MASK_GA_32 0xFF00FF00
#define MASK_A_32 0xFF000000
void *fb_hPixelSetAlpha4(void *dest, int color, size_t size)
{
unsigned int sc, srb, sg, sa, dc, drb, dg, a, irb, ig;
unsigned int *d = (unsigned int *)dest;
sc = (unsigned int)color;
srb = sc & MASK_RB_32;
sg = sc & MASK_G_32;
sa = sc & MASK_A_32;
a = sc >> 24;
for (; size; size--) {
dc = *d;
drb = dc & MASK_RB_32;
dg = dc & MASK_G_32;
irb = ((srb - drb) * a) >> 8;
ig = ((sg - dg) * a) >> 8;
dc = ((drb + irb) & MASK_RB_32) | ((dg + ig) & MASK_G_32) | sa;
*d++ = dc;
}
return dest;
}
extern void* fb_hPixelSetAlpha4MMX(void* dest, int color, size_t size);
typedef unsigned int PixelTypeSrc;
typedef unsigned int PixelTypeDest;
int __cdecl main(int argc, char** argv)
{
unsigned w = strtoul(argv[1], NULL, 10);
unsigned h = strtoul(argv[2], NULL, 10);
unsigned len = w * h;
int srcPixel, same;
unsigned int i;
PixelTypeDest* dst = calloc(len, sizeof(*dst));
PixelTypeDest* dst2 = calloc(len, sizeof(*dst2));
PixelTypeSrc* src3 = calloc(len, sizeof(*src3));
for(i = 0; i < len; ++i)
{
dst[i] = 0xffed9564U;
}
memcpy(dst2, dst, len * sizeof(*dst));
srcPixel = strtoul(argv[3], NULL, 16);
printf("srcPixels are %#x - dstPixels are %#x\n", srcPixel, dst[0]);
for(i = 0; i < len; ++i)
{
src3[i] = srcPixel;
}
fb_hPixelSetAlpha4(dst, srcPixel, len);
fb_hPixelSetAlpha4MMX(dst2, srcPixel, len);
same = memcmp(dst, dst2, len * sizeof(*dst));
printf(
"C (f-%#x, l-%#x)\nMMX (f-%#x, l-%#x)\nmemcmp=%d",
dst[0],
dst[len - 1],
dst2[0],
dst2[len - 1],
same
);
}
I have tried the latest builds of the compilers and they seem broken, reporting wrong warnings:
FreeBASIC Compiler - Version 1.06.0 (08-26-2018), built for win32 (32bit)
warning 43(0): Argument count mismatch
SetWindowSubclass hCtl, CAST(SUBCLASSPROC, pWndProc), uIdSubclass, dwRefData
FreeBASIC Compiler - Version 1.06.0 (08-26-2018), built for win64 (64bit)
Warning 43(0): Argument count mismatch
SetWindowSubclass hCtl, CAST(SUBCLASSPROC, pWndProc), uIdSubclass, dwRefData
warning 41(0): Return type mismatch
bi.lpfn = cast(BFFCALLBACK, @AfxBrowseForFolderProc)
where bi has been declared as bi AS BROWSEINFOW
They compile fine, without errors or warnings, with the previous 1.06 versions.
See also: https://freebasic.net/forum/viewtopic.php?f=3&t=27168
In the below code, a white border should be drawn between two grey borders, but some of it is cropped out of the viewport, and so not drawn.
screen 12
view (120,120)-(220,220), , 7 '' grey border outside viewport
window screen (0,0)-(1,1)
line (0.01,0.01)-(0.99,0.99), 7, b '' grey inner border of Window (1px inwards)
line (0,0)-(1,1), 15, b '' white outer border of Window (buggy line)
sleep
In QBASIC, all three borders can be fully seen.
I've investigated in https://freebasic.net/forum/viewtopic.php?p=254681#p254681, and found two bugs in fb_hTranslateCoord() (and associated code).
One-line expression:
var square = Function(n As Integer) n * n
Print square(4)
Multi-line expression:
var division = Function(u As Integer, v As Integer)
Return u \ v
End Function
Print division(10, 5)
Please read these two forum threads:
https://www.freebasic.net/forum/viewtopic.php?f=17&t=29149
https://www.freebasic.net/forum/viewtopic.php?f=17&t=29165
The last thread I posted a patch. I did it in darkness without any guidance, so please don't surprise if it doesn't work at all.
Best regards.
I have found The GUI toolkit, which would even allow totally blind programmer to create GUI WIndows apps which will look acceptable for sighted sers.
But unfortunately, I AM sad, that yours compiler, which produces so reliable executable code have been based on The strange approach while calling WIndows dlls.
Why programmer can not simply call Windows dll by typing
Declare Function BASS_StreamCreateURL Lib "bass.dll" (ByVal url As String, ByVal offset As Long, ByVal flags As Long, ByVal proc As Long, ByVal user As Long) As Long
Why developer or somebody around Free Basic community must generate .lib.a special file and .bi file?
How complex would be to reprogram Free Basic compiler so dlls would be possible to call as in Microsoft VIsual Basic by simply declaring it?
Is it very complex task to be done in opensource free product? Or which circunstamces have lead you to to call libraries by using so complex way?
If is it Free Basic development paradighm, has it some advantage while comparing it with call method, which Microsoft Visual Basic uses?
Memory allocation, faster speed, ETC?
Thank you very very much for yours explanation.
When I run make, it shows this:
/bin/sh: fbc: command not found
So I tried to run make bootstrap.
But when linking, it tells me:
Undefined symbols for architecture x86_64:
"_fb_ConsoleGetMouse", referenced from:
_fb_GetMouse in hook_getmouse.o
"_fb_ConsoleMultikey", referenced from:
_fb_Multikey in hook_multikey.o
"_fb_ConsoleSetMouse", referenced from:
_fb_SetMouse in hook_setmouse.o
"_fb_GfxGetJoystick", referenced from:
_fb_GfxStickQB in gfx_stick.o
_fb_GfxStrigQB in gfx_stick.o
"_fb_SerialClose", referenced from:
_fb_DevComClose in dev_com.o
"_fb_SerialGetRemaining", referenced from:
_fb_DevComEof in dev_com.o
_fb_DevComTell in dev_com.o
"_fb_SerialOpen", referenced from:
_fb_DevComOpen in dev_com.o
"_fb_SerialRead", referenced from:
_fb_DevComRead in dev_com.o
_fb_DevComReadWstr in dev_com.o
"_fb_SerialWrite", referenced from:
_fb_DevComWrite in dev_com.o
_fb_DevComWriteWstr in dev_com.o
"_fb_hGL_GetProcAddress", referenced from:
_fb_GfxGetGLProcAddress in gfx_opengl.o
"_fb_hIn", referenced from:
_fb_In in hook_ports.o
_fb_Wait in hook_ports.o
(maybe you meant: _fb_hInit, _fb_hInitConsole )
"_fb_hOut", referenced from:
_fb_Out in hook_ports.o
"_main", referenced from:
implicit entry/start for main executable
ld: symbol(s) not found for architecture x86_64
So how can I compile it on macOS?
fbc/inc/win/ntdef.bi
#include once "excpt.bi" <- missing bi.
#include once "sdkddkver.bi" <- missing bi.
Borderless window (GFX_NO_FRAME) will freeze at exit, only in opengl mode (GFX_OPENGL).
[code]
dim as integer fullscreen=0, useopengl=1, gfxnoswitch=0, borderlesswindow=1, alwaysontop=0, alphaprimitives=0, highpriority=0, multisample=0
dim as long screenflags=iif(fullscreen,&h01,0) or iif(useopengl,&h02,0) or iif(gfxnoswitch,&h04,0) or iif(borderlesswindow,&h08,0) or iif(alwaysontop,&h20,0) or iif(alphaprimitives,&h40,0) or iif(highpriority,&h80,0) or iif(multisample,&h40000,0)
screenres 1920, 1080, 32, 1, screenflags, 60
do
screensync
flip
loop until inkey<>""
[/code]
There is a source code:
Function EntryPoint Alias "EntryPoint"()As Integer
Dim pValue As Integer Ptr = CPtr(Integer Ptr, 0)
Return 0
End Function
When compiling with the "-gen lvm " option and then compiling via "clang.exe -c -S EntryPoint.ll -o EntryPoint.asm" returns an error:
EntryPoint.ll:29:13: error: integer constant must have integer type
store i64* 0, i64** %PVALUE.1
^
1 error generated.
In the generated code, we find:
%FBSTRING = type { i8*, i64, i64 }
declare void @llvm.memset.p0i8.i32(i8*, i8, i32, i32, i1) nounwind
%fb_RTTI$ = type { i8*, i8*, %fb_RTTI$* }
@__fb_ZTS6Object = global %fb_RTTI$ zeroinitializer
@llvm.global_ctors = appending global [1 x { i32, void ()* }] [{ i32, void ()* } { i32 0, void ()* @fb_ctor__EntryPoint }]
define i64 @EntryPoint( ) nounwind
{
; localvar fb$result
%fb$result.0 = alloca i64
; localvar PVALUE
%PVALUE.1 = alloca i64*
; addrof fb$result
; memclear fb$result
%vr1 = bitcast i64* %fb$result.0 to i8*
call void @llvm.memset.p0i8.i32( i8* %vr1, i8 0, i32 8, i32 1, i1 false )
; label .Lt_0004
br label %.Lt_0004
.Lt_0004:
; store PVALUE := 20
store i64* 0, i64** %PVALUE.1
; store fb$result := 0
store i64 0, i64* %fb$result.0
; goto .Lt_0005
br label %.Lt_0005
.Lt_0006:
; label .Lt_0005
br label %.Lt_0005
.Lt_0005:
; loadres fb$result
%vr3 = load i64, i64* %fb$result.0
ret i64 %vr3
}
And it should be like this:
store i64* inttoptr (i64 0 to i64*), i64** %1, align 8
Clang also throws an error on strings:
@__fb_ZTS6Object = global %fb_RTTI$ zeroinitializer
@llvm.global_ctors = appending global [1 x { i32, void ()* }] [{ i32, void ()* } { i32 0, void ()* @fb_ctor__EntryPoint }]
If you remove them, the compilation will be successful.
I'm developing an fbc package for Gentoo, but there's a behavior in fbc that causes problems for the Gentoo build system. Gentoo packages are required to build executable with the symbol table intact (i.e. "not stripped" executables).
However, fbc automatically passes the -s option down to the linker if debugging/profiling is not enabled; this strips all symbol information from the executable. Since the addition of the -s option cannot be controlled, fbc executables cause the Gentoo build system to fail.
It is true that symbols will not be stripped if debugging is enabled, but this bloats the executables with additional information that is not used (e.g. debug_info). There are situations where symbols are useful outside of source code debugging, where debug_info and such are not neeeded.; for example, a live memory analyzer can keep track of symbol values if they are simply present in the symbol table without the need of additional debugging info.
I propose the following new compiler option:
-strip Omit all symbol information from the output file
It will be useful to have a way to manually control whether symbols are stripped or not. That should give user much finer control and freedom over the resulting executables.
in the raspberry pi, we want to use the framebuffer driver, to enable graphic mode without x11
the header files disables this drivers for the arm, because there is inline assembly.
this inline assembly is only used for the 4 bit per pixel mode, but we will use the 16bpp mode, so we could put the content of this method in comment for the arm target, instead of disable the driver
fre returns 0 in FreeBSD 12.0-RELEASE.
Hello,
I would like use FreeBASIC. But, FreeBASIC does not support non-English IBM/DOS character sets on graphical screen modes.
I would like to add support non-English IBM/DOS character sets on graphical screen modes?
Thanks.
Starting fullscreen (GFX_FULLSCREEN) in opengl mode (GFX_OPENGL) will cause the program to steal keyboard input from all other windows.
Can do ALT+ENTER, but can't ALT+TAB, can't type...
[code]
dim as integer fullscreen=1, useopengl=1, gfxnoswitch=0, borderlesswindow=0, alwaysontop=0, alphaprimitives=0, highpriority=0, multisample=0
dim as long screenflags=iif(fullscreen,&h01,0) or iif(useopengl,&h02,0) or iif(gfxnoswitch,&h04,0) or iif(borderlesswindow,&h08,0) or iif(alwaysontop,&h20,0) or iif(alphaprimitives,&h40,0) or iif(highpriority,&h80,0) or iif(multisample,&h40000,0)
screenres 1920, 1080, 32, 1, screenflags, 60
do
screensync
flip
loop until multikey(1)
[/code]
I think this behaviour was introduced trying to fix another bug (freeze on start).
The following error occurs when building from the FreeBasic-1.06.0-source-bootstrap.tar.xz source code:
LINK bootstrap/fbc
AR lib/freebasic/linux-x86_64/libfb.a
gcc: error: lib/freebasic/linux-x86_64/libfb.a: No such file or directory
AR lib/freebasic/linux-x86_64/libfbpic.a
make: *** [makefile:1093: bootstrap/fbc] Error 1
make: *** Waiting for unfinished jobs....
AR lib/freebasic/linux-x86_64/libfbmt.a
The following command was used to run the build:
make -j5 bootstrap CFLAGS="-DDISABLE_X11 -DDISABLE_GPM -DDISABLE_FFI -DDISABLE_OPENGL"
I suspect this is a race condition issue, because the issue disappears when the number of make jobs is restricted to 1:
make -j1 bootstrap CFLAGS="-DDISABLE_X11 -DDISABLE_GPM -DDISABLE_FFI -DDISABLE_OPENGL"
On my system, this issue is only present when making bootstrap; making all (i.e. compiling fbc normally using an existing fbc) completes correctly even with multiple make jobs.
This code will give a warning when compiled with -O 2 or higher:
const idx as integer=10
dim as string aa(1 to idx) = { "a","a","a","a","a","a","a","a","a","a" }
warn.c: In function ‘main’:
warn.c:49:26: warning: array subscript -1 is outside array bounds of ‘FBSTRING[10]’ {aka ‘struct [10]’} [-Warray-bounds]
49 | (FBSTRING*)&tmp$2$0 = (FBSTRING*)((uint8*)AA$0 + -24ll);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
warn.c:47:11: note: while referencing ‘AA$0’
47 | FBSTRING AA$0[10];
| ^~~~
If I dim with (0 to idx) instead of (1 to idx), the warning is gone.
As I'm sure you're aware, it's not clear how to bootstrap FBC.
Bootstrap of course means to build from source without an existing FBC binary.
It's a common problem. Consider the solutions SBCL has used over the years.
dim as integer x, y, rate
screeninfo x, y, , , ,rate
print rate
I have a 144Hz monitor.
If I compile and run this code using fbc linux, it will always return 50
If I compile it for windows and run it using wine, it will return the correct rate, 144.
screenres 320+88,200+88,8,0,GFX_FULLSCREEN causes programs to freeze. I am using Manjaro Linux with all the latest updates.
should return 0.00e-00
It should be something like
Dim protected _compilerKernelInstance as quantumUINT64 to x to y to z to a to b to c to d .. etc
(Or uint128, whatever)
C code equivalent is
q128 kip[a][b][c]; // etc
Edit: I mean multidimensional arrays
As observed in https://freebasic.net/forum/viewtopic.php?p=254055#p254055
dim as zstring ptr zptr = @"Hi"
dim as string s = *zptr '' "Hi"
dim as integer i = *zptr '' asc("H")
print i, s, z10 '' 72, Hi, Hi
I thought we'd fixed something like this before, but I can't find an existing bug report or changelog entry.
Potentially similar bugs were fixed at:
Duplicated here for BountySource.
Original Link:
https://sourceforge.net/p/fbc/bugs/801/
cVarOrDeref() allows DEREFs but not CALLCTOR/TYPEINI nodes, so it behaves differently with/without -exx for expressions like *@type<...>(...) (with -exx the DEREF/ADDROF is preserved due to null pointer checks, but without -exx it is solved out).
-exx should not have this kind of effect on the parsing.
Maybe cVarOrDeref() should just accept CALLCTOR/TYPEINI nodes too, but then code like this would be accepted too:
type UDT
i as integer
end type
dim x as UDT
type<UDT>(1) = x
which I don't think was ever intended to work. On the other hand, this already works:
type<UDT>().i = 1
so it wouldn't matter much.
Line 3311 in 5e93d69
This #ifdef looks both suspiciously placed(only covering single typedef) and having wrong version comparison(if LEQ than NT 5.2).
running the sample code from the manual 1.0.7 about getMouse()
the return of x, y, buttons works when setting any screenres but it doesnt return anything when in a console window. it seems to have worked on win7... something must have changed for win10
Build fails:
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
g++-multilib : Depends: cpp (>= 4:4.8.2-1ubuntu6) but it is not going to be installed
Depends: g++ (>= 4:4.8.2-1ubuntu6) but it is not going to be installed
Depends: g++-4.8-multilib (>= 4.8.2-5~) but it is not going to be installed
gcc-multilib : Depends: cpp (>= 4:4.8.2-1ubuntu6) but it is not going to be installed
Depends: gcc (>= 4:4.8.2-1ubuntu6) but it is not going to be installed
Depends: gcc-4.8-multilib (>= 4.8.2-5~) but it is not going to be installed
E: Unable to correct problems, you have held broken packages.
When using concatenate and assign operator &= on fixed length wstring buffer, the null terminator can be overwritten causing a buffer overrun on a subsequent operation.
dim a as wstring * 5
dim b as wstring * 3 = "12"
a &= b
print len(a) '' 2
a &= b
print len(a) '' 4
a &= b
print len(a) '' 6 (a buffer overrun)
a &= b '' then segfault (most usually)
print len(a)
Appears to be due to wrong logic in fb_WstrConcatAssign(). Length of memory to write is clamped, but logic assumes last character is a null. Last character written to the buffer is not null if the source string is truncated. And no null character is explicitly written.
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.