Revision history for DevMakingReleases


Revision [20794]

Last edited on 2016-03-12 13:32:10 by fxm [Formatting]

No Differences

Revision [19992]

Edited on 2016-02-10 15:48:47 by DkLwikki [Update link format]
Additions:
[[DevBuildKnownProblems|Known problems when compiling FB]]
[[DevGccToolchainChoice|GCC toolchain choice]]
Deletions:
[[DevBuildKnownProblems Known problems when compiling FB]]
[[DevGccToolchainChoice GCC toolchain choice]]


Revision [17708]

Edited on 2015-07-01 08:03:57 by DkLwikki [Add "build doc packages" to summary]
Additions:
- Build documentation packages (CHM on Windows, rest can be done on Linux)


Revision [17707]

Edited on 2015-07-01 08:02:41 by DkLwikki [Update release/build.sh command lines]
Additions:
./build.sh <target> <fbc-commit>%%
Deletions:
./build.sh <target> [<fbc-commit>]%%


Revision [17706]

Edited on 2015-07-01 08:02:11 by DkLwikki [Update release/build.sh command lines]
Additions:
./build.sh win32 <commitid>
./build.sh win32-mingworg <commitid>
./build.sh dos <commitid>%%
./build.sh win64 <commitid>%%
./build.sh linux-x86 <commitid>%%
./build.sh linux-x86_64 <commitid>%%
Deletions:
./build.sh win32
./build.sh win32-mingworg
./build.sh dos%%
./build.sh win64%%
./build.sh linux-x86%%
./build.sh linux-x86_64%%


Revision [17601]

Edited on 2015-04-11 17:30:05 by DkLwikki [Update (e.g. using the contrib/release/build.sh script nowadays)]
Additions:
**{{anchor name="GENERAL|In general"}}**
**{{anchor name="PACKAGING|Packaging and Manifests"}}**
**{{anchor name="TOOLCHAIN|Toolchain/build environment"}}**
**{{anchor name="RELEASESCRIPT|Release making script"}}**
**{{anchor name="DOCS|FB manual/documentation"}}**
**{{anchor name="SUMMARY|Summary: currently the easiest way to build a release"}}**
{{anchor name="GENERAL"}}{{fbdoc item="section" value="In general"}}
{{anchor name="PACKAGING"}}{{fbdoc item="section" value="Packaging and Manifests"}}
{{anchor name="TOOLCHAIN"}}{{fbdoc item="section" value="Toolchain/build environment"}}
{{anchor name="RELEASESCRIPT"}}{{fbdoc item="section" value="Release making script"}}
{{anchor name="DOCS"}}{{fbdoc item="section" value="FB manual/documentation"}}
{{anchor name="SUMMARY"}}{{fbdoc item="section" value="Summary: currently the easiest way to build a release"}}
Deletions:
{{fbdoc item="section" value="In general"}}
{{fbdoc item="section" value="Packaging and Manifests"}}
{{fbdoc item="section" value="Toolchain/build environment"}}
{{fbdoc item="section" value="Release making script"}}
{{fbdoc item="section" value="FB manual/documentation"}}
{{fbdoc item="section" value="Summary: currently the easiest way to build a release"}}


Revision [17600]

Edited on 2015-04-11 17:26:03 by DkLwikki [Update (e.g. using the contrib/release/build.sh script nowadays)]
Additions:
{{fbdoc item="section" value="In general"}}
Making an FB release means:
- Ensuring that the development version is in reasonable/usable state.
- Updating the documentation (Wiki and man page) for language/compiler changes and new features, if not yet done.
- Choosing and preparing gcc toolchains/build environments for ""DOS, Linux x86, Linux x86_64, Win32, Win64"".
- Compiling the development version of FB for all of them.
- Building the ""Win32"" installer (##contrib/nsis-installer/##).
- Testing the builds to ensure they are basically working.
- Synchronizing the online Wiki with the Wiki files in the fbc Git repository.
- Regenerating the ""PrintToc"" and ""CompilerErrMsg"" pages.
- Regenerating the examples/manual/ directory (code examples from the Wiki).
- Compiling the offline documentation (CHM, HTML, text).
- Creating the release packages (source code, binary builds, documentation).
- Uploading them and source code of dependencies (binutils, gcc, ""MinGW"", DJGPP, ...) to fbc's download site on ""SourceForge"".
- Announcing the new release on freebasic.net, in freebasic.net/forum News, and in ""SourceForge"" fbc project News.
The new release should be compilable with the previous version, so others can bootstrap it if wanted. Ideally it is compilable with even older versions.
FB releases in form of prebuilt binaries should be made at least for DOS, Linux, and ""Win32"". The DOS and ""Win32"" packages traditionally are standalone builds coming with prebuilt binutils and ""MinGW""/DJGPP libraries. The Linux package traditionally is a normal build intended to be installed into ##/usr## or ##/usr/local## and uses the system's binutils/libraries.
All the binary packages must effectively be built from the same source revision. All the to-be-released fbc binaries should be built with the same date, preferably on the same day the release is published. It's confusing to have multiple fbcs each with the same version number but different dates; are they the same version or not?
The sources must be packaged and uploaded in parallel to the binary packages. That includes sources for third-party binaries included in the FB binary packages, e.g. binutils, gdb, gcc, DJGPP/MinGW libs, etc.
To test the releases, it can be useful to
- run the test suite (for every target system)
- test all compilation modes (exe, dll, profiling, ...)
- run every .exe (binutils etc.) included in the packages to ensure that no DLLs are missing
- check that globbing works ok for Windows builds (all included .exe's and new generated ones too), because it might depend on the configuration of the ""MinGW-w64"" runtime.
Linux packages must be ##.tar.gz##, Windows/DOS packages must be ##.zip##. Other formats such as ##.tar.xz## or ##.7z## should be offered additionally, but note that there are people with e.g. older GNU/Linux systems that don't know ##.tar.lzma## or ##.tar.xz##, or with Windows systems that don't have 7-zip installed.
The FB makefile offers the ##gitdist## command for packaging the source code via ##git archive##, and the ##bindist## command for packaging previously built binaries. Example workflow:
%%# Go to fbc Git clone
##gitdist## creates source tarballs in multiple formats. It assumes that all changes to the fbc source code used for building the release have been committed to Git.
##bindist## creates the needed binary archive(s), potentially in multiple formats, with the proper package name and directory layout depending on the target platform and whether it's a normal or standalone build, and it (re)generates the corresponding manifest (list of all files included in the archive) in the ##contrib/manifest/## directory in the fbc source tree.
By checking the manifest differences via Git (git diff, git gui, etc.) you can check whether any files are missing in comparison to the previous release, or whether files were added that should not be included. Should there be any such issues, they may need to be fixed manually (possible the makefile's ##bindist## implementation needs updating, or you simply need to copy in missing files), after which ##make bindist## can be run again to recreate the package and update the manifest again.
##bindist## configuration options:
- ##TARGET_OS##/##TARGET_ARCH## makefile variables: You can set ##TARGET_OS## and/or ##TARGET_ARCH## on the make command line to override the makefile's default uname check. This is useful if you want to package for a different system than what the uname command returns. For example, packaging the FB-dos release from a ""MinGW/MSYS"" shell (with MSYS tools instead of DJGPP tools):
%%make bindist TARGET_OS=dos
- ##FBPACKAGE## makefile variable: Package/archive file name without path or extension. Defaults:
- Linux/BSD normal, Windows/DOS standalone: ##""FreeBASIC-x.xx.x-target""##
- Linux/BSD standalone: ##""FreeBASIC-x.xx.x-target-standalone""##
- Windows/DOS normal (""MinGW/DJGPP-style"" packages): ##""fbc-x.xx.x-target""##
- ##FBPACKSUFFIX## makefile variable: Suffix string that will be appended to the package name (and the toplevel directory in the archive).
- ##FBMANIFEST## makefile variable: Manifest file name without path or extension. The defaults are the same as for ##FBPACKAGE##, except without the ##-x.xx.x## version number part.
- ##FBVERSION## makefile variable: Is already set in the makefile, but you can override it if you want to (e.g. when making testing releases instead of "official" releases). For example: ##FBVERSION=0.90.1## or ##FBVERSION=0.90.1rc1##
- ##DISABLE_DOCS=1## makefile variable: If this variable is set, ##bindist## will exclude documentation (readme, changelog, man page) and examples from the package. This is useful when creating small binary-only fbc packages such as those for installation into ""DJGPP/MinGW"" trees.
When making an FB release, the GCC toolchain used to build FB has a huge impact, because FB itself will basically become a modified/extended version of that toolchain. The FB-dos and FB-win32 releases include libraries from the used DJGPP/""MinGW"" toolchains, and they will be used for any FB programs made with those FB builds. Even the FB-linux release will depend on the gcc/glibc version it was built with, because of the precompiled rtlib/gfxlib2 libraries, and because of fbc which will have been linked against shared libraries that may not exist on other systems.
Additionally, different GCC toolchains and runtime libraries (e.g. ""MinGW.org"" vs. ""MinGW-w64"", or DJGPP 2.03 vs. 2.04 vs. CVS) can be more or less different in terms of ABI compatibility or runtime behaviour. As such any FB program can behave differently depending on the GCC toolchain, including fbc itself.
More information:
[[DevBuildKnownProblems Known problems when compiling FB]]
[[DevGccToolchainChoice GCC toolchain choice]]
{{fbdoc item="section" value="Release making script"}}
The FB sources contain a release-making script at ##contrib/release/build.sh##.
This script downloads & extracts ""DJGPP/MinGW.org/MinGW-w64"" toolchains, FB packages for bootstrapping, fbc sources, etc., then builds normal and standalone versions of fbc, and finally creates the complete packages ready to be released.
- Downloaded archives are cached in the ##contrib/release/input/## dir
- Output packages & manifests are put in the ##contrib/release/output/## dir
- Toolchain source packages are downloaded too
- fbc sources are retrieved from Git; you can specify the exact commit to build, the default is "master".
Usage:
%%cd contrib/release
./build.sh <target> [<fbc-commit>]%%
##<target>## can be one of:
- ##dos##: DOS build: must run on ""Win32"". Uses ""Win32 MSYS"", but switches to DJGPP for building FB.
- ##linux-x86##, ##linux-x86_64##: native builds on ""GNU/Linux"" x86/x64_64 - relying on the host toolchains; no gcc toolchain is downloaded; no standalone version of FB is built.
- ##win32##: 32bit ""MinGW-w64"" build: must run on ""Win32"". Uses MSYS.
- ##win32-mingworg##: 32bit ""MinGW.org"" build: must run on ""Win32"". Uses MSYS.
- ##win64##: 64bit ""MinGW-w64"" build: must run on ""Win64"". Uses ""Win32"" MSYS, but overrides the FB makefile's uname check in order to build for 64bit instead of 32bit.
Requirements:
- MSYS environment on ""Windows"" with: bash, wget/curl, zip, unzip, patch, make, findutils (win32/win64 builds need to be able to run ./configure scripts, to build libffi)
- 7z (7-zip) in the PATH (win32/win64)
- makensis (NSIS) in the PATH (FB-win32 installer)
- git in the PATH
- internet access for downloading input packages and fbc via git
Some of the ideas behind this script:
- Automating the build process for FB releases => less room for mistakes
- Starting from scratch everytime => clean builds
- Specifying the exact ""DJGPP/MinGW"" packages to use => reproducible builds
- Only work locally, e.g. don't touch existing ""DJGPP/MinGW"" setups on the host
{{fbdoc item="section" value="Summary: currently the easiest way to build a release"}}
- Update the wiki snapshot in the fbc sources
- Regenerate PrintToc and CompilerErrMsg
- If needed, update wiki samples in examples/manual/
- Check whether toolchains used in the ##contrib/release/build.sh## script need updating
- Have target systems ready (installations of Linux and Windows, 32bit and 64bit -- virtual machines are useful for this)
- For each system, update fbc sources (to have the latest version of the release script)
- On win32:
%%cd contrib/release
./build.sh win32
./build.sh win32-mingworg
./build.sh dos%%
- On win64:
%%cd contrib/release
./build.sh win64%%
- On linux-x86:
%%cd contrib/release
./build.sh linux-x86%%
- On linux-x86_64:
%%cd contrib/release
./build.sh linux-x86_64%%
- Collect all the archives and manifests from the ##contrib/release/input## and ##contrib/release/output## directories
- Review the manifests to check for missing files etc.
- If ok, commit the new manifests
- Create the release tag
- Upload the packages
- Post announcements
Deletions:
- Making an FB release means:
- Ensuring that the development version is in reasonable/usable state.
- Updating the documentation (Wiki and man page) for language/compiler changes and new features, if not yet done.
- Choosing and preparing gcc toolchains/build environments for ""DOS, Linux x86, Linux x86_64, Win32, Win64"".
- Compiling the development version of FB for all of them.
- Building the ""Win32"" installer (##contrib/nsis-installer/##).
- Testing the builds to ensure they are basically working.
- Synchronizing the online Wiki with the Wiki files in the fbc Git repository.
- Regenerating the ""PrintToc"" and ""CompilerErrMsg"" pages.
- Regenerating the examples/manual/ directory (code examples from the Wiki).
- Compiling the offline documentation (CHM, HTML, text).
- Creating the release packages (source code, binary builds, documentation).
- Uploading them and source code of dependencies (binutils, gcc, ""MinGW"", DJGPP, ...) to fbc's download site on ""SourceForge"".
- Announcing the new release on freebasic.net, in freebasic.net/forum News, and in ""SourceForge"" fbc project News.
- When making a new release, please check that the source code for the new release can be compiled using at least the compiler from the previous release. Ideally it is compilable with even older versions. This way we can ensure that fbc can always be bootstrapped using the last release.
- FB releases in form of prebuilt binaries should be made at least for DOS, Linux, and ""Win32"".
- The DOS and ""Win32"" packages traditionally are standalone builds coming with prebuilt binutils and ""MinGW""/DJGPP libraries.
- The Linux package traditionally is a normal build intended to be installed into ##/usr## or ##/usr/local## and uses the system's binutils/libraries.
- All the binary packages must be built from the same source revision.
- The source must be packaged and uploaded in parallel to the binary packages.
- All the to-be-released fbc binaries should be built with the same date, preferably on the same day the release is published. It's confusing to have multiple fbcs each with the same version number but different dates; are they the same version or not?
- All the binary packages should include a build.txt file describing the gcc/binutils toolchain used for the build and the tools/libraries included in the FB package.
- Run the test suite for every release build/package to ensure everything basically works.
- Test all compilation modes (exe, dll, profiling, ...) to ensure everything basically works.
- Run every .exe (binutils etc.) included in the packages to ensure that no DLLs are missing
- Check that globbing works ok for Windows builds (all included .exe's and new generated ones too),
because it depends on the configuration of the ""MinGW-w64"" runtime.
- Linux packages must be ##.tar.gz##, Windows/DOS packages must be ##.zip##. Other formats such as ##.tar.xz## or ##.7z## should be offered additionally, but note that there are people with e.g. older GNU/Linux systems that don't know ##.tar.lzma## or ##.tar.xz##, or with Windows systems that don't have 7-zip installed.
The FB makefile offers the ##gitdist## command for packaging the source code via ##git archive##, and the ##bindist## command for packaging previously built binaries. Example workflow:
%%# Go to fbc Git clone
##gitdist## creates source tarballs in multiple formats. It assumes that all changes to the fbc source code used for building the release have been committed to Git.
##bindist## creates the needed binary archive(s), potentially in multiple formats, with the proper package name and directory layout depending on the target platform and whether it's a normal or standalone build, and it (re)generates the corresponding manifest (list of all files included in the archive) in the ##contrib/manifest/## directory in the fbc source tree.
By checking the manifest differences via Git (git diff, git gui, etc.) you can check whether any files are missing in comparison to the previous release, or whether files were added that should not be included. Should there be any such issues, they may need to be fixed manually (possible the makefile's ##bindist## implementation needs updating, or you simply need to copy in missing files), after which ##make bindist## can be run again to recreate the package and update the manifest again.
##bindist## configuration options:
- ##TARGET_OS##/##TARGET_ARCH## makefile variables: You can set ##TARGET_OS## and/or ##TARGET_ARCH## on the make command line to override the makefile's default uname check. This is useful if you want to package for a different system than what the uname command returns. For example, packaging the FB-dos release from a ""MinGW/MSYS"" shell (with MSYS tools instead of DJGPP tools):

%%make bindist TARGET_OS=dos
- ##FBPACKAGE## makefile variable: Package/archive file name without path or extension. Defaults:
- Linux/BSD normal, Windows/DOS standalone: ##""FreeBASIC-x.xx.x-target""##
- Linux/BSD standalone: ##""FreeBASIC-x.xx.x-target-standalone""##
- Windows/DOS normal (""MinGW/DJGPP-style"" packages): ##""fbc-x.xx.x-target""##
- ##FBPACKSUFFIX## makefile variable: Suffix string that will be appended to the package name (and the toplevel directory in the archive).
- ##FBMANIFEST## makefile variable: Manifest file name without path or extension. The defaults are the same as for ##FBPACKAGE##, except without the ##-x.xx.x## version number part.
- ##FBVERSION## makefile variable: Is already set in the makefile, but you can override it if you want to (e.g. when making testing releases instead of "official" releases). For example: ##FBVERSION=0.90.1## or ##FBVERSION=0.90.1rc1##
- ##DISABLE_DOCS=1## makefile variable: If this variable is set, ##bindist## will exclude documentation (readme, changelog, man page) and examples from the package. This is useful when creating small binary-only fbc packages such as those for installation into ""DJGPP/MinGW"" trees.
When making an FB release, the GCC toolchain used to build FB has a huge impact, because FB itself will basically become a modified/extended version of that toolchain. The FB-dos and FB-win32 releases include libraries from the used DJGPP/""MinGW"" toolchains, and they will be used for any FB programs made with those FB builds. Even the FB-linux release will depend on the gcc/glibc version it was built with, because of the precompiled rtlib/gfxlib2 libraries, and because of fbc which will have been linked against shared libraries that may not exist on other systems.
Additionally, different GCC toolchains and runtime libraries (e.g. ""MinGW.org"" vs. ""MinGW-w64"", or DJGPP 2.03 vs. 2.04 vs. CVS) can be more or less different in terms of ABI compatibility or runtime behaviour. As such any FB program can behave differently depending on the GCC toolchain, including fbc itself.
More information:
[[DevBuildKnownProblems Known problems when compiling FB]]
[[DevGccToolchainChoice GCC toolchain choice]]


Revision [17399]

Edited on 2014-12-29 15:25:15 by DkLwikki [Document FBPACKSUFFIX]
Additions:
- ##FBPACKSUFFIX## makefile variable: Suffix string that will be appended to the package name (and the toplevel directory in the archive).


Revision [17268]

Edited on 2014-09-10 12:19:58 by DkLwikki [Document DISABLE_DOCS]
Additions:
- ##DISABLE_DOCS=1## makefile variable: If this variable is set, ##bindist## will exclude documentation (readme, changelog, man page) and examples from the package. This is useful when creating small binary-only fbc packages such as those for installation into ""DJGPP/MinGW"" trees.


Revision [17261]

Edited on 2014-09-10 08:29:59 by DkLwikki [Formatting]
Additions:
- Building the ""Win32"" installer (##contrib/nsis-installer/##).
- Regenerating the examples/manual/ directory (code examples from the Wiki).
- Compiling the offline documentation (CHM, HTML, text).
Deletions:
- Building the ""Win32"" installer (##contrib/nsis-installer/##)
- Regenerating the examples/manual/ directory (code examples from the Wiki)
- Compiling the offline documentation (CHM, HTML, text)


Revision [17260]

Edited on 2014-09-10 08:29:33 by DkLwikki [Mention man page and Win32 installer too]
Additions:
- Updating the documentation (Wiki and man page) for language/compiler changes and new features, if not yet done.
- Building the ""Win32"" installer (##contrib/nsis-installer/##)
Deletions:
- Updating the documentation for language/compiler changes and new features, if not yet done.


Revision [17259]

Edited on 2014-09-10 07:53:35 by DkLwikki [Update/overhaul]
Additions:
- Synchronizing the online Wiki with the Wiki files in the fbc Git repository.
- Regenerating the ""PrintToc"" and ""CompilerErrMsg"" pages.
- Regenerating the examples/manual/ directory (code examples from the Wiki)
- When making a new release, please check that the source code for the new release can be compiled using at least the compiler from the previous release. Ideally it is compilable with even older versions. This way we can ensure that fbc can always be bootstrapped using the last release.
Deletions:
- Synchronizing the online Wiki with the Wiki files in the fbc Git repository, regenerating the ""PrintToc"" and ""CompilerErrMsg"" pages.
- When making a new release, please check that the source code for the new release can be compiled using at least the compiler from the previous release. Ideally it is compilable with even older versions. This way we can ensure that fbc can always be bootstrapped.


Revision [17258]

Edited on 2014-09-10 07:51:17 by DkLwikki [Update/overhaul]
Additions:
- Choosing and preparing gcc toolchains/build environments for ""DOS, Linux x86, Linux x86_64, Win32, Win64"".
- Synchronizing the online Wiki with the Wiki files in the fbc Git repository, regenerating the ""PrintToc"" and ""CompilerErrMsg"" pages.
- Uploading them and source code of dependencies (binutils, gcc, ""MinGW"", DJGPP, ...) to fbc's download site on ""SourceForge"".
- Announcing the new release on freebasic.net, in freebasic.net/forum News, and in ""SourceForge"" fbc project News.
Deletions:
- Choosing and preparing gcc toolchains/build environments for DOS, Linux x86, Linux x86_64, Win32, Win64.
- Synchronizing the online Wiki with the Wiki files in the fbc Git repository, regenerating the PrintToc and CompilerErrMsg pages.
- Uploading them and source code of dependencies (binutils, gcc, ""MinGW"", DJGPP, ...) to fbc's download site on SourceForge.
- Announcing the new release on freebasic.net, in freebasic.net/forum News, and in SourceForge fbc project News.


Revision [17257]

Edited on 2014-09-10 07:50:20 by DkLwikki [Update/overhaul]
Additions:
- Making an FB release means:
- Ensuring that the development version is in reasonable/usable state.
- Updating the documentation for language/compiler changes and new features, if not yet done.
- Choosing and preparing gcc toolchains/build environments for DOS, Linux x86, Linux x86_64, Win32, Win64.
- Compiling the development version of FB for all of them.
- Testing the builds to ensure they are basically working.
- Synchronizing the online Wiki with the Wiki files in the fbc Git repository, regenerating the PrintToc and CompilerErrMsg pages.
- Compiling the offline documentation (CHM, HTML, text)
- Creating the release packages (source code, binary builds, documentation).
- Uploading them and source code of dependencies (binutils, gcc, ""MinGW"", DJGPP, ...) to fbc's download site on SourceForge.
- Announcing the new release on freebasic.net, in freebasic.net/forum News, and in SourceForge fbc project News.
- When making a new release, please check that the source code for the new release can be compiled using at least the compiler from the previous release. Ideally it is compilable with even older versions. This way we can ensure that fbc can always be bootstrapped.
- The DOS and ""Win32"" packages traditionally are standalone builds coming with prebuilt binutils and ""MinGW""/DJGPP libraries.
- The Linux package traditionally is a normal build intended to be installed into ##/usr## or ##/usr/local## and uses the system's binutils/libraries.
- All the binary packages must be built from the same source revision.
- The source must be packaged and uploaded in parallel to the binary packages.
- All the to-be-released fbc binaries should be built with the same date, preferably on the same day the release is published. It's confusing to have multiple fbcs each with the same version number but different dates; are they the same version or not?
- All the binary packages should include a build.txt file describing the gcc/binutils toolchain used for the build and the tools/libraries included in the FB package.
- Run the test suite for every release build/package to ensure everything basically works.
- Test all compilation modes (exe, dll, profiling, ...) to ensure everything basically works.
- Run every .exe (binutils etc.) included in the packages to ensure that no DLLs are missing
- Check that globbing works ok for Windows builds (all included .exe's and new generated ones too),
because it depends on the configuration of the ""MinGW-w64"" runtime.
- Linux packages must be ##.tar.gz##, Windows/DOS packages must be ##.zip##. Other formats such as ##.tar.xz## or ##.7z## should be offered additionally, but note that there are people with e.g. older GNU/Linux systems that don't know ##.tar.lzma## or ##.tar.xz##, or with Windows systems that don't have 7-zip installed.
The FB makefile offers the ##gitdist## command for packaging the source code via ##git archive##, and the ##bindist## command for packaging previously built binaries. Example workflow:
%%# Go to fbc Git clone
cd fbc
# Compile FB
make
# Package the source code
make gitdist
# Package the binaries, regenerate the manifest
make bindist
# Check the manifest
git diff
%%
##gitdist## creates source tarballs in multiple formats. It assumes that all changes to the fbc source code used for building the release have been committed to Git.
##bindist## creates the needed binary archive(s), potentially in multiple formats, with the proper package name and directory layout depending on the target platform and whether it's a normal or standalone build, and it (re)generates the corresponding manifest (list of all files included in the archive) in the ##contrib/manifest/## directory in the fbc source tree.
By checking the manifest differences via Git (git diff, git gui, etc.) you can check whether any files are missing in comparison to the previous release, or whether files were added that should not be included. Should there be any such issues, they may need to be fixed manually (possible the makefile's ##bindist## implementation needs updating, or you simply need to copy in missing files), after which ##make bindist## can be run again to recreate the package and update the manifest again.
##bindist## configuration options:
- ##TARGET_OS##/##TARGET_ARCH## makefile variables: You can set ##TARGET_OS## and/or ##TARGET_ARCH## on the make command line to override the makefile's default uname check. This is useful if you want to package for a different system than what the uname command returns. For example, packaging the FB-dos release from a ""MinGW/MSYS"" shell (with MSYS tools instead of DJGPP tools):

%%make bindist TARGET_OS=dos
%%
- ##FBPACKAGE## makefile variable: Package/archive file name without path or extension. Defaults:

- Linux/BSD normal, Windows/DOS standalone: ##""FreeBASIC-x.xx.x-target""##
- Linux/BSD standalone: ##""FreeBASIC-x.xx.x-target-standalone""##
- Windows/DOS normal (""MinGW/DJGPP-style"" packages): ##""fbc-x.xx.x-target""##

- ##FBMANIFEST## makefile variable: Manifest file name without path or extension. The defaults are the same as for ##FBPACKAGE##, except without the ##-x.xx.x## version number part.


- ##FBVERSION## makefile variable: Is already set in the makefile, but you can override it if you want to (e.g. when making testing releases instead of "official" releases). For example: ##FBVERSION=0.90.1## or ##FBVERSION=0.90.1rc1##
{{fbdoc item="section" value="Toolchain/build environment"}}
When making an FB release, the GCC toolchain used to build FB has a huge impact, because FB itself will basically become a modified/extended version of that toolchain. The FB-dos and FB-win32 releases include libraries from the used DJGPP/""MinGW"" toolchains, and they will be used for any FB programs made with those FB builds. Even the FB-linux release will depend on the gcc/glibc version it was built with, because of the precompiled rtlib/gfxlib2 libraries, and because of fbc which will have been linked against shared libraries that may not exist on other systems.
Additionally, different GCC toolchains and runtime libraries (e.g. ""MinGW.org"" vs. ""MinGW-w64"", or DJGPP 2.03 vs. 2.04 vs. CVS) can be more or less different in terms of ABI compatibility or runtime behaviour. As such any FB program can behave differently depending on the GCC toolchain, including fbc itself.
More information:
[[DevBuildKnownProblems Known problems when compiling FB]]
[[DevGccToolchainChoice GCC toolchain choice]]
##./mkprntoc -web##
Deletions:
- the DOS and ""Win32"" packages traditionally are standalone builds coming with prebuilt binutils and libraries
- the Linux package traditionally is intended to be installed into /usr or /usr/local and uses the system's binutils/libraries
- All the to-be-released fbc binaries should be built with the same date, preferably on the same day the release is published (it's confusing to have multiple fbcs each with the same version number but different dates; are they the same version or not?)
- Linux packages must be .tar.gz, Windows packages must be .zip, DOS packages must be .zip with low word size/fast byte setting. Other formats should be offered additionally, but there are people with e.g. older GNU/Linux systems that don't know .tar.lzma or .tar.xz, or with Windows systems that don't have 7-zip installed.
After FB, binutils and external libraries etc. have been compiled and/or copied into the FB tree, the contrib/release/pattern.bas program can be used to create the binary packages and corresponding manifests from the files in the FB tree.
##$ fbc contrib/release/pattern.bas -g -exx##
##$ contrib/release/pattern {dos|linux|win32}##
The manifests at contrib/release/manifest/*.lst will be regenerated. This can be used to check for extra/missing files in combination with Git's diff'ing capabilities. The include/exclude patterns in contrib/release/pattern.txt may need adjustment.
{{fbdoc item="section" value="Win32"}}
For the win32 build, ""MinGW.org"", TDM-GCC or ""MinGW-w64"" toolchains could be used.
""MinGW.org"" seems to be the most "standard", but apparently uses DW2 exception handling which results in huge .eh_frame sections in code generated by gcc, including libgcc.a etc. This is considered unacceptable bloat by some FB users.
TDM-GCC was used for some FB releases in the past because it provided GCC 4 while ""MinGW.org"" didn't yet. However ""MinGW.org"" has GCC 4 too nowadays.
""MinGW-w64"" is rather new but also used by many projects instead of ""MinGW.org"". Since they upstream all GCC patches it can be considered very "standard" aswell. When thinking about porting FB to 64bit Windows it'd make some sense to use ""MinGW-w64"" toolchains for both the 32bit and 64bit versions.
SJLJ vs DW2 exception handling doesn't really matter for FB at the moment since it doesn't support exceptions, but it could still matter when using static ""C++"" libraries linked into FB programs, such as ASpell, and it affects the binaries generated by gcc including gcc's own objects/libraries (such as libgcc.a or crtbegin.o/crtend.o).
Even though the core C ABI is surely compatible between the different GCC ""Win32"" toolchains, there may be differences in ""libsupc++.a"" (which FB uses), or other files, due to the exception handling configuration, and besides that different GCC release versions themselves have ABI differences, e.g. 4.6 vs 4.7 changed structures to assume ""__attribute__((ms_struct))"" by default, instead of ""__attribute__((gcc_struct))"". These things could cause problems between different FB releases and different ""MinGW"" toolchains.
{{fbdoc item="subsect" value="FreeBASIC-x.xx.x-win32"}}
- get the whole ""MinGW/MSYS"" setup from ""MinGW.org""
- and potentially ""MinGW-w64"" or TDM-GCC in a separate directory
- MSYS provides the Unixish shell environment
- ""MinGW"" provides autotools
- set the PATH accordingly, most importantly for gcc/binutils
- build FB with ENABLE_STANDALONE
- rebuild fbc with itself at least once, to ensure it itself uses its own rtlib, instead of the one from the host fbc
- use the contrib/libs/win32/build.sh script to build libffi.a and other external libraries
- copy the gcc/binutils/gdb compiled by the contrib/libs/win32/build.sh script into bin/win32/
- alternatively, copy binutils/gdb from the ""MinGW.org/MinGW-w64/TDM-GCC"" setup into bin/win32/:
- as.exe, ar.exe, ld.exe, dlltool.exe, gprof.exe, gdb.exe
- plus any needed DLLs (such as libintl, libiconv, libexpat...)
- also gcc.exe and its ../libexec/gcc/ directory for -gen gcc
- copy the latest ""GoRC.exe"" into bin/win32/
- use the lib/win32/makefile to copy the ""MinGW"" and ""Win32"" API libs from the ""MinGW.org/MinGW-w64/TDM-GCC"" into lib/win32/
- copy the GCC libs from ""MinGW.org/MinGW-w64/TDM-GCC"" setup into lib/win32/:
- libgcc.a, libgcc_eh.a (if it exists), ""libsupc++.a"", crtbegin.o, crtend.o
- crt2.o, dllcrt2.o, gcrt2.o
- libmingw32.a, libmingwex.a, libmoldname.a, libgmon.a
- run ##contrib/release/pattern.exe## to create the manifests and packages
- check the manifests and make adjustments if necessary
{{fbdoc item="subsect" value="fbc-x.xx.x-mingw32"}}
This is intended to be a build of FB for the ""MinGW.org"" toolchain, able to just be extracted into a ""MinGW"" tree like a ""MinGW"" package.
- get the ""MinGW.org""/MSYS setup, plus ""DirectX"" headers for gfxlib2
- build libffi.a
##../libffi-3.0.11/configure --disable-shared --prefix=C:/MinGW##
##make install##
- build FB
- run ##contrib/release/pattern.exe mingw32## to create the manifest and package
- check the manifest and make adjustments if necessary
{{fbdoc item="section" value="Linux"}}
Building binaries that work on most of the available GNU/Linux distributions is hard because even though they are often similar in general, they differ in detail just as often. The most common problem is mismatching glibc versions, i.e. the fbc binary is run on a system with older glibc than the one it was built on, and an "glibc too old" error is encountered. The ncurses library is not always exactly the same either, as shown by the "`ospeed' has different size, consider re-linking" warnings when running fbc. That's why the Linux releases have usually been built in some GNU/Linux system old enough to let the fbc binary work on Debian 4 and 5, the current supported Ubuntu versions (especially LTSs), Fedora and ""OpenSUSE"".
{{fbdoc item="subsect" value="FreeBASIC-x.xx.x-linuxmusl"}}
As of FB 0.24 it's possible to create static ELF binaries using [[http://www.etalabs.net/musl/ musl libc]] instead of glibc, which should prevent the problems mentioned above. Other alternative libc's might work too, though I (dkl) tested only musl libc and dietlibc, and musl worked almost without problems, while compiling the rtlib with dietlibc required more adjustments. Besides getting the rtlib to build, the other big issue is getting the proper target libraries.
libc & co (including crt{1,i,n}.o) are easy to build from the musl sources, but properly compiling GCC to get libgcc, ""libsupc++"" and crtbegin.o/crtend.o requires some experience. Luckily there is a script to create a musl libc GCC cross-compiling toolchains available at [[https://github.com/GregorR/musl-cross]].
The contrib/libs/linuxmusl/build.sh script uses that to build a whole statically linked FB setup using musl libc, including statically linked binutils and gcc, and tons of external libraries. This resulted in the FB-linuxmusl package.
- an FB source tarball must be made available in contrib/libs/src/
- then, run the contrib/libs/linuxmusl/build.sh script, it will work in the current directory
- it should finally produce an fbc-static directory containing an FB tree with statically linked fbc, and all the other built binaries and libraries
- run ##contrib/release/pattern linuxmusl## to create the manifests and packages
- check the manifests and make adjustments if necessary
{{fbdoc item="subsect" value="FreeBASIC-x.xx.x-linux"}}
- pick a distro
- build FB
- run ##contrib/release/pattern## to create the manifests and packages
- check the manifests and make adjustments if necessary
{{fbdoc item="section" value="DOS"}}
With DJGPP the choice is between the latest CVS version or the somewhat outdated DJGPP 2.04 beta release. Compiling DJGPP from CVS is not that much trouble though:
- get the DJGPP 2.04 setup as a base
- get & build DJGPPCVS with that ("make" in the src directory)
- copy all packages (gcc/binutils/etc.) except the old djdev (libc, libm, headers, etc.) over into the DJGPP CVS tree
- delete the DJGPP 2.04 setup
- and use the CVS version in its place
{{fbdoc item="subsect" value="FreeBASIC-x.xx.x-dos"}}
- Get the DJGPP setup, see also the DOS section on [[DevBuild]]
- build FB with ENABLE_STANDALONE
- copy binutils/gdb from DJGPP into bin/dos/:
as.exe, ar.exe, ld.exe, gprof.exe, gdb.exe
- copy libs from DJGPP into lib/dos/:
- crt0.o, gcrt0.o
- libemu.a, libm.a
- libgcc.a, libsupcx.a (renamed from libsupcxx.a)
- the contrib/libs/dos/build.sh script can also be used to cross-compile a lot of external libraries using a DJGPP cross-compiler toolchain
- run ##contrib/release/pattern.exe dos## to create the manifests and packages
- check the manifests and make adjustments if necessary
{{fbdoc item="subsect" value="fbcxxxxb.zip"}}
This is intended to be a build of FB for DJGPP, able to just be extracted into a DJGPP tree like a DJGPP package.
- DJGPP setup as for the ""FreeBASIC-x.xx.x-dos"" release
- build FB
- run ##contrib/release/pattern.exe djgpp## to create the manifest and package
- check the manifest and make adjustments if necessary
##./mkprnttoc -web##


Revision [16857]

Edited on 2013-06-22 12:51:31 by DkLwikki [Update for 0.90]
Additions:
- FB releases in form of prebuilt binaries should be made at least for DOS, Linux, and ""Win32"".
- the DOS and ""Win32"" packages traditionally are standalone builds coming with prebuilt binutils and libraries
- the Linux package traditionally is intended to be installed into /usr or /usr/local and uses the system's binutils/libraries
- Linux packages must be .tar.gz, Windows packages must be .zip, DOS packages must be .zip with low word size/fast byte setting. Other formats should be offered additionally, but there are people with e.g. older GNU/Linux systems that don't know .tar.lzma or .tar.xz, or with Windows systems that don't have 7-zip installed.
{{fbdoc item="section" value="Packaging and Manifests"}}
After FB, binutils and external libraries etc. have been compiled and/or copied into the FB tree, the contrib/release/pattern.bas program can be used to create the binary packages and corresponding manifests from the files in the FB tree.
##$ fbc contrib/release/pattern.bas -g -exx##
##$ contrib/release/pattern {dos|linux|win32}##
The manifests at contrib/release/manifest/*.lst will be regenerated. This can be used to check for extra/missing files in combination with Git's diff'ing capabilities. The include/exclude patterns in contrib/release/pattern.txt may need adjustment.
For the win32 build, ""MinGW.org"", TDM-GCC or ""MinGW-w64"" toolchains could be used.
""MinGW.org"" seems to be the most "standard", but apparently uses DW2 exception handling which results in huge .eh_frame sections in code generated by gcc, including libgcc.a etc. This is considered unacceptable bloat by some FB users.
TDM-GCC was used for some FB releases in the past because it provided GCC 4 while ""MinGW.org"" didn't yet. However ""MinGW.org"" has GCC 4 too nowadays.
""MinGW-w64"" is rather new but also used by many projects instead of ""MinGW.org"". Since they upstream all GCC patches it can be considered very "standard" aswell. When thinking about porting FB to 64bit Windows it'd make some sense to use ""MinGW-w64"" toolchains for both the 32bit and 64bit versions.
SJLJ vs DW2 exception handling doesn't really matter for FB at the moment since it doesn't support exceptions, but it could still matter when using static ""C++"" libraries linked into FB programs, such as ASpell, and it affects the binaries generated by gcc including gcc's own objects/libraries (such as libgcc.a or crtbegin.o/crtend.o).
Even though the core C ABI is surely compatible between the different GCC ""Win32"" toolchains, there may be differences in ""libsupc++.a"" (which FB uses), or other files, due to the exception handling configuration, and besides that different GCC release versions themselves have ABI differences, e.g. 4.6 vs 4.7 changed structures to assume ""__attribute__((ms_struct))"" by default, instead of ""__attribute__((gcc_struct))"". These things could cause problems between different FB releases and different ""MinGW"" toolchains.
- get the whole ""MinGW/MSYS"" setup from ""MinGW.org""
- and potentially ""MinGW-w64"" or TDM-GCC in a separate directory
- MSYS provides the Unixish shell environment
- ""MinGW"" provides autotools
- set the PATH accordingly, most importantly for gcc/binutils
- build FB with ENABLE_STANDALONE
- rebuild fbc with itself at least once, to ensure it itself uses its own rtlib, instead of the one from the host fbc
- use the contrib/libs/win32/build.sh script to build libffi.a and other external libraries
- copy the gcc/binutils/gdb compiled by the contrib/libs/win32/build.sh script into bin/win32/
- alternatively, copy binutils/gdb from the ""MinGW.org/MinGW-w64/TDM-GCC"" setup into bin/win32/:
- also gcc.exe and its ../libexec/gcc/ directory for -gen gcc
- copy the latest ""GoRC.exe"" into bin/win32/
- use the lib/win32/makefile to copy the ""MinGW"" and ""Win32"" API libs from the ""MinGW.org/MinGW-w64/TDM-GCC"" into lib/win32/
- copy the GCC libs from ""MinGW.org/MinGW-w64/TDM-GCC"" setup into lib/win32/:
- libgcc.a, libgcc_eh.a (if it exists), ""libsupc++.a"", crtbegin.o, crtend.o
- crt2.o, dllcrt2.o, gcrt2.o
- run ##contrib/release/pattern.exe## to create the manifests and packages
- check the manifests and make adjustments if necessary
This is intended to be a build of FB for the ""MinGW.org"" toolchain, able to just be extracted into a ""MinGW"" tree like a ""MinGW"" package.
- build FB
- run ##contrib/release/pattern.exe mingw32## to create the manifest and package
- check the manifest and make adjustments if necessary
Building binaries that work on most of the available GNU/Linux distributions is hard because even though they are often similar in general, they differ in detail just as often. The most common problem is mismatching glibc versions, i.e. the fbc binary is run on a system with older glibc than the one it was built on, and an "glibc too old" error is encountered. The ncurses library is not always exactly the same either, as shown by the "`ospeed' has different size, consider re-linking" warnings when running fbc. That's why the Linux releases have usually been built in some GNU/Linux system old enough to let the fbc binary work on Debian 4 and 5, the current supported Ubuntu versions (especially LTSs), Fedora and ""OpenSUSE"".
{{fbdoc item="subsect" value="FreeBASIC-x.xx.x-linuxmusl"}}
As of FB 0.24 it's possible to create static ELF binaries using [[http://www.etalabs.net/musl/ musl libc]] instead of glibc, which should prevent the problems mentioned above. Other alternative libc's might work too, though I (dkl) tested only musl libc and dietlibc, and musl worked almost without problems, while compiling the rtlib with dietlibc required more adjustments. Besides getting the rtlib to build, the other big issue is getting the proper target libraries.
libc & co (including crt{1,i,n}.o) are easy to build from the musl sources, but properly compiling GCC to get libgcc, ""libsupc++"" and crtbegin.o/crtend.o requires some experience. Luckily there is a script to create a musl libc GCC cross-compiling toolchains available at [[https://github.com/GregorR/musl-cross]].
The contrib/libs/linuxmusl/build.sh script uses that to build a whole statically linked FB setup using musl libc, including statically linked binutils and gcc, and tons of external libraries. This resulted in the FB-linuxmusl package.
- an FB source tarball must be made available in contrib/libs/src/
- then, run the contrib/libs/linuxmusl/build.sh script, it will work in the current directory
- it should finally produce an fbc-static directory containing an FB tree with statically linked fbc, and all the other built binaries and libraries
- run ##contrib/release/pattern linuxmusl## to create the manifests and packages
- check the manifests and make adjustments if necessary
{{fbdoc item="subsect" value="FreeBASIC-x.xx.x-linux"}}
- pick a distro
- build FB
- run ##contrib/release/pattern## to create the manifests and packages
- check the manifests and make adjustments if necessary
With DJGPP the choice is between the latest CVS version or the somewhat outdated DJGPP 2.04 beta release. Compiling DJGPP from CVS is not that much trouble though:
- get the DJGPP 2.04 setup as a base
- get & build DJGPPCVS with that ("make" in the src directory)
- copy all packages (gcc/binutils/etc.) except the old djdev (libc, libm, headers, etc.) over into the DJGPP CVS tree
- delete the DJGPP 2.04 setup
- and use the CVS version in its place
- build FB with ENABLE_STANDALONE
- the contrib/libs/dos/build.sh script can also be used to cross-compile a lot of external libraries using a DJGPP cross-compiler toolchain
- run ##contrib/release/pattern.exe dos## to create the manifests and packages
- check the manifests and make adjustments if necessary
This is intended to be a build of FB for DJGPP, able to just be extracted into a DJGPP tree like a DJGPP package.
- DJGPP setup as for the ""FreeBASIC-x.xx.x-dos"" release
- build FB
- run ##contrib/release/pattern.exe djgpp## to create the manifest and package
- check the manifest and make adjustments if necessary
Deletions:
- FB releases should be made at least for DOS, Linux, and ""Win32"".
- the DOS, ""Win32"" and Linux-standalone packages traditionally are standalone builds containing their own binutils and libraries
- the normal Linux package is intended to be installed into /usr or /usr/local and uses the system's binutils/libraries
- Linux packages must be .tar.gz, Windows packages must be .zip, DOS packages must be .zip with low word size. Other formats should be offered additionally, but there are people with e.g. older GNU/Linux systems that don't know .tar.lzma or .tar.xz, or with Windows systems that don't have 7-zip installed.
{{fbdoc item="section" value="Manifests"}}
- compile contrib/manifest/exclude.bas:
##$ fbc contrib/manifest/exclude.bas -g -exx##
- regenerate manifest:
##$ contrib/manifest/update.sh <manifest-name>##
- check for extra/missing files in combination with Git (e.g. git gui or git diff),
- adjust exclude patterns in contrib/manifest/exclude.ini if needed
- regenerate manifest again... and repeat
- finally, create a package based on the manifest:
##$ contrib/manifest/package.sh <manifest-name> <package-name> {targz|zip}##
- win32 standalone uses TDM-GCC
- TDM-GCC vs. ""MinGW.org"": TDM-GCC has smaller libgcc binaries than ""MinGW.org"", resulting in smaller FB programs. The difference is (presumably) due to TDM-GCC being configured for SJLJ exception rather than DW2. Since FB doesn't support exceptions yet, the exception handling method of the GCC toolchain doesn't really matter for plain FB programs; this may be different when third-party libraries are involved though. In programs using the GCC support libraries from the ""MinGW.org"" toolchain you can observe huge .eh_frame sections via "##objdump -h##". The presence of libgcc_eh is related to that aswell (TDM-GCC doesn't have it, but ""MinGW.org"" does and in fact it must be linked in there to satisfy dependencies).
- get the TDM-GCC/MSYS setup, plus ""DirectX"" headers for gfxlib2
##../libffi-3.0.11/configure --disable-shared --prefix=C:/TDM-GCC##
- build binutils 2.17 to get libbfd 2.17 and matching libiberty
##../binutils-2.17/configure --disable-shared --disable-nls --disable-werror##
(this requires automake, autoconf, bison, flex, etc. to be installed)
- get an FB setup to compile the new fbc binary (usually the latest development version, or at least the previous release)
- ensure the FB setup will link the new compiler against the libbfd.a 2.17 built before, e.g. by copying the libbfd.a into the FB setup's lib/ dir, or by using -p c:/path/to/libbfd217/ when linking the new fbc
- config.mk:
%%ENABLE_STANDALONE := YesPlease
ENABLE_FBBFD := 217
FBCFLAGS := -d ENABLE_TDMGCC
FBLFLAGS := -p c:/path/to/libbfd217/
%%
- build the import libs in lib/win32/
- copy binutils/gdb from TDM-GCC setup into bin/win32/:
- copy ""GoRC.exe"" (e.g. from previous FB release) into bin/win32/
- copy libs from TDM-GCC setup into lib/win32/:
- libgcc.a, ""libsupc++.a"", crtbegin.o, crtend.o
- crt2.o, dllcrt2.o, gcrt2.o, libmsvcrt.a -> libmsvcrt.dll.a
- all the ""Win32"" API import libraries from the w32api package, renamed from *.a to *.dll.a
##cd .../w32api/lib##
##for i in *.a; do mv $i `echo $i | sed -e 's/\.a/.dll.a/g'`; done##
##mv * .../fbc-standalone-release/lib/win32##
- copy in libbfd.a 2.17 (and libiberty.a) too
- copy in libffi.a into lib/win32/ too
- copy libffi's LICENSE file to doc/libffi-license.txt
- regenerate & check the manifest:
##contrib/manifest/update.sh win32##
- package:
##""contrib/manifest/package.sh win32 FreeBASIC-x.xx.x-win32 zip""##
- build binutils 2.17 to get libbfd 2.17 and matching libiberty
##../binutils-2.17/configure --disable-shared --disable-nls --disable-werror##
(this requires automake, autoconf, bison, flex, etc. to be installed)
- get an FB setup to compile the new fbc binary (usually the latest development version, or at least the previous release)
- ensure the FB setup will link the new compiler against the libbfd.a 2.17 built before, e.g. by copying the libbfd.a into the FB setup's lib/ dir, or by using -p c:/path/to/libbfd217/ when linking the new fbc
- config.mk:
%%FBLFLAGS := -p c:/path/to/libbfd217/
ENABLE_FBBFD := 217
%%
- copy inc/ to include/freebasic/
- regenerate & check the manifest:
##contrib/manifest/update.sh mingw32##
- package:
##contrib/manifest/package.sh mingw32 fbc-x.xx.x-mingw32 zip##
Building binaries that work on most of the available GNU/Linux distributions is hard because even though they are often similar in general, they differ differ in detail just as often. The most common problem is mismatching glibc versions, i.e. the fbc binary is run on a system with older glibc than the one it was built on, and an "glibc too old" error is encountered. The ncurses library is not always exactly the same either, as shown by the "`ospeed' has different size, consider re-linking" warnings when running fbc. That's why the Linux releases have usually been built in some GNU/Linux system old enough to let the fbc binary work on Debian 4 and 5, the current supported Ubuntu versions (especially LTSs), Fedora and ""OpenSUSE"".
As of FB 0.24 it's possible to create static ELF binaries using [[http://www.etalabs.net/musl/ musl libc]] instead of glibc, which should prevent the problems mentioned above. Other alternative libc's might work too, though I (dkl) tested only musl libc and dietlibc, and musl worked almost without problems, while compiling the rtlib with dietlibc required more adjustments. Besides getting the rtlib to build, the other big issue is getting the proper target libraries.
libc & co (including crt{1,i,n}.o) are easy to build from the musl sources, but properly compiling GCC to get libgcc, ""libsupc++"" and crtbegin.o/crtend.o requires some experience. Luckily there is a script to create a musl libc GCC cross-compiling toolchains available at [[https://github.com/GregorR/musl-cross]].
The contrib/build-musl-fbc.sh script uses that to build a whole "musl-fbc" setup, including the CRT/GCC/ncurses/bfd/CUnit target libraries needed to build a static fbc binary with it.
- lib{c,dl,m,pthread}, crt{1,i,n}.o from musl libc
- lib{gcc,gcc_eh,""supc++""}, crt{begin,end}.o from GCC, built against musl
- libncurses, libffi and libbfd 2.17 built against musl
- FB rtlib (without X11/gpm/""OpenGL"" support)
This should be enough for an fbc linked against musl libc, although it won't be enough for many other FB programs (e.g. graphics). The script builds a standalone FB setup, which is the native-to-musl cross-compiler with the binutils/libraries in order to compile static linux-musl FB programs. This setup can be used to create static FB programs, by doing:
##.../fbc/fbc-new -static -l tinfo ...##
{{fbdoc item="subsect" value="FreeBASIC-x.xx.x-linux-musl with fbc linked against musllibc"}}
- Use the build-musl-fbc.sh script to build the musl-fbc setup. Best copy the script in a new empty directory called "musl-fbc" and run it from there. It'll hg clone musl-cross and git clone fbc, and download lots of source packages (musl libc, Linux headers, gcc, binutils, ncurses, libffi, CUnit), unless those directories or packages already exist.
- config.mk:
%%FBC := .../musl-fbc/fbc/fbc-new
FBLFLAGS := -static -l tinfo
ENABLE_FBBFD := 217
ENABLE_STANDALONE := YesPlease
%%
- then build an fbc with it:
##$ make compiler##
- copy over all the files from .../musl-fbc/fbc/bin/linux/ into bin/linux/
- copy over all the files from .../musl-fbc/fbc/lib/linux/ into lib/linux/, including libfb[mt].a and fbrt0.o (no need to rebuild them in a new tree, when it's already done by the build-musl-fbc.sh script)
- regenerate & check the manifest:
##contrib/manifest/update.sh linux-musl##
- package:
##""contrib/manifest/package.sh linux-musl FreeBASIC-x.xx.x-linux-musl targz""##
{{fbdoc item="subsect" value="FreeBASIC-x.xx.x-linux with fbc linked against musllibc"}}
- Get the ""FreeBASIC-x.xx.x-linux-musl"" release first
- config.mk:
%%FBC := .../fbc-musl-release/fbc
FBLFLAGS := -static -l tinfo
ENABLE_FBBFD := 217
%%
This should result in a static fbc binary built using the musl-fbc setup, and normal rtlib/gfxlib2 builds, compiled with the native gcc. Even though the fbc binary will be statically linked against musl libc and be very portable, the rtlib/gfxlib2 will still use the system's glibc headers, so the compilation should not be done on a system with the latest glibc version, but perhaps on a system with slightly older version, just to ensure the rtlib won't use any new APIs that would make it ABI-incompatible with older glibc versions. This is essentially the same problem as with fbc, but it cannot be avoided, but just compiling against a specific glibc version causes less trouble than linking against a specific glibc version.
- regenerate & check the manifest:
##contrib/manifest/update.sh linux##
- package:
##""contrib/manifest/package.sh linux FreeBASIC-x.xx.x-linux targz""##
{{fbdoc item="subsect" value="FreeBASIC-x.xx.x-linux with normally linked fbc"}}
- fbc binaries created by the musl-fbc setup currently have a problem compiling float constants, causing test suite failures; until the issue is found and fixed, it does not seem like a good idea to use fbc binaries linked against musl libc.
- build binutils 2.17 to get libbfd 2.17 and matching libiberty
##../binutils-2.17/configure --disable-shared --disable-nls --disable-werror##
(this requires automake, autoconf, bison, flex, etc. to be installed)
- get an FB setup to compile the new fbc binary (usually the latest development version, or at least the previous release)
- ensure the FB setup will link the new compiler against the libbfd.a 2.17 built before, e.g. by copying the libbfd.a into the FB setup's lib/ dir, or by using -p /path/to/libbfd217/ when linking the new fbc
- config.mk:
%%ENABLE_FBBFD := 217
FBLFLAGS := -p /path/to/libbfd217/
%%
- regenerate & check the manifest:
##contrib/manifest/update.sh linux##
- package:
##""contrib/manifest/package.sh linux FreeBASIC-x.xx.x-linux targz""##
{{fbdoc item="subsect" value="staticglibc-fbc (native -> staticglibc cross)"}}
- Note that this all was built on ""OpenSUSE"" 12.1 i686 with gcc 4.6.1 and glibc 2.14.1
- libbfd 2.17
##../binutils-2.17/configure --disable-nls --disable-shared --disable-werror##
##make CFLAGS=-O2##
(doesn't need to complete, only libiberty/libbfd is needed)
copy libbfd.a, libiberty.a into lib/linux/
- libffi
##./configure --disable-shared##
##make CFLAGS=-O2##
copy libffi.a into lib/linux/
copy libffi's LICENSE file to doc/libffi-license.txt
- CUnit
##./configure --disable-shared##
copy libcunit.a into lib/linux/
- binutils
##../binutils-2.22/configure --disable-nls --disable-shared##
##make CFLAGS=-O2##
copy as/ar/ld/gprof into bin/linux/
- gcc
##""BOOT_CFLAGS=-O2 CFLAGS=-O2 ../gcc-4.7.1/configure --disable-bootstrap --enable-languages=c,c++ --disable-nls""##
copy libgcc.a, libgcc_eh.a, libgcov.a, crtbegin.o, crtend.o, ""libsupc++.a"" into lib/linux/
- glibc
##CFLAGS=-O2 ../glibc-2.14.1/configure --without-cvs --prefix=/opt/glibc##
make
copy into lib/linux/:
crt1.o, crti.o, crtn.o
libc.a, libpthread.a, libdl.a, libm.a
- ncurses
##../ncurses-5.9/configure --without-debug --without-profile --without-cxx --without-cxx-binding --without-ada --without-manpages --without-progs --without-tests --without-pkg-config --without-shared --without-libtool --with-termlib --without-gpm --without-dlsym --without-sysmouse --enable-termcap --without-develop --enable-const --prefix=/usr##
copy libncurses.a and libtinfo.a into lib/linux/
- config.mk:
%%ENABLE_STANDALONE := YesPlease
FBLFLAGS := -p /path/to/libbfd217
ENABLE_FBBFD := 217
%%
- regenerate & check the manifest:
##contrib/manifest/update.sh staticglibc-fbc##
- package:
##""contrib/manifest/package.sh staticglibc-fbc staticglibc-fbc-x.xx.x targz""##
{{fbdoc item="subsect" value="FreeBASIC-x.xx.x-linux-staticbin"}}
- exact same as FreeBASIC-x.xx.x-linux, except that the fbc binary is built using the staticglibc-fbc setup
- config.mk:
%%FBC := /path/to/staticglibc-fbc/fbc-new
FBLFLAGS := -static -l tinfo
ENABLE_FBBFD := 217
%%
- regenerate & check the manifest:
##contrib/manifest/update.sh linux##
- package:
##""contrib/manifest/package.sh linux FreeBASIC-x.xx.x-linux-staticbin targz""##
- Remember that FB needs a modified version of DJGPP's libc
- increase the maximum number of available file handles [if needed; it seems to be needed on Windows XP in order to build binutils 2.17 under DJGPP]
- Use 'msconfig' to add ""PerVMFiles=255"" to the ""[386Enh]"" section of ""SYSTEM.INI""
- Edit setting in ""C:\WINDOWS\system32\CONFIG.NT"": ""files=255""
- build binutils 2.17 to get libbfd 2.17 and matching libiberty
##../binutils-2.17/configure --disable-shared --disable-nls --disable-werror##
(this requires automake, autoconf, bison, flex, etc. to be installed)
- get an FB setup to compile the new fbc binary (usually the latest development version, or at least the previous release)
- ensure the FB setup will link the new compiler against the libbfd.a 2.17 built before, e.g. by copying the libbfd.a into the FB setup's lib/ dir, or by using -p c:/path/to/libbfd217/ when linking the new fbc
- config.mk:
%%ENABLE_STANDALONE := YesPlease
ENABLE_FBBFD := 217
FBLFLAGS := -p c:/path/to/libbfd217/
%%
- copy in the modified libc.a (e.g. from the previous FB release, or use DJGPP's libc.a and modify it)
- copy in the libbfd.a 2.17 (and libiberty.a) too
- regenerate & check the manifest:
##contrib/manifest/update.sh dos##
- package:
##""contrib/manifest/package.sh dos FreeBASIC-x.xx.x-dos zip""##
- exactly like the ""FreeBASIC-x.xx.x-dos"" release
- config.mk:
%%ENABLE_FBBFD := 217
FBLFLAGS := -p c:/path/to/libbfd217/
%%
- copy in the modified libc.a into lib/freebas/
- regenerate & check the manifest:
##contrib/manifest/update.sh djgpp##
- package:
##contrib/manifest/package.sh djgpp fbcxxxxb zip##


Revision [16308]

Edited on 2012-08-19 04:41:51 by DkLwikki [New section for static glibc build]
Additions:
- config.mk:
- config.mk:
- config.mk:
- config.mk:
- fbc binaries created by the musl-fbc setup currently have a problem compiling float constants, causing test suite failures; until the issue is found and fixed, it does not seem like a good idea to use fbc binaries linked against musl libc.
- config.mk:
{{fbdoc item="subsect" value="staticglibc-fbc (native -> staticglibc cross)"}}
- Note that this all was built on ""OpenSUSE"" 12.1 i686 with gcc 4.6.1 and glibc 2.14.1
- libbfd 2.17
##../binutils-2.17/configure --disable-nls --disable-shared --disable-werror##
##make CFLAGS=-O2##
(doesn't need to complete, only libiberty/libbfd is needed)
copy libbfd.a, libiberty.a into lib/linux/
- libffi
##./configure --disable-shared##
##make CFLAGS=-O2##
copy libffi.a into lib/linux/
copy libffi's LICENSE file to doc/libffi-license.txt
- CUnit
##./configure --disable-shared##
copy libcunit.a into lib/linux/
- binutils
##../binutils-2.22/configure --disable-nls --disable-shared##
##make CFLAGS=-O2##
copy as/ar/ld/gprof into bin/linux/
- gcc
##""BOOT_CFLAGS=-O2 CFLAGS=-O2 ../gcc-4.7.1/configure --disable-bootstrap --enable-languages=c,c++ --disable-nls""##
copy libgcc.a, libgcc_eh.a, libgcov.a, crtbegin.o, crtend.o, ""libsupc++.a"" into lib/linux/
- glibc
##CFLAGS=-O2 ../glibc-2.14.1/configure --without-cvs --prefix=/opt/glibc##
make
copy into lib/linux/:
crt1.o, crti.o, crtn.o
libc.a, libpthread.a, libdl.a, libm.a
- ncurses
##../ncurses-5.9/configure --without-debug --without-profile --without-cxx --without-cxx-binding --without-ada --without-manpages --without-progs --without-tests --without-pkg-config --without-shared --without-libtool --with-termlib --without-gpm --without-dlsym --without-sysmouse --enable-termcap --without-develop --enable-const --prefix=/usr##
copy libncurses.a and libtinfo.a into lib/linux/
- config.mk:
FBLFLAGS := -p /path/to/libbfd217
##contrib/manifest/update.sh staticglibc-fbc##
##""contrib/manifest/package.sh staticglibc-fbc staticglibc-fbc-x.xx.x targz""##
{{fbdoc item="subsect" value="FreeBASIC-x.xx.x-linux-staticbin"}}
- exact same as FreeBASIC-x.xx.x-linux, except that the fbc binary is built using the staticglibc-fbc setup
- config.mk:
%%FBC := /path/to/staticglibc-fbc/fbc-new
##""contrib/manifest/package.sh linux FreeBASIC-x.xx.x-linux-staticbin targz""##
- config.mk:
- exactly like the ""FreeBASIC-x.xx.x-dos"" release
- config.mk:
Deletions:
- build the new FB release with something like the following config.mk:
- build the new FB release with something like the following config.mk:
- setup a config.mk like this:
- build FB with a config.mk like this:
- fbc binaries created by the musl-fbc setup currently have a problem compiling float constants, causing test suite failures; until the issue is found and fixed, normally linked fbc binaries must be used.
- build the new FB release with something like the following config.mk:
- build the new FB release with something like the following config.mk:
- exactly like the ""FreeBASIC-x.xx.x-dos"" release, but build with a config.mk like:


Revision [16305]

Edited on 2012-08-18 13:10:14 by DkLwikki [New section for linux build with normally linked fbc]
Additions:
{{fbdoc item="subsect" value="FreeBASIC-x.xx.x-linux-musl with fbc linked against musllibc"}}
{{fbdoc item="subsect" value="FreeBASIC-x.xx.x-linux with fbc linked against musllibc"}}
{{fbdoc item="subsect" value="FreeBASIC-x.xx.x-linux with normally linked fbc"}}
- fbc binaries created by the musl-fbc setup currently have a problem compiling float constants, causing test suite failures; until the issue is found and fixed, normally linked fbc binaries must be used.
- ensure the FB setup will link the new compiler against the libbfd.a 2.17 built before, e.g. by copying the libbfd.a into the FB setup's lib/ dir, or by using -p /path/to/libbfd217/ when linking the new fbc
FBLFLAGS := -p /path/to/libbfd217/
Deletions:
{{fbdoc item="subsect" value="FreeBASIC-x.xx.x-linux-musl"}}
{{fbdoc item="subsect" value="FreeBASIC-x.xx.x-linux"}}


Revision [16303]

Edited on 2012-08-17 17:49:43 by DkLwikki [Update for libffi]
Additions:
- build libffi.a
##../libffi-3.0.11/configure --disable-shared --prefix=C:/TDM-GCC##
##make install##
- copy in libffi.a into lib/win32/ too
- copy libffi's LICENSE file to doc/libffi-license.txt
- build libffi.a
##../libffi-3.0.11/configure --disable-shared --prefix=C:/MinGW##
##make install##
Deletions:
- build libffi
- build libffi


Revision [16302]

Edited on 2012-08-17 17:24:35 by DkLwikki [Formatting fixes]
Additions:
- TDM-GCC vs. ""MinGW.org"": TDM-GCC has smaller libgcc binaries than ""MinGW.org"", resulting in smaller FB programs. The difference is (presumably) due to TDM-GCC being configured for SJLJ exception rather than DW2. Since FB doesn't support exceptions yet, the exception handling method of the GCC toolchain doesn't really matter for plain FB programs; this may be different when third-party libraries are involved though. In programs using the GCC support libraries from the ""MinGW.org"" toolchain you can observe huge .eh_frame sections via "##objdump -h##". The presence of libgcc_eh is related to that aswell (TDM-GCC doesn't have it, but ""MinGW.org"" does and in fact it must be linked in there to satisfy dependencies).
- get the TDM-GCC/MSYS setup, plus ""DirectX"" headers for gfxlib2
- copy ""GoRC.exe"" (e.g. from previous FB release) into bin/win32/
- all the ""Win32"" API import libraries from the w32api package, renamed from *.a to *.dll.a
##""contrib/manifest/package.sh win32 FreeBASIC-x.xx.x-win32 zip""##
- get the ""MinGW.org""/MSYS setup, plus ""DirectX"" headers for gfxlib2
Building binaries that work on most of the available GNU/Linux distributions is hard because even though they are often similar in general, they differ differ in detail just as often. The most common problem is mismatching glibc versions, i.e. the fbc binary is run on a system with older glibc than the one it was built on, and an "glibc too old" error is encountered. The ncurses library is not always exactly the same either, as shown by the "`ospeed' has different size, consider re-linking" warnings when running fbc. That's why the Linux releases have usually been built in some GNU/Linux system old enough to let the fbc binary work on Debian 4 and 5, the current supported Ubuntu versions (especially LTSs), Fedora and ""OpenSUSE"".
libc & co (including crt{1,i,n}.o) are easy to build from the musl sources, but properly compiling GCC to get libgcc, ""libsupc++"" and crtbegin.o/crtend.o requires some experience. Luckily there is a script to create a musl libc GCC cross-compiling toolchains available at [[https://github.com/GregorR/musl-cross]].
- FB rtlib (without X11/gpm/""OpenGL"" support)
##""contrib/manifest/package.sh linux-musl FreeBASIC-x.xx.x-linux-musl targz""##
- Get the ""FreeBASIC-x.xx.x-linux-musl"" release first
##""contrib/manifest/package.sh linux FreeBASIC-x.xx.x-linux targz""##
- Use 'msconfig' to add ""PerVMFiles=255"" to the ""[386Enh]"" section of ""SYSTEM.INI""
- Edit setting in ""C:\WINDOWS\system32\CONFIG.NT"": ""files=255""
##""contrib/manifest/package.sh dos FreeBASIC-x.xx.x-dos zip""##
- exactly like the ""FreeBASIC-x.xx.x-dos"" release, but build with a config.mk like:
- Get ""MySQL"", libcurl, libaspell, libpcre
Then copy the error list from errors.wakka into ""doc/manual/cache/CompilerErrMsg.wakka"", and update the online wiki too.
##""./samps extract @PageIndex.txt""##
Deletions:
- TDM-GCC vs. MinGW.org: TDM-GCC has smaller libgcc binaries than MinGW.org, resulting in smaller FB programs. The difference is (presumably) due to TDM-GCC being configured for SJLJ exception rather than DW2. Since FB doesn't support exceptions yet, the exception handling method of the GCC toolchain doesn't really matter for plain FB programs; this may be different when third-party libraries are involved though. In programs using the GCC support libraries from the MinGW.org toolchain you can observe huge .eh_frame sections via "##objdump -h##". The presence of libgcc_eh is related to that aswell (TDM-GCC doesn't have it, but MinGW.org does and in fact it must be linked in there to satisfy dependencies).
- get the TDM-GCC/MSYS setup, plus DirectX headers for gfxlib2
- copy GoRC.exe (e.g. from previous FB release) into bin/win32/
- all the Win32 API import libraries from the w32api package, renamed from *.a to *.dll.a
##contrib/manifest/package.sh win32 FreeBASIC-x.xx.x-win32 zip##
- get the MinGW.org/MSYS setup, plus DirectX headers for gfxlib2
Building binaries that work on most of the available GNU/Linux distributions is hard because even though they are often similar in general, they differ differ in detail just as often. The most common problem is mismatching glibc versions, i.e. the fbc binary is run on a system with older glibc than the one it was built on, and an "glibc too old" error is encountered. The ncurses library is not always exactly the same either, as shown by the "`ospeed' has different size, consider re-linking" warnings when running fbc. That's why the Linux releases have usually been built in some GNU/Linux system old enough to let the fbc binary work on Debian 4 and 5, the current supported Ubuntu versions (especially LTSs), Fedora and OpenSUSE.
libc & co (including crt{1,i,n}.o) are easy to build from the musl sources, but properly compiling GCC to get libgcc, libsupc++ and crtbegin.o/crtend.o requires some experience. Luckily there is a script to create a musl libc GCC cross-compiling toolchains available at [[https://github.com/GregorR/musl-cross]].
- FB rtlib (without X11/gpm/OpenGL support)
##contrib/manifest/package.sh linux-musl FreeBASIC-x.xx.x-linux-musl targz##
- Get the FreeBASIC-x.xx.x-linux-musl release first
##contrib/manifest/package.sh linux FreeBASIC-x.xx.x-linux targz##
- Use 'msconfig' to add PerVMFiles=255 to the [386Enh] section of SYSTEM.INI
- Edit setting in C:\WINDOWS\system32\CONFIG.NT: files=255
##contrib/manifest/package.sh dos FreeBASIC-x.xx.x-dos zip##
- exactly like the FreeBASIC-x.xx.x-dos release, but build with a config.mk like:
- Get MySQL, libcurl, libaspell, libpcre
Then copy the error list from errors.wakka into doc/manual/cache/CompilerErrMsg.wakka, and update the online wiki too.
##./samps extract @PageIndex.txt##


Revision [16301]

Edited on 2012-08-17 17:17:08 by DkLwikki [Formatting fixes]
Additions:
- libgcc.a, ""libsupc++.a"", crtbegin.o, crtend.o
- lib{gcc,gcc_eh,""supc++""}, crt{begin,end}.o from GCC, built against musl
Deletions:
- libgcc.a, libsupc++.a, crtbegin.o, crtend.o
- lib{gcc,gcc_eh,supc++}, crt{begin,end}.o from GCC, built against musl


Revision [16297]

Edited on 2012-08-17 15:10:33 by DkLwikki [New page for notes on how to make FB releases]
Additions:
{{fbdoc item="back" value="DevToc|FreeBASIC Developer Information"}}
{{fbdoc item="back" value="DocToc|Table of Contents"}}


Revision [16296]

The oldest known version of this page was created on 2012-08-17 15:09:54 by DkLwikki [New page for notes on how to make FB releases]
Valid XHTML :: Valid CSS: :: Powered by WikkaWiki



sf.net phatcode