[[TOC]]
(C) Copyright 2013-2024 Oliver Niebuhr
Very basic Scripts to
- Clone (Download) the Source Code of multiple Libraries and Frameworks from their Git Repositories
- Build these Libraries and Frameworks
May they be useful to you in one way or another.
The Scripts are written to compliment each other. Example: Locally cloned Repositories will be found under
/home/[User Name]/Dev/GitRepos/[Name-Of-The-Repository]
The Build Scripts will search for the Source Code of these Libraries in this Directory.
These Scripts will only get updated if I run into Issues myself! Bug Reports to fix or update a specific Compiler Flag will be ignored, if it interferes with my use case or it is not compatible with the Version of a Library and or Compiler I am using!
As I am switching between different programming Languages and Frameworks, not frequently used Scripts can be outdated and Bug Reports will probably stay open for many Months.
The best options to get something fixed are:
- Clone the Repository -> Fix the Bug -> Create a Pull Request -> Wait for me to Merge your Pull Request
- Fork the Repository -> Fix the Bug -> Enjoy the Error Free Script
All Scripts were created and successfully tested under the following Linux and Compiler Versions:
- openSUSE Tumbleweed, KDE Plasma 6, Stable Repository, x86_64
- GNU GCC/G++ Compiler, 11.1.0 up to 14.2.0, x86, x86_64
- Zig specific Scripts: I will update to the latest Nightly Zig Version every 1 to 2 weeks. If necessary more often.
- This can change after Zig reaches API stability in Version 1.0.0
Other Linux Distributions are untested by me.
Other Compiler Variants like Clang-GCC are untested and therefore not supported by me!
Older Versions should work, if they are not too old. What too old means, has not been fully tested. The oldest GCC Version I tested to build some of the older Versions of Libraries like ICU and OpenSSL with, was GCC 8.1.0 back in 2019.
You usually need to remove or modify some Compiler Flags for newer and older Kernel, Compiler, Linker and Library Versions.
The Content in this Repository is Dual-Licensed under "The Unlicense" (Public Domain) OR under the "CC0-1.0 Universal License" (Public Domain with Fallback Mechanism).
If you live in a Jurisdiction like Germany or anywhere else outside the USA which
- does not acknowledge Public Domain at all OR
- does only acknowledge some Parts of Public Domain
and therefore "The Unlicense" is deemed illegal or invalid, choose the CC0-1.0 Universal License with the Fallback Mechanism.
Simplified Explanation: Both Licenses allow you to do with these Scripts whatever you want without mentioning my Name ('without giving me Credit' also known as 'No Attribution').
The Fallback Mechanism is made for Jurisdictions like Germany etc., to allow me (the 'Licensor') to give away all my Rights as far as the local Laws allow me to do so. So that you (the 'Licensee') can do whatever you want with whatever I have published under these License(s).
The huge Amount of different Jurisdictions and Copyright Laws are a horrible Mess and need these specific Statements unfortunately.
Also: Repositories got removed or hidden if they do not contain a License Document.
And as always the usual necessary Disclaimer: I AM NOT A LAWYER AND THIS IS NOT LEGAL ADVICE. IF YOU NEED LEGAL ADVICE, CONSULT A LICENSED ATTORNEY.
Here you can find the different License Texts: The Unlicense (Public Domain):
- THE_UNLICENSE.txt - In this Repo: THE_UNLICENSE.txt
- The Unlicense: Original at the Authors Website: https://unlicense.org/
- The Unlicense: At SPDX.org: https://spdx.org/licenses/Unlicense.html
CC0-1.0 Universal (Public Domain with Fallback Mechanism):
- CC0-1.0.txt - In this Repo: CC0-1.0.txt
- CC0-1.0: Full Text at CreativeCommons.org: https://creativecommons.org/publicdomain/zero/1.0/legalcode.txt
- CC0-1.0: Human-Readable Summary - English at CreativeCommons.org: https://creativecommons.org/publicdomain/zero/1.0/
- CC0-1.0: Human-Readable Summary - German Translation at CreativeCommons.org: https://creativecommons.org/publicdomain/zero/1.0/deed.de
- CC0-1.0: At SDPX.org: https://spdx.org/licenses/CC0-1.0.html
The full Contribution Rules can be found in the
Send me a Message. I will try to reply within 96 hours. Sometimes sooner, sometimes later.
- For Bug Reports: Click on the Button "New Issue" and use the "Bug Report" Form to create a new Issue marked as Bug Report: https://github.com/MeerMusik/LinuxScripts/issues/
- For Questions: Click on the Button "New Issue" and use the "Question" Form to create a new Issue marked as Question: https://github.com/MeerMusik/LinuxScripts/issues/
- eMail: Bug Report. MailTo Link: Opens your eMail Program
- eMail: Question. MailTo Link: Opens your eMail Program
- Contact me on Mastodon: https://mastodon.social/@MeerMusik
- Contact me on Twitter (now called 'X'): https://x.com/MeerMusik
- Contact Form on my personal Website (German): https://oliverniebuhr.de/kontakt
Remember that Tweets are always public! Everyone can read what you write! If you need to send Personal Infos, send me a Direct Message!
Where necessary, I added a Section called 'WARNING:' at the upper Part of the Build Scripts, which list in example Flags which are not compatible or not fully supported. It also contains other Hints about removed or disabled Features where necessary.
Some Security = Hardening Flags forced whenever possible:
- Fortify Source
- Position-Independent-Code or Position-Independent-Executable
- Stack Protector
- Stack-Clash Protector
- Read-Only Relocation
- Immediate Binding
- No Executable Stack
- Spectre and Meltdown Mitigation
- As I have a AMD CPU, some Mitigations will lead to link Errors. Therefore I have to lower the Level of Security for some Mitigations. Blame Intel. And AMD.
- Feel free to raise the Flags for those Mitigations to a higher Value, if they work on your System
Hash-Style=GNU is set by all Scripts:
- I have added '-Wl,--hash-style=gnu' - this leads to shorter build and link times. If your App or Library does not run on Linux Versions because your Binutils Version is too old, set the Value to:
- -Wl,--hash-style=both - this is the Default Value, which will write the old slow SYSV Sections and the newer GNU Sections into the Header of the File. Alternatively set it to write only the old Value: -Wl,--hash-style=sysv
- It seems this was introduced in Binutils 2.17.50.0.2 Beta. It became usable after some Bugs were fixed. Probably any Version from Binutils 2.17.50.0.6 Beta and later should work. Take this with a huge Container of Salt! Do your own testing to be on the relatively safe side!
- I guess anything released beginning from January 2007 should be safe. But again: Do your homework to be on the safe side.
- You also need the correct GLIBC Version. Probably at least Version 2.5 but I have not researched this Topic thoroughly. You are once more on your own with this!
- Link to the Binutils Changelog on the spinics.net Mailing List
Static Builds: For Compatibility Reasons, Static Builds are the usual weird Linux Mix:
- Executables are: ELF 32-Bit or 64-Bit LSB PIE executables, dynamically linked
- Static Libraries are Static Libraries
Should the GLIBC Library at some point step forward in to the year 2000 and embrace the future, I will change the Compiler and Linker Flags to turn Static Binaries into real Static Binaries. But only if I will be still alive in the year 6666.
Status: Unused. Kept in case it turned out to be a Alternative to OpenSSL.
Infos:
- Documentation: https://botan.randombit.net/handbook/building.html
- Download Source Code directly: https://github.com/randombit/botan/releases
Get the Source Code:
- Clone Git Repository to local Drive: NewBotanGit.sh
- Update local Git Repository: UpdateBotanGit.sh
Build it:
- X86_64, Dynamic, Debug and Release: Botanx64.sh
- X86_64, Static, Debug and Release: Botanx64Static.sh
- X86, Dynamic, Debug and Release: Botanx86.sh
- X86, Static, Debug and Release: Botanx86Static.sh
Status: Currently not used
Building from Source is optional.
If you use the Build Scripts as they are and want to run the LLDB Test Suite: You need to install Python and Swig.
- swig Website: http://www.swig.org/
- Install Python through your Distribution's Package Manager, if it is not already pre-installed.
Infos:
- If you do not have a specific use case to build a customized Compiler, you should use the prebuilt Binaries provided by your Distribution. It is much less hassle, you will save a lot of time and keep your frustation Level to a minimum.
- If there are no prebuilt Binaries for your Distribution: Try your Luck at the official LLVM Download Website: https://releases.llvm.org/
- General Documentation: https://llvm.org/docs/
- How to build Clang / LLVM: Basic starting Guide: https://llvm.org/docs/GettingStarted.html
Disabled Functionality:
- Colored Output: -DLLVM_ENABLE_TERMINFO='OFF'
Colored Output requires ncurses. As different Distributions deploy different Versions of ncurses, it often leads to linking errors. If you want colored output, enable that Flag and install or download ncurses. Make sure to install the correct Version! I have never used ncurses, therefore I can not tell you which Version you need!
Get the Source Code:
- Clone Git Repository to local Drive: NewLLVMGit.sh
- Update local Git Repository: UpdateLLVMGit.sh
Build it:
- X86_64, Debug: LLVMx64Debug.sh
- X86_64, Release: LLVMx64Release.sh
No X86 = 32-Bit only Scripts:
- I do not want to install 32-Bit Python from an unofficial Repository
- I could build the old 'lib32-python' from the AUR, but the Version is usually outdated and the Package Script has some Issues
- Also the Build and Config Script for Packages will break, if they do not keep getting updated. This is unavoidable
This Data are based on Version 13. Later Versions can take more Space and can take more time to compile!
Required Free Space during build time:
- Debug Build with Unit Tests: Circa 204.0 Gigabyte
- Release Build with Unit Tests: Circa 9.1 Gigabyte
Required Free Space for Installation:
- Debug Build: Circa 73.3 Gigabyte
- Release Build: Circa 3.5 Gigabyte
Build time: 16 Cores 32 Threads, 64 GB RAM, 32 GB fixed SWAPFILE (SATA SSD):
- Debug Build: Limited to 16 Parallel Link Jobs = Circa 34 Minutes plus running Unit Tests plus installing = Circa 41 Minutes total
- Release Build: Circa 21 Minutes plus running Unit Tests plus installing = circa 25 Minutes total
Status: Used when a Tool or Library supports it or has it set as a fixed Dependency.
I usually use the latest CMake Version provided by my Linux Distribution.
I build only from Source, when I need to test specific fixes or a new Feature.
Attention: By Default, You need an existing CMake and Ninja Installation to build CMake from Source! You can uncomment the Lines in the Script to use 'Make'. Do not forget to comment the CMake specific Parts - otherwise you will break the Scripts obviously!
Infos:
- Official Documentation: https://cmake.org/cmake/help/latest/
- Community Wiki: https://gitlab.kitware.com/cmake/community/-/wikis/home
Get the Source Code:
- Clone Git Repository to local Drive: NewCMakeGit.sh
- Update local Git Repository: UpdateCMakeGit.sh
Build it:
- X86_64, Dynamic, Release: CMakex64Release.sh
Status: Currently unused. If it is still needed, needs to be determined.
Infos:
- Documentation: http://site.icu-project.org/docs
- Download Source Archive or prebuilt Binaries directly: https://icu.unicode.org/download
Get the Source Code:
- Clone Git Repository to local Drive: NewICUGit.sh
- Update local Git Repository: UpdateICUGit.sh
You also need Git Large File Storage Extension
Need help setting up Git LFS? Follow the Section 'Detailed Instructions' -> 'Prerequisites: Git and Git LFS' at the ICU Project Site
Build it:
Build it - Cross-Compile Linux to Windows:
- X86_64, Debug and Release: ICUx64LinWin.sh
- X86, Debug and Release: ICUx86LinWin.sh
Cross-Compile Limitations:
Tests are disabled as WINE can not find the necessary Runtime Libraries. Maybe I can I find some Settings to make the tests work - long-term.
Status: Heavily recommended. I use it whenever possible
Infos:
- Documentation: https://ninja-build.org/manual.html
- Download Source Archive or prebuilt Binaries directly: https://github.com/ninja-build/ninja/releases
Get the Source Code:
- Clone Git Repository to local Drive: NewNinjaGit.sh
- Update local Git Repository: UpdateNinjaGit.sh
Build it:
- X86_64, Static, Release: Ninjax64Release.sh
Attention: You need Python installed for the Bootstrapping Script!
Status: Currently unused
Additional Infos:
- The Scripts build a Version which only supports DTLS 1.2 and TLS 1.2 and 1.3
- A lot of the Protocols, which I never intended to use, are disabled as well. Everything that is disabled by Default, is less pressure, to keep up with possible Security holes in OpenSSL. Simple as that.
Infos:
- Documentation: https://www.openssl.org/docs/
- Download Source Archive or prebuilt Binaries directly: https://www.openssl.org/source/
Get the Source Code:
- Clone Git Repository to local Drive: NewOpenSSLGit.sh
- Update local Git Repository: UpdateOpenSSLGit.sh
Build it:
- X86_64, Dynamic, Debug and Release: OpenSSLx64.sh
- X86_64, Static, Debug and Release: OpenSSLx64Static.sh
- X86, Dynamic, Debug and Release: OpenSSLx86.sh
- X86, Static, Debug and Release: OpenSSLx86Static.sh
Build it - Cross-Compile Linux to Windows:
- X86_64, Dynamic, Debug and Release: OpenSSLx64LinWin.sh
- X86_64, Static, Debug and Release: OpenSSLx64StaticLinWin.sh
- X86, Dynamic, Debug and Release: OpenSSLx86LinWin.sh
- X86, Static, Debug and Release: OpenSSLx86StaticLinWin.sh
Cross-Compile Limitations:
Tests are disabled as WINE can not find the necessary Runtime Libraries. Maybe I can I find some Settings to make the tests work - long-term.
Status: Delayed indefinitely. Project will potentially be killed off.
The Links to the Files have been removed while the Tool will be rewritten from Scratch in another Framework.
Info:
- My personal Website (German): https://oliverniebuhr.de
- FAQ on my Website (German): https://oliverniebuhr.de/
Get the Source Code:
- Clone Git Repository to local Drive: NewPiratesLittleHelper.sh
- Update local Git Repository: UpdatePiratesLittleHelper.sh
Build it: The real Build Scripts will be added when they are ready...
Build it: Cross-Compile Linux to Windows: The real Build Scripts will be added when they are ready...
Cross-Compile Limitations:
Unknown yet
Status: Hard Dependencies or recommended Libraries.
-
NASM - Netwide Assembler. For OpenSSL. Optional but highly recommended: Some Algorithms are massively slower without NASM enabled.
- Preferable way to get it: Install nasm through your trusty Package Manager
- Alternatively: Download the latest prebuilt Binaries: https://www.nasm.us/pub/nasm/releasebuilds/
- Version: Always the latest
-
Perl Programming Language
- Required as an Interpreter for all Projects using Perl Scripts
- Version: Always the latest. Unless I need an older Version because of in example Compatibility Issues
Perl comes preinstalled on many Linux Distributions. Open a Console or Shell and type
perl --version
to see which Version is installed on your Distribution.
If Perl is not found, install the prebuilt Binaries provided by your Distribution. Read the Instructions for the Package Manager of your Distribution on how to do that.
- Python 3.x Programming Language
- Required as an Interpreter for all Projects using Python Scripts
- Version: Always the latest. Unless I need an older Version because of in example Compatibility Issues
Python comes preinstalled on many Linux Distributions. Open a Console / Shell and type
python --version
to see which Version is installed on your Distribution.
If Python is not found, install the prebuilt Binaries provided by your Distribution. Read the Instructions for the Package Manager of your Distribution on how to do that.
I also published my Windows Scripts Dual-Licensed under "The Unlicense" (Public Domain) OR under the "CC0-1.0 Universal License" (Public Domain with Fallback Mechanism):
- WindowsScripts: Repository at GitHub