The linux kernel project tries to collect all the useful patches in a single place, they are not hard to locate if you need one, with gcc I can't locate a resource, online or offline, with the official releases or with the development snapshots, that actually provides patches that can be useful for who wants to rebuild gcc from sources .
There is a way I can see a list of all the patches available for gcc ?
You can find it on the official website. Don't know if this could help you rebuild gcc though.
https://gcc.gnu.org/ml/gcc-patches/
https://gcc.gnu.org/snapshots.html
Related
I'm trying to find a copy of stdckdint.h, which I assume should be in the gcc 11.2 collection, but a search fails to locate it in the downloaded source tarball.
Is it not public yet, or do I have to unpack/build something to get the include files?
Gcc11 does not provide stdckdint.h. The documentation of gcc does not mentions it, neither in release notes nor in C standard support page. As the documentation states, C2x support in GCC is incomplete and experimental. The release notes for gcc11 lists implemented C2x features.
In the meantime, you can use my implementation available from https://gitlab.com/Kamcuk/ckd/-/tree/master .
The original question, Packaging Go application for Debian, was asked over three years ago, when Go was statically linking executables.
Now, with the new Go 1.5 Release, whose release note says,
Changes to the linker enable distributing Go packages as shared libraries to link into Go programs, and building Go packages into archives or shared libraries that may be linked into or loaded by C programs
I headed to Debian GoPackaging wiki, but only to find out that it has not been updated to Go 1.5 yet, maybe the wiki is not maintained, or maybe not, but,
I just want to know, if I want to package a tool that depends on nothing but the official Go packages, how should I take advantage of the shared libraries, instead of building my app into a humongous statically linked executable?
I know the official answer may take some time, but I can wait.
Thanks to Braiam's answer, I moved a bit further.
I followed the blog to the step head -100 debian/**/*, but my output is completely different from the blog's. Mine is just the following. Anyone knows why and how to fix?
$ head -100 debian/**/*
3.0 (quilt)
I tried to run gbp buildpackage --git-pbuilder but bumped into error:
gbp:info: Building with (cowbuilder) for sid
Base directory /var/cache/pbuilder/base.cow does not exist
gbp:error: 'git-pbuilder' failed: it exited with 1
I checked and verified that I already have cowbuilder & pbuilder installed:
ii cowbuilder amd64 pbuilder running on cowdancer
ii pbuilder all personal package builder for Debian packages
What's wrong? This pbuilder thing is new to me as I build Debian/Ubuntu Package with Docker.
The easiest method is to use dh-make-golang and verify/correct the autogenerated files. Otherwise you must follow Debian Packaging Guide and create debian/* directory and editing the control and rules file to match the examples.
Of course we all know building GCC version >= 4.1.x requires the supplementary packages MPFR, GMP and MPC to be present.
There's a few ways to handle these GCC dependencies:
1) Download and build each supporting package separately and then tell make where the binaries are located during GCC build time.
2) Download each supporting package, untar and move the source into your GCC build directory and make will automatically build each of the packages when needed.
(Executing the gcc-src/contrib/download_prerequisites script does the same as option 2)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Is there an advantage to either method? Does pre-compiling the binaries provide something I'm missing by taking the "easy route" and just dumping the package's source into my GCC build directory and letting make figure it out?
I've seen it done more frequently in various build scripts by pre-compiling each package to a binary, and then telling make where they are located during gcc compilation. Is this the "preferred" way to do it? Why?
To add context, I'm mainly building cross-compilers targeting various ARM platforms.
For most use cases I believe that option 2 is just as good as option 1. However, I can see a few situations in which one would want to do it manually.
A package maintainer wants to build separately as they want separate packages for mpfr et al.
Someone who wants to pass different configure arguments/CFLAGS to each of the packages.
A GCC developer who wants to keep their source and build trees small as they don't make any changes to MPFR/GMP/etc.
I haven't done too much work with the (rather ugly) GCC build system, but I haven't seen any obvious differences in how the binaries are built.
I'm not the biggest authority on this though, so YMMV; I may be wrong.
It seems there were/are efforts to do this, but most of the resources I've seen so far are either outdated (with dead links) or have little to no information to actually build a small working sample (that, for example relies on boost program_options to build an executable).
Also, when using ExternalProject_Add, how does one resolve dependencies inside of Boost?
I'm basically looking to use Boost easily from within CMake with little to no manual configuration.
Try Hunter package manager:
hunter_add_package(Boost COMPONENTS regex system filesystem)
find_package(Boost CONFIG REQUIRED regex system filesystem)
target_link_libraries(foo PUBLIC Boost::regex Boost::system Boost::filesystem)
Note that usage of imported Boost targets is importand for relocatable packages
Wiki
Boost package
Relocation notes
Examples
Small
Big
Currently (August 2017) Boost libraries do not provide CMake support nor are they build using CMake. Boost has its own build system called b2. In July 2017 the Boost steering committee announced that all boost libraries should be moved to use CMake. This affects users and developers, i.e., CMake will be used internally to build the libraries and externally it will provide CMake config files.
As the build system question triggered heated discussions in the past years and there are strong feeling from part of the community against b2 and CMake, the outcome of this decision is unclear (first release with CMake, will all old libraries support CMake, even a split of the Boost community).
Original Answer from 2015
You can consider the effort to introduce CMake as a first-class citizen to boost as dead. See the mailing list thread about the topic.
If you don't want to use third party tools like hunter's package manager, check the most current verion of the boost library you want to use. Maybe you are lucky and it provides some CMakeLists.txt files you can use.
The most recent work on 'a boost which uses CMake and makes boost use ideal for CMake users' is here:
https://github.com/boost-cmake/boost-cmake
It requires cmake master branch (until CMake 3.0.0 is released soon) and I haven't attempted to build it in a while. Someone in the boost community would have to push forward with transitioning boost to CMake. The boost community might still be busy with transitioning to git.
I am working on CentOS 6 machines, which has very old GCC/GlibC version. I want to build the whole glibc, binutils, gcc toolchain with latest or at least very recent versions in order to use c++11 support in latest gcc, and ld.gold in recent binutils, and possibly improvements in recent glibc.
I want to put the whole toolchain in some separate directory, and not to influence any existing system files. I also want to build gcc with --sys-root so that when using the gcc, I don't need to specify -I/some/directory/include and -L/some/directory/lib or whatever other parameters. Also the generated executable will automatically use the new ld-linux-xxxxx program loader which will automatically find the new libc.so.
Anyone knows if there exists some tutorial on this task?
The compiler is very dependent on glibc, altough you manage to build the compiler either in a chrooted system or equivalent, you will need to build also all libraries needed with the program you will build with this new compiler.
The best you can do is use a fresh new system (vm or whatever) or upgrade your existing one
You can download the latest toolchain from Openembedded or Yocto.
And here you don't have to do any package installation to your current system.
Just download the toolchain, source the environment and thats it you are ready to check the c++11 support.
The location to download the toolchain:
http://downloads.yoctoproject.org/releases/yocto/yocto-1.7/toolchain/ (Just select the architecture either 32bit or 64 bit based on your machine support)
If you need the latest toolchain, you'd better migrate to Fedora.
If you can't/won't, the best bet is to get the pieces as source RPMs for CentOS and Fedora, unpack them and fix up the CentOS by pilfering the sources and patches from Fedora, take care it doesn't overrule the system packages, correct versions and fix to install elsewhere (don't mess up your system too much! /usr/local comes to mind). The pieces are at least binutils, gcc.
I do not knwo Why you need this ? If this is needed that to compile for another computer, I would suggest using a virtual machine running the same OS as target. much more easier !!