I am pretty new to buildroot and I wish to add more than 1 post-build scripts, as the documentation says:
3.3.1. Customizing the generated target filesystem
In the Buildroot configuration, you can specify the paths to one or more post-build scripts. These scripts are called in the given order, after Buildroot builds all the selected software, but before the rootfs images are assembled. The BR2_ROOTFS_POST_BUILD_SCRIPT allows you to specify the location of your post-build scripts
http://buildroot.uclibc.org/downloads/manual/manual.html#rootfs-custom
How can I specify more than one value in a buildroot setting?
See: buildroot Makefile, especially lines 782-784.
The string is passed to a shell's for loop. So a space separator should be used. Each script gets a TARGET_DIR parameter.
In fact, I am running Armadeus 5.2 which only includes Buildroot 2012.02, which does not allow more than 1 post build script. Buildroot 2013.02 does.
Current docs have made it clearer now:
To enable this feature, specify a space-separated list of post-build scripts in config option BR2_ROOTFS_POST_BUILD_SCRIPT
So space separated as Artless deduced from the source.
Related
For a small project I'm working on, I would like to create a “relocatable build” of PostgreSQL, similar to the binaries here. The idea is that you have PostgreSQL and all required libraries packaged so that you can just unpack it in any directory on any machine and it will run. I want the resulting build of Postgres to work on virtually any Linux machine it finds itself on.
I've made it so far as determining which libaries I need to build:
My understanding is that I should be getting the source code for these libraries (and their dependencies) and compiling them statically.
As things stand currently, my build script is quite barebones and obviously produces an install that is linked against whatever distribution it was run on:
./configure \
--prefix="${outputDir}" \
--with-uuid="ossp"
I'm wondering if anyone could outline what steps I must take to get the relocatable build that I'm after. My hunch right now is that I'm looking for guidance on what environment variables I would need to set and/or parameters I'd need to provide to my build in order to end up with a fully relocatable build of Postgres.
Please note: I don't normally work with C/C++ although I have several years of ./configure, make and doing builds for other much higher level ecosystems under my belt. I'm well aware that distribution-specific releases of Postgres are widely available, to speak nothing of the official docker container. Please take the approach that I'm pursuing a concept in the spirit of research or exploration. I'm looking for a precise solution, not a fast one.
This answer is for Linux; this will work differently on different operating systems.
You can create a “relocatable build” of PostgreSQL if you build it with the appropriate “run path”. The documentation gives you these hints:
The method to set the shared library search path varies between platforms, but the most widely-used method is to set the environment variable LD_LIBRARY_PATH [...]
On some systems it might be preferable to set the environment variable LD_RUN_PATH before building.
The manual for ld tells you:
If -rpath is not used when linking an ELF executable, the contents > of the environment variable LD_RUN_PATH will be used if it is defined.
It also tells you this about the run path:
The tokens $ORIGIN and $LIB can appear in these search directories. They will be replaced by the full path to
the directory containing the program or shared object in the case of $ORIGIN and either lib - for 32-bit
binaries - or lib64 - for 64-bit binaries - in the case of $LIB.
See also this useful answer.
So the sequence of steps would be:
./configure --disable-rpath [other options]
export LD_RUN_PATH='$ORIGIN/../lib'
make
make install
Then you package the PostgreSQL binaries in the bin subdirectory and the shared libraries plus all required libraries (you can find them with ldd) in the lib subdirectory. The libraries will then be looked up relative to the binaries.
I have a simple CMake project with CTest and CPack. It uses the Lua C API to load and execute an script file called script.lua.
This script will be in different location when built vs when installed/packed, it's location would be:
[build] : ${CMAKE_CURRENT_SOURCE_DIR}/src/scripts
[install]: ../scripts (relative to app which is in bin directory)
What I'm trying to achieve here is to have install step regenerate configure_file then rebuild using new configure_file and only then proceed to do the normal install step and of course revert the configure_file back to it's original state afterwards.
Any help regarding this issue is appreciated.
My understanding is that CMake's configure_file command has its full effect during the execution of the cmake program. It has no representation in generated makefiles, or whatever other build system components cmake generates. Thus, if you want to configure a file differently for installation than for pre-installation testing,
You would need to perform completely separate builds (starting with executing cmake) for the two cases, and
You would need to use some attribute of the cmake command line or execution environment to convey the wanted information, such as using a -D option to define a CMake variable on the command line.
I advise you not to pursue this route. Aside from being overcomplicated, it's also poor form to install a different build of the software than is tested.
You have a variety of alternatives that could serve better. Among those are
Give the program itself the ability to accept a custom location for the Lua script. That is, make it recognize a command-line argument or environment variable that serves this purpose. Make use of that during pre-installation testing.
If indeed the program is using a relative path to locate the script at runtime, then just (have CMake) put a copy of the script at the appropriate location in the build tree, so that the program will find it normally during testing.
I have all compiled binaries for target machine. I want to create a binary package - say .ipk, .rpm - for target machine. As this suggested to clone poky, which will have bitbake within it. But, as this document says, we can directly use bitbake without poky, however, it not mentioned anywhere that we need poky as well as bitbake to build a custom package. But of course poky is required if we have to compile source code and create binaries.
If I don't need to compile any source code at all, does I need to have Poky?
Is it possible to build a package with only bitbake?
First, Poky is a reference distribution that contains primarily bitbake and openembedded-core.
Yes, you need oe-core to build packages as the logic to build packages is part of oe-core, not bitbake.
I have a project whose source includes symbolic links to other source trees (notably, the CppUTest framework). I need to build a debian package out of my project, but dpkg-source will not follow the symbolic links.
Digging further, I believe this is because the default behavior for tar is not to dereference symbolic links unless explicitly told to (with -h).
I was unable to find a way to pass this extra option to tar when building the debian source tarball.
So what am I doing wrong here? Is it possible to build a debian source tarball whose origin includes symbolic links? If so, how?
As read in this thread.. http://ubuntuforums.org/showpost.php?p=9752860&postcount=3
They can be included in the package just like normal files.
The details depend on the way you're doing the packaging, but using something like the following in debian/rules's `install' target should work:
ln -s /usr/share/whatever/file/you/want $(CURDIR)/debian/<pkgname>/usr/whatever/place/you/want/the/link
Everything inside debian/ will end up inside the .deb, including the symlinks you put there.
I have a set of Debian packaging scripts and I would like the version number of the package to be incremented each time it is built. (i.e. debian_revision as specified in the Debian Policy Manual) That is, the first build should be PACKAGE-1.0-0, then PACKAGE-1.0-0, and so on (where 1.0 is the upstream_version). Is there an easy way to specify this "extra" version number without having to create a new entry in the changelog?
I'm looking to have this automatically done by the Makefile for the project whenever a particular target (i.e. deb is built)
dh_* scripts read debian/changelog to build a changes file and set the versions, among other things. You should not change the version without editing the changelog, but if your problem is changes made manually you can make a script that invokes
dch -i
or if your problem is changes made at the debian/changelog, you can make a bash script to change the version automatically.