I want to build v4l2-ctl tool in buildroot (from 2019.02.4) linux system.
But v4l2-ctl is legacy (has been deprecated and replaced by a single option to build all the libv4l utilities).
I try to setup BR2_PACKAGE_LIBV4L_UTILS, to get v4l2-ctl, but after make, in linux system there is no v4l2-clt tool.
Do not understand: where is v4l2-ctl? How to build v4l2-ctl?
I got it:
It is need to rebuild buildroot's packet again:
make libv4l-dirclean
then
make libv4l-rebuild
then
make
and v4l2-ctl will appear in target usr/bin directory
Related
I have a Python project which I would like to distribute as a Pex or shiv self-contained Python-executable package, in the spirit of the Python Packaging Guide, "Depending on a pre-installed Python" section. My project is structured in the spirit of PEP518, and it has a pyproject.toml file. My project also includes a few libraries not in the Python Standard Library, so I use pipenv to manage those.
How to I build the pex package using a backend which I can specify in the [build-backend] of my pyproject.toml file?
The documentation for pex and shiv show how to build self-contained packages from the command line, or via setuptools.py, but not using the PEP518 structure and pyproject.toml. At least, not as far as I have been able to discover. (And, by "self-contained", I mean all Python language packages, but I am happy to use an existing Python 3 interpreter on the destination system.)
Note that of the three executable packages listed in the Packaging Guide, zipapps does not seem like a fit for me. It doesn't give me a way to manage my external libraries.
Update: some specific invocations, per request.
I currently use build as my build frontend. I use setuptools as my build backend. My pyproject.toml file currently reads,
[build-system]
requires = ["setuptools"]
build-backend = "setuptools.build_meta"
I currently build a wheel via this shell command:
(MyPipenvVenv) % python -m build
…[many lines of output elided]…
Successfully built MyProject-0.0.6a0.tar.gz and MyProject-0.0.6a0-py3-none-any.whl
I can build a self-contained app (which relies on the system's Python interpreter) using these pipenv and shiv commands:
(MyPipenvVenv) % pipenv requirements > requirements.txt
(MyPipenvVenv) % shiv --console-script myapp -o app/myappfile.pyz -r requirements.txt .
Installing build dependencies: started
Installing build dependencies: finished with status 'done'
Getting requirements to build wheel: started
Getting requirements to build wheel: finished with status 'done'
Installing backend dependencies: started
Installing backend dependencies: finished with status 'done'
Preparing metadata (pyproject.toml): started
Preparing metadata (pyproject.toml): finished with status 'done'
Collecting click==8.1.3
Using cached click-8.1.3-py3-none-any.whl (96 kB)
Collecting pip==22.1.2
Using cached pip-22.1.2-py3-none-any.whl (2.1 MB)
Collecting setuptools==62.5.0
Using cached setuptools-62.5.0-py3-none-any.whl (1.2 MB)
Collecting shiv==1.0.1
Downloading shiv-1.0.1-py2.py3-none-any.whl (19 kB)
Building wheels for collected packages: MyProject
Building wheel for MyProject (pyproject.toml): started
Building wheel for MyProject (pyproject.toml): finished with status 'done'
Created wheel for MyProject: filename=MyProject-0.0.6a0-py3-none-any.whl size=5317 sha256=bbcc…cf
Stored in directory: /private/var/folders/…/pip-ephem-wheel-cache-eak1xqjp/wheels/…cc1d
Successfully built MyProject
Installing collected packages: MyProject, setuptools, pip, click, shiv
Successfully installed MyProject-0.0.6a0 click-8.1.3 pip-22.1.2 setuptools-62.5.0 shiv-1.0.1
What I want is to give the command to the PEP 517 front-end, have the pyproject.toml specify that the resulting build work be done by shiv, and point to whatever configuration shiv needs. I want the result be a self-contained app file app/myappfile.pyz. e.g.
(MyPipenvVenv) % python -m build
…[many lines of output elided]…
Successfully built MyProject
Installing collected packages: MyProject, setuptools, pip, click, shiv
Successfully installed MyProject-0.0.6a0 click-8.1.3 pip-22.1.2 setuptools-62.5.0 shiv-1.0.1
My pyproject.toml file would be something like,
[build-system]
requires = ["shiv"]
build-backend = "shiv.build_something_something"
As far as I know, shiv is not a "PEP 517 build back-end" (neither is pex), so it is not possible to write something like the following in pyproject.toml:
[build-system]
requires = ["shiv"]
build-backend = "shiv.build_something_something"
As discussed there, the PEP 517 interface is targeted at the generation of source distributions (sdist) and wheels only.
From my point of view, I consider tools like shiv and pex that generate zipapps to be (at least) one layer above. And when working at this level, it does not matter whether or not sdists and/or wheels are generated via the PEP 517 interface, in other words it does not matter whether or not pyproject.toml files are involved. I assume that shiv and pex either consume wheels and sdists that are already available (maybe downloaded from PyPI) or they delegate the "build" step to a 3rd party tool (maybe pip, maybe build), I do not know and it does not matter.
From my point of view, the input that makes the most sense to get a zipapp as output is some kind of "lock file", and not a (PEP 517) pyproject.toml file. Zipapps are basically one whole "virtual environment" in a single file. It means that the Python interpreter is fixed, and each dependency (direct or indirect) is fixed. This is best described with a lock file.
The requirements.txt files while not strictly lock files, are probably what is the closest thing with enough availability and support in the Python packaging ecosystem. And as far as I know the requirements.txt files are the only "lock file"-ish format that tools like shiv and pex accept as input.
So my recommendation for you would be to focus on requirements.txt files to provide as input to pex or shiv. As you are already doing.
In the Python packaging ecosystem...
It looks like PDM has a real lock file format and already has support for generating zipapps via a plugin pdm-packer.
Poetry also has a lock-file format and they are somewhat looking into supporting zipapps as well
There are discussions and work going on towards a standardized lock file format. But it is difficult work, and will probably still take some time to reach a conclusion.
I'm building a lightweight distribution for the Raspberry Pi (dedicated to mpd player).
As I'd like to add an filesystem extender (like raspbian) I need resize2fs to be build.
But even if in menuconfig I select target -> FS tools-> e2fsprogs -> resize2fs, this binary is not built.
Can't figure why!
Have you got any explanation?
If you enable resize2fs after having already built e2fsprogs, then you need to reconfigure e2fsprogs:
make menuconfig, enable resize2fs
make e2fsprogs-dirclean
make
This is because resize2fs is not a Buildroot package, it is an optional component of the e2fsprogs package. And since Buildroot does not track changes to the package configuration, it does not know it has to rebuild the package in this case.
To better understand, read the Buildroot manual section 8.3. Understanding how to rebuild packages. Section 8.2. Understanding when a full rebuild is necessary would is very useful too.
I tried:
git checkout 2018.05
make qemu_x86_64_defconfig
make BR2_JLEVEL="$(nproc)" "$(pwd)/output/images/rootfs.ext2"
but it still built the kernel at:
output/images/bzImage
I want to do that because:
I'm making a setup where you can pick between multiple different root filesystems, so I will need to build Linux kernel manually for the other root filesystems, and would not like Buildroot to waste time building it again
I don't want to wait 5 seconds every time for Buildroot to parse 100 Makefile configs when I want to rebuild the kernel :-)
I'm using LINUX_OVERRIDE_SRCDIR with Linux on a submodule, so Linux the headers should match the source I will use for the build.
Is there a fundamental dependency between, say, glibc and the kernel build, or is it just a weird use case never catered for?
Ah, I noticed now that any loadable kernel modules need to go on the rootfs and would require a kernel build, and that build does have some .ko in the rootfs.
Well, just disable BR2_LINUX_KERNEL and Buildroot will no longer build the kernel.
I'm trying to debug an open source package, called libprotoident in Eclipse, Kepler version, within Debian. As it has the Makefile, I choose to make an empty Makefile project, and then add all the sources into the workspace. So after that the source compiled and run successfully as in the command line using the Makefile.
As it has 4 apps you can use, I choose to run lpi_protoident package in the run configuration window, as the following image shown.
So the Program ran successfully. Now I'm trying to debug it but it generates the following error.
How can I solve this error and debug the Project?
The file you are trying to debug is most likely a shell script created by automake that acts as a wrapper around the real executable, which has been built in a hidden directory.
Instead of telling Eclipse that tools/protoident/lpi_protoident is your application, try using tools/protoident/.libs/lpi_protoident instead.
General Answer about the error you are getting
What not in executable format: File format not reconized error means is that lpi_protoident is not an executable on the platform you are working on.
Are you sure that is an executable you can run (E.g. from the command line)?
There is also the small chance that the GDB you are using is somehow incompatible with the executable, but that is less likely.
Building libprotoident from source
(Assuming you are trying to build https://github.com/wanduow/libprotoident)
You are trying to build an automake project. The normal way to do that is by configuring to create Makefile, you shouldn't be making your own makefile. Please refer to the README in the project, but the key parts you need to do are:
Installation
After having installed the required libraries, running the following series of commands should install libprotoident
./bootstrap.sh (only if you've cloned the source from GitHub)
./configure
make
make install
By default, libprotoident installs to /usr/local - this can be changed
by appending the --prefix= option to ./configure.
The libprotoident tools are built by default - this can be changed by
using the
--with-tools=no option with ./configure.
I am writing a component that goes into the yocto build, but during development I don't want to build the entire image. I want to checkout my component(in its own GIT repo), build it using the cross-compiler used for building the entire tree, and test that before checking in(devtest) and building the entire filesystem for system test. I have not found a way to do that.
If I understand your question correctly, what you want to do is to build the SDK?
Run
bitbake - c populate_sdk <image-name>
that'll give you a nice SDK in a tarball. Then you execute that tarball to install it on you desired location.
In the shell where you're developing your application, you source the environment-.... file in the installed location. Now everything is configured to crosscompile, as long as you're using eg CC instead of directly calling gcc.