I was following the instruction on this page https://www.math.uwaterloo.ca/tsp/concorde/DOC/README.html, where I used the following command
./configure --with-qsopt=SOME_DIR --enable-pthreads
to enable pthreads as shown in the ./configure --help manu on my Ubuntu 20.04.
I also checked the INCLUDE/config.h file that
/* Define if you want to use posix threads */
#define CC_POSIXTHREADS 1
the macro is set after doing the configure command.
However, when I run the compiled code ./TSP/concorde on a TSP instance, the runtime is still the same. And I use htop to see the CPU usage. Only one core is used.
Is there any other things I need to do to enable multi-threading? Thanks for the help!
Related
I am new to qemu. I have the following question. I needed to emulate some new instructions using qemu. Basically I modify the target-i386 to something like target-i386-extended. Add tcg/i386-extended.Since qemu supports many architectures, normally i configure using the following command
./configure --target-list=i386-softmmu --enable-debug
make
make install
Are there any changes that needs to be done if we want to emulate new target? If so, what needs to be the command in the above case?
Looking forward to your reply.
./configure --help
shows option for customized building and compiling.
Standard options:
--help print this message
--prefix=PREFIX install in PREFIX [/usr/local]
--interp-prefix=PREFIX where to find shared libraries,
etc.use %M for cpu name [/usr/gnemul/qemu-%M]
--target-list=LIST set target list (default: build everything)
by default it will build for all your targets like x86,x86_64,arm.powerpc etc
./configure --target-list=i386-softmmu
this will build only for x86 target i.e you ll get qemu-i386 binary only.
if you want for arm target only then use
./configure --target-list=arm-softmmu which will build and compile only for arm.
qemu-system-arm binaries you ll get which you can use for emulating ARM board
I wanted to compile botan library version Botan-1.10.1 on linux for 64-bit mode.
Please tell me steps for compiling the botan on linux in 64-bit mode.
The build instructions for botan can be found here:
http://botan.randombit.net/manual/building.html
Basically, you need to run ./configure. In theory, it should make an educated guess as to the CPU type, so if you are building on a 64bit machine, it should automagically configure itself accordingly. If not, you can help it along by specifiying the correct cpu type with
./configure --cpu
Botan automatically guesses your OS and architecture. However, you can set that manually if you want(For e.g., if you are targeting multiple platforms or using a script to run configure.py). To build for 64-bit you need to specify --cpu=x86_64:
python configure.py --cpu=x86_64
To disable certain os features use: --without-os-features=.
To specify compiler use: --cc= or --cc-bin=path/to/compiler
To get a single .h and .cpp file use: --amalgamation
To disable certain modules use: --disable-modules=aes, block
Further build instructions for botan can be found here or use --help to get more info:
http://botan.randombit.net/manual/building.html
Due to hardware issues I want to install a new Kernel following this guide.
But I am a little confused with this line:
$ sudo time fakeroot make-kpkg -j4 --initrd kernel_image kernel_headers
where I have to set the number of cores my processor has.
I have an Intel i7-720QM which is a quad core. But I guess because of hyperthreading (at least I think my processor is hyperthreaded) I have to use the option -j8 instead of -j4. is this okay?
Note: In the comments of the guide above, this question was also asked, and one answer wos to use -j4 the other was to go with -j8 so i am confused now.
kind regards
The -j4 argument to make-kpkg (which gets passed to the underlying make) only sets the number of parallel compilation processes during the kernel build (and has no influence on the produced kernel packages). And it does not matter that much (so -j4 or -j8 won't make a very big difference in term of build time).
I often pass only -j3 to leave a core available to other processes (e.g. my web surfing or my email reading during the kernel compilation).
Also, some part of make-kpkg is intrinsically serial and cannot be parallelized (some tar running....)
And you could even remove the -j4 (same as -j1): kernel build time will increase, but your machine will be more responsive during it
PS: you don't need both sudo and fakeroot if the parent directory (..) is user-writable. It will contain the produced .deb packages. BTW, you could edit your /etc/kernel-package.conf.
I am compiling a message passing program using openmpi with mpicxx on a Linux desktop. My makefile does the following:
mpicxx -c readinp.cpp
mpicxx -o exp_fit driver.cpp readinp.o
at which point i get the following error:
/usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../x86_64-suse-linux/bin/ld: cannot find -lnuma
My questions are:
what is -lnuma? what is using it? how should i go about linking to it?
Thanks Jonathan Dursi!
On Ubuntu, the package name is libnuma-dev.
apt-get install libnuma-dev
The build script can't find the numa library - NUMA (Non Uniform Memory Access). The -l option tells the linker to link the library, but your system ether doesn't have the right one installed or your search path for the linker is incomplete/wrong.
Try querying your package-manager (apt or rpm) for a package libnuma.
OpenMPI, and I think mpich2, uses libnuma (`a simple programming interface to the NUMA (Non Uniform Memory Access) policy supported by the Linux kernel') for memory affinity -- to ensure that the memory for a particular MPI task stays close to the core that the task is running on, as vs. being kept in cache on another socket entirely. This is important for performance on multicore nodes.
You may need to use YaST to install libnuma-devel if your linker can't find the library.
I got the same error working on a remote server, which had the NUMA library installed. In particular, the file /usr/lib64/libnuma.so.1 existed. It appears that the linker only looked for the file under the name libnuma.so. Creating the symlink
ln -s /usr/lib64/libnuma.so.1 /usr/lib64/libnuma.so
as described here might have worked, but in my case I did not have permission to create files in /usr/lib64. I got around this by creating the symlink in some other location of which I have write permission:
ln -s /usr/lib64/libnuma.so.1 /some/path/libnuma.so
and then add this path to the compilation flags. In your case this would be
mpicxx -L/some/path -o exp_fit driver.cpp readinp.o
In my case of a larger build process (compiling fftw), I added the path to the LDFLAGS environment variable,
export LDFLAGS="${LDFLAGS} -L/some/path"
which fixed the issue.
I 've cross compiled a Linux Kernel (for ARM on i686 - using Cross-LFS).
Now I'm trying to boot this Kernel using QEMU.
$ qemu-system-arm -m 128 -kernel /mnt/clfs-dec4/boot/clfskernel-2.6.38.2 --nographic -M versatilepb
Then, it shows this line and waits for infinite time !!
Uncompressing Linux... done, booting the kernel.
So, I want to debug the kernel, so that I can study what exactly is happening.
I'm new to these kernel builds, Can someone please help me to debug my custom built kernel as it is not even showing anything after that statement. Is there any possibility of the kernel being broken? ( I dont think so, b'se it didnot give any error while compiling )
And my aim is to generate a custom build very minimal Linux OS. Any suggestions regarding any tool-chains etc which would be easy & flexible depending on my requirements like drivers etc.,
ThankYou
You can use GDB to debug your kernel with QEMU you can use -s -S options. If you want a simple and reliable toolchain, you can use ELDK from DENX (http://www.denx.de/wiki/DULG/ELDK).
You can install it like this (It's not the last version, but you got the idea):
wget http://ftp.denx.de/pub/eldk/4.2/arm-linux-x86/iso/arm-2008-11-24.iso
sudo mkdir -p /mnt/cdrom (if necessary)
sudo mount -o loop arm-2008-11-24.iso /mnt/cdrom
/mnt/cdrom/install -d $HOME/EMBEDDED_TOOLS/ELDK/
The command above should install the toolchain under $HOLE/EMBEDDED_TOOLS/ELDK (modify it if you need)
echo "export PATH=$PATH:$HOME/EMBEDDED_TOOLS/ELDK/ELDK42/usr/bin" >> $HOME/.bashrc
You can then see the version of your ARM toolchain like this:
arm-linux-gcc -v
You can test a hello_world.c program like this:
arm-linux-gcc hello_world.c -o hello_world
And you type: file hello_wrold to see the target architecture of the binary, it should be something like this:
hello_wrold: ELF 32-bit LSB executable, ARM, version 1 (SYSV)
Now if you want to compile a production kernel, you need to optimize it (i suggest using busybox) and if you want just one for testing now, try this steps:
Create a script to set your chain tool set_toolchain.sh:
#! /usr/bin/sh
PATH=$PATH:$HOME/EMBEDDED_TOOLS/ELDK/ELDK42/usr/bin
ARCH=arm
CROSS_COMPILE=arm-linux-gnueabi-
export PATH ARCH CROSS_COMPILE
And run your script (source ./set_toolchain.sh)
Download a linux kernel and unzip it (Let's assume 2.6.x, it's an old kernel, but there are a lot of chances that it work without compilation errors).
Inside your unzipped kernel:
cd ~/linux-2.6.29/arch/arm/configs
make versatile_defconfig
Here we use versatile chip, you may need to use make menuconfig to modify the option OABI and set it to ARM EABI, this option is under Kernel features menu
After all this steps, you can compile you kernel:
make
if you want verbose compilation make v=1
After this you got your kernel under arch/arm/boot/zImage.
Hope this help.
Regards.
I would suggest to build your kernel by activating the option in the section Kernel hacking of your configuration file.
Then you may use kdb or kgdb which is easier to use but requires another machine running gdb.
`
You can also connect Qemu and GDB. Qemu has the -s and -S options that run a GDB server and allow you to connect to it via TCP to localhost:1234. Then you can load your kernel image (the unzipped one) in GDB and see how far your kernel boots.