I'm playing around with patches in Buildroot (version 2017.02), but when I override the package sources in local.mk:
PACKAGENAME_OVERRIDE_SRCDIR = /...path_to_local_checkout
I see that the Buildroot patches are not applied for this package.
They are applied only if the package is not overriden in local.mk.
Is this expected behavior?
Notes:
I didn't find the answer to my question in the Buildroot manual:
https://buildroot.org/downloads/manual/manual.html#patch-apply-order
The package I'm testing is the Linux kernel, but I guess it's unrelated.
I put my patches in the global patch dir
board/company_name/common/patches/...
Yes, this is expected behavior. If you use <pkg>_OVERRIDE_SRCDIR, then the source tree for the package is available locally, so you should apply the patches to your source tree. Buildroot cannot know which version of the package you're using, and therefore the patches it has in package/<pkg> may not apply, which is why the behavior is as you've seen that patches are not applied to overridden packages.
Essentially, the flow for a regular package is: download -> extract -> patch -> configure -> build -> install.
The flow for an overridden package is: rsync -> configure -> build -> install.
This behavior is documented in the current version of the documentation:
When Buildroot finds that for a given package, an <pkg>_OVERRIDE_SRCDIR has been defined, it will no longer attempt to download, extract and patch the package. Instead, it will directly use the source code available in the specified directory and make clean will not touch this directory. This allows to point Buildroot to your own directories, that can be managed by Git, Subversion, or any other version control system. To achieve this, Buildroot will use rsync to copy the source code of the component from the specified <pkg>_OVERRIDE_SRCDIR to output/build/-custom/.
I would just go and apply all the Buildroot patches to the package and keep them git tracked.
Most of them (TODO all?) seem to be cherry picked from future versions on master, so I would just cherry pick them as much as possible.
It would be beautiful if Buildroot itself could use git submodules for every package and keep it under their fork: github.com/buildroot/ but there are likely technical limitations to this such as Git shallow cloning annoyances.
Related
Asking to see what the appropriate workaround is for building individual go packages from the go/std library when working on a github repo fork. The issue encountered is summarized by the following error when building for example the src/go/parser package.
parser.go 21:2 use of internal package go/internal/typeparams is not allowed
Of course the project import paths all reference GOROOT library paths
usr/local/go
And I am typically working on projects from my own directory where my go path is set.
/Users/andewx/github/go/src/github.com/andewx/my_go_extension_project
The crux of the issue is that the clone/fork project uses standard library import paths and I would like to be able to work on my repo from my own GOPATH. But internal packages can't be imported in this case because the import directives will always point to my GOROOT.
The only two options I can think of is:
Extending my personal go project by initiating the repo inside of my /usr/local/go and working on the packages from there.
Changing my GOROOT to point to my current project and including current go binary go fmt and toolchains in my project
Ideally I can just leave everything as far as directory structure is concerned as is and I can redirect the standard import path for go standard library to my current project for this project only...
Any ideas from the community for solution #3 is what I'm looking for.
Extending my personal go project by initiating the repo inside of my /usr/local/go and working on the packages from there.
Changing my GOROOT to point to my current project and including current go binary go fmt and toolchains in my project
If you are trying to work on the go compiler and extend it I actually found that changing your GOROOT to point to your workspace and then copying over the binaries and tools you need as a suitable fix and it doesn't create any additional issues.
Export your environment variable export GOROOT="/my/go/project"
Find out where your go tools are located with go env GOTOOLDIR copy this directory structure into your project folder.
Copy go bin cp /usr/local/bin/* ${GOROOT}"/bin" copy in your go binary
Copy toolscp /usr/local/go/pkg/tool/linux_amd64/* ${GOROOT}/pkg/tool/linux_amd64
Now your project should be able to run the copied binaries with your project directories temporarily set as the GOROOT.
I am trying to compile some open source libraries in MinGW+MSYS. During the configure phase, I kept seeing some 3rd party libraries are missing.
For now, my solution is to download the source of the missing libraries and follow the GNU build process to compile and install them into my MinGW environment.
Is there any package management system for MinGW+MSYS to install packages easily? Just like apt-get.
I tried the mingw-get for the missing package. But it reports the error below.
mingw-get is the (closest equivalent to apt-get) package manager for MinGW and MSYS. However, it can only manage packages which are actually available for MinGW and/or MSYS, (either because a MinGW developer has built and packaged them, or a member of the MinGW user community has contributed them).
Arbitrarily guessing what packages may be available, and even what their correct package names may be, is unlikely to be productive. Run mingw-get in its GUI mode, (if it's properly installed, just running mingw-get without arguments should start it in this mode), to see a list of packages which are actually available; if you don't see any likely candidates for what you are looking for, then it doesn't (yet) exist. In that case, you will need to either find a non-MinGW alternative build, or build it yourself, from source. (If you choose the latter option, and your build is successful, then you may wish to consider contributing it to MinGW.org).
This works for me as a "package manager".
Install MSYS2. It comes with a package manager called pacman.
I followed this install wget tutorial,
After I ran this
./configure --with-ssl=openssl
It ran so many checks, what exactly it did? Did it change anything in my system?
If it does, then, is it safer or more fault prove to use the package management tool like MacPort or such so that such 'configure' will not be done manually like this or does those tool do the same thing in order to make wget work?
Sorry, I am pretty noob on shell commands.
Thanks
It's part of the build process. The configure script collects information about your system and build options into a local file, nothing more.
Typically, this script is created by autoconf and is used to figure out whether the prerequisites for a build are properly installed, etc. It will collect this into a file config.save and also possibly generate a makefile and/or other build infrastructure in order for make to be able to concentrate on compiling and linking the source files.
Neither configure nor make should be expected to change anything outside of the directory tree where you run them.
Conventionally, make install will copy the final build artefacts into place so that other parts of your system can find them and use them.
See also http://www.edwardrosten.com/code/autoconf/
A prepackaged binary will already have been built on a remote system before it was packaged (though there are package managers which allow or require you to build locally; Gentoo Linux famously uses the latter approach) and is often the simplest way to get a tool if you don't have special requirements, such as building with a specific SSL version, or disabling SSL entirely, or getting a bleeding edge version before anybody has packaged it.
I have to use different compiler (gcc) from one packaged with centos. It is also gcc, just repacked newer version which has been installed with different path.
I am using mock for build, which has in its basic setup
config_opts['chroot_setup_cmd'] = 'groupinstall build'
Group build in my case contains CentOS stock gcc. I cannot change anything in mock environment.
Is there a way how to delete gcc package before build actually proceed?
The problem is that some programs compiled by my repacked gcc tends to use system /usr/include/ instead of correct include's from repacked gcc, so I am looking for a way how to localize problem.
You can try to use the instructions provided by Fedora to complete this task, they talk about doing a build when the rpm you need to install isn't part of a repo.
If that doesn't work I would look at setting up a custom environment, or asking your admin to do so if you cannot change it as you state in your question. The configuration files are stored under /etc/mock/*.cfg. I would suggest copying one of these that matches your needs and naming it something unique. Then you need to add an additional repo line (either local or remote depending on where your custom copy of GCC lives).
This will configure the environment to pick up that version of GCC if it really is just marked as a newer release. In the event there is some unique naming convention or it's not being picked up for some reason you should look at modifying the chroot_setup_cmd to simply install all the build packages. When I review a
yum groupinstall buildsys-build
I see a list of all the associated packages. You'll obviously want to check 'build'. You can then modify your config_opts['chroot_setup_cmd'] to use 'install', instead of 'groupinstall', where you can then install all the associated build packages, as well as your custom GCC.
If that still doesn't work, you can always copy the build packages to your own personal repo where GCC lives, ensure that's the only one available to pull from, configure the repo so it supports the 'build' group, and then build the package. While not extremely helpful due to age, the Mock docs have some useful information for configuring your environment with local repos.
I'm trying to install something with the following command:
make world
It takes a long time, and usually it ends up with an error saying that I'm missing some kind of package. I found out what the package is, install it, and run the thing again, only to find out after a long time that I'm missing another package. Is there a way to find out all the packages I need to install without having to go through this process?
This is generally what the configure script does. If the project you're building doesn't have one, you should write one.
The best way to deal with dependencies is with a package manager such as:
On Ubuntu: apt-get
On Red Hat / Fedora: yum
On Mac OS X: port
On Windows: cygwin
If you install software with a package manager, it will automatically fetch, download, and install any dependencies as necessary. These package managers support a huge number of popular open source projects, but not all projects are supported. Some of these package managers support creating custom package repositories, which allows them to be used for dependency management in-house, as well.
Unfortunately, there is no general way to get all the library dependencies of a Makefile (short of grepping for "lib", ".so", and "-l" which may give you spurious results); however, if you are installing an open source project, chances are that it is supported by a package manager on your system.