I am trying to enable packaging for my C project. I know that i can use the AC_CANONICAL_BUILD macro to get #build_cpu#. But the problem is, that the debian control file wants amd64 instead of x86_64. Is there a simple way to convert these uname outputs to the format that dpkg wants or do I need to check every possible architecture in an if statement?
It is not entirely clear what you are trying to do, and why you would need this mapping. My impression is that you might probably be trying to do something wrong.
For packages that are portable, you should simply use one of the wildcards for the Architecture field. For example any, or if for whatever reason it's kernel specific, then something like linux-any or kfreebsd-any.
If you really need to map between GNU triplets or components and dpkg architectures you can always use the dpkg-architecture command (please check its man page), but again, this usually smells like the wrong way of going about this, and more so from an upstream point of view, which should be distribution neutral.
Maybe you can use sed in your autotools file to do these conversions? For example,
echo `uname -m | sed s/aarch64/arm64/ | sed s/x86_64/amd64/`
will output arm64 on an ARM aarch64 system and amd64 on an x86_64 system.
I happen to be using this at the moment to automate installation of Visual Studio Code Server for multiple architectures like this:
export VERSION=3.12.0 \
&& export ARCH=`uname -m | sed s/aarch64/arm64/ | sed s/x86_64/amd64/` \
&& curl -fOL https://github.com/cdr/code-server/releases/download/v$VERSION/code-server_"$VERSION"_"$ARCH".deb \
&& dpkg -i code-server_"$VERSION"_"$ARCH".deb \
&& rm code-server_"$VERSION"_"$ARCH".deb
Related
I am building an rpm where I need to check the OS version. If it is rhel5 or rhel6, then it'll work, else it'll stop.
Please advice how can I make it.
Thanks & Regards.
You can use https://unix.stackexchange.com/questions/9296/how-can-i-specify-os-conditional-build-requirements-in-an-rpm-spec-file
however this only decide what go inside of package in buildtime. And you can still install el6 package on el5 and vice versa.
So if you want to do decide that during actual installation, the you need to parse /etc/os-release (IIRC exist only in el7+) or /etc/redhat-release.
Another alternate Use to use the uname command and parse Information
Save time execute the following:
uname -r | cut -d '.' -f6
This is valid in RHEL 6 and 7.
There's %{rhel} you can check
$ rpmbuild --eval %{rhel}
7
You can run cat /etc/issue and parse as necessary
I would like to read the actual source code which the linux commands are written with. I've gained some experience using them and now I think it's time to interact with my machine at a deeper level.
I've found some commands here http://directory.fsf.org/wiki/GNU. Unfortunately I wasn't able to find basic commands such as 'ls' which seems to me easy enough to begin.
How exactly do I read the source code of the simple shell commands like 'ls'?
I'm running on Ubuntu 12.04
All these basic commands are part of the coreutils package.
You can find all information you need here:
http://www.gnu.org/software/coreutils/
If you want to download the latest source, you should use git:
git clone git://git.sv.gnu.org/coreutils
To install git on your Ubuntu machine, you should use apt-get (git is not included in the standard Ubuntu installation):
sudo apt-get install git
Truth to be told, here you can find specific source for the ls command:
http://git.savannah.gnu.org/cgit/coreutils.git/tree/src/ls.c
Only 4984 code lines for a command 'easy enough' as ls... are you still interested in reading it?? Good luck! :D
Direct links to source for some popular programs in coreutils:
cat (767 lines)
chmod (570 lines)
cp (2912 lines)
cut (831 lines)
date (570 lines)
df (1718 lines)
du (1112 lines)
echo (272 lines)
head (1070 lines)
hostname (116 lines)
kill (312 lines)
ln (651 lines)
ls (4954 lines)
md5sum (878 lines)
mkdir (306 lines)
mv (512 lines)
nice (220 lines)
pwd (394 lines)
rm (356 lines)
rmdir (252 lines)
shred (1325 lines)
tail (2301 lines)
tee (220 lines)
touch (437 lines)
wc (801 lines)
whoami (91 lines)
Full list here.
ls is part of coreutils. You can get it with git :
git clone git://git.sv.gnu.org/coreutils
You'll find coreutils listed with other packages (scroll to bottom) on this page.
Actually more sane sources are provided by http://suckless.org look at their sbase repository:
git clone git://git.suckless.org/sbase
They are clearer, smarter, simpler and suckless, eg ls.c has just 369 LOC
After that it will be easier to understand more complicated GNU code.
CoreUtils referred to in other posts does NOT show the real implementation of most of the functionality which I think you seek. In most cases it provides front-ends for the actual functions that retrieve the data, which can be found here:
It is build upon Gnulib with the actual source code in the lib-subdirectory
You can have it on github using the command
git clone https://github.com/coreutils/coreutils.git
You can find all the source codes in the src folder.
You need to have git installed.
Things have changed since 2012, ls source code has now 5309 lines
BSD distributions are actually a nice way of reading the source code, by using their repositories, since it is all packed into one place, and you can view how historically the source code has evolved, or changed. So why not use BSD repos , such as NetBSD or OpenBSD for this task.
cd ~ && apt-get source coreutils && ls -d coreutils*
You should be able to use a command like this on ubuntu to gather the source for a package, you can omit sudo assuming your downloading to a location you own.
I'm automating RPM package building with rpmbuild. The files end up in the architecture subdirectory under RPMS.
Question - how do I retrieve, from a shell script, the architecture name of the host that RPM is using? It's not the same as arch command.
It looks like
rpm --eval '%{_arch}'
does the trick:
$ rpm --eval '%{_arch}'
x86_64
$ rpm --target 'SPARC64' --eval '%{_arch}'
sparc64
There's /usr/lib/rpm/rpmrc that translates known OS-level architecture names into canonical RPM architecture names. The following shell script does the job for me:
ARCH=`arch`
# OS-level architecture name, like 'i686'
ARCH=`cat /usr/lib/rpm/rpmrc | grep "buildarchtranslate: $ARCH" | cut -c21-`
# returns the translate line as "arch-from: arch-to"
ARCH=${ARCH/#*: /}
# strips the prefix up to colon and following space, returns arch-to.
# Assumes just one space after colon. If not, more regex magic is needed.
You're doing it wrong. Redefine %_build_name_fmt in ~/.rpmmacros.
I am trying to catalog uses of the RDTSC instruction on my computer. My first thought was to run my /lib folder through objdump and search for RDTSC
$ for f in ls /lib/*; do echo "*** $f ***" && objdump -d $f | grep -n rdtsc; done > ~/tmp/out
I noticed that a lot of RDTSC is present in the ld.2.11.1.so file. I am pretty sure it has something to do with dynamic library linking, but I'm not sure. My real question is, how can I find the source code so I can see what the RDTSC instructions are for?
ld-2.11.1.so is the dynamic linker itself. Most of its sources live in glibc/elf directory. You may want to start here. Look for HP_TIMING* macros.
ld.so is part of the C library, which is typically Glibc or EGlibc, depending on the Linux distro.
Is there any efficient way (maybe by abusing the gcc preprocessor?) to get a set of stripped kernel sources where all code not needed according to .config is left out?
Well got some steps into a solution.
First, one can obtain the used compiler commands by
make KBUILD_VERBOSE=1 | tee build.log
grep '^ gcc' build.log
For now, I select only one gcc command line for further steps. For example the build of kernel/kmod.c, it looks like:
gcc <LIST OF MANY OPTIONS> -c -o kernel/kmod.o kernel/kmod.c
I now remove the option -c, -o ... and add -E, thus disabling compilation and writing preprocessor output to the screen. Further I add -fdirectives-only to prevent macro expansion and -undef to remove the GNU defined macro definitions. -nostdinc to remove the standard c headers is already added by the kernel makefile.
Now includes are still included and thus expanded on the preprocessor output. Thus I pipe the input file through grep removing them: grep -v '#include' kernel/kmod.c. Now only one include is left: autoconf.h is included by the Makefile's command line. This is great as it actually defines the macros used by #ifdef CONFIG_... to select the active kernel code.
The only thing left is to filter out the preprocessor comments and the remaining #defines from autoconf.h by means of grep -v '^#'.
The whole pipe looks like:
grep -v '#include' kernel/kmod.c | gcc -E -fdirectives-only -undef <ORIGINAL KERNEL BUILD GCC OPTIONS WITHOUT -c AND -o ...> - |grep -v '^#'
and the result is a filtered version of kernel/kmod.c containing the code that is actually build into kmod.o.
Questions remain: How to do that for the whole source tree? Are there files that are actually build but never used and stripped at linking?
Kernel Minimization Script :
A project inspired by this question and providing an easy answer...
It contains a Python script that generate a minimized sources code during build time. The new minimized source tree will only contain used sources. (project page)
Info :
The script is tested working with the kernel v4.14.x, however building the kernel one more time from those generated minimized sources require to copy make files and Kconfig files etc... at least we could easily isolate only used source for investigations and development
Usage :
cd /kernel/sources
make
wget https://github.com/Hitachi-India-Pvt-Ltd-RD/minimization/raw/master/minimize.py
export PATH=$PATH:`pwd`
make C=2 CHECK=minimize.py CF="-mindir ../path-to-minimized-source-tree/"
Note & Reminder :
If we are building within and against the targeted machine, we also have the make localmodconfig command that shrink the current config file with only the currently used modules, if used before "Minimization" it will generate further more stripped sources
Compile everything and use atime to find out which files were not used. It might not be very accurate but it's probably worth a try.