I recently do some study about executable compression. When compile the test.c C language source and compress it with UPX in Linux not windows. It is list in Terminal: UPX: test.so NotCompressibleException. The source code of test.c is:
int main(){
int i = 0;
printf("HelloWorld\n");
return 0;
}
What am I guessing is that the executable file is too simple to compress? Or
may be I missed something? If there is anyone know about this issue, Please tell
me the reason. If nobody tell me I have to read source code to find out the issue. Ah! reading source code burden.
There are several reasons to output a NotCompressibleException, but in your case it is simply because the size of your binary is too small. UPX cannot handle binaries under 40Kb.
The best way to workaround this problem is to compile your binary in static mode, in order to get a bigger executable file. So, just try: gcc -static -o mytest mytest.c and then upx -o mytest-upx mytest.
Related
I need to build a static library to create a binary. I am using ubuntu 15.04 and I need libdevmapper static library. I am sorry I couldn't be more clear as I have absolutely no clue how to do that. I installed libdevmapper-dev, it only installs .so not .la. Any pointers on how can I do it?
Thanks.
You might first want to take a look at this tutorial to get some idea about static libraries.
First you need to create your object code from your source file.
gcc -Wall -c test1.c test2.c
Then you need to use the ar command to generate the library file.
ar -cvq libtest.a test1.o test2.o
Hi team,
I have three files which I need to compile for testing, btw im using CentOS linux.
source_code.c
library.h
library.c
how do I put the library.h in the gcc library, so I can use it?
how do I compile the source_code.c to use that library?
Thank you very much.
This is basic knowledge of your tools, but you can do this:
#include "library.h" in the include section of the library.c code (at top of the file).
gcc source_code.c library.c in the linux terminal will link and compile both source_code.c and library.c. This will generate an executable named "a.out" (if there were no compilation problems). You can change its name, by adding the option -o name to the gcc command (gcc source_code.c library.c -o mycode will generate an executable named "mycode").
If you really need a library that will be used by a lot of other programs, you can look for "shared libraries", but I think that you are asking for a basic thing.
You dont need this library.h while building and executable (with gcc) as you should have specified the exact location of the library in the source file. All you need to do is gcc sourcefile1.c sourcefile2.c -o exename
i am trying to know the size of task_struct. thus i have downloaded the linux source code from the website and i have generated the head files via typing the command make headers_install into terminal in the source code file root directory.
#include<stdio.h>
#include<linux/sched.h>
int main()
{
printf("%d\n",sizeof(struct task_struct)).
return 0;
}
typing the command to the termial to compile and source code gcc -g -I *path/to/linux*-source/usr/include test.c -o test. However the terminal shows struct task_struct does not define stuff.
Could any guys to help me to figure it out? Really appreciated.
This struct is for kernel internal use only. It's definition is pretty long and largely varies depending on kernel configuration. So, the struct size also varies depending on kernel configuration, and you can't get it from user-space.
Unless, you extract kernel config, which is bad idea, as for me. The better one is to write a kernel module.
The Scenario
I am developing an application in C99 ANSI C that uses OpenMP and GMP. It's natural habitat will be a linux machine with plenty of cores, so there's basically no big trouble there, but for reasons I do not want to debate here, I have to develop under Cygwin on a 64 bit Windows machine.
When I use the 32 bit version of gcc, something, somewhere, goes horribly wrong and the application is about 60 times slower than a very crude single-threaded version, when it should in fact be faster by a factor that equals the number of CPU's. It makes it impossible to work with. I really don't know what is causing this; Anyway, I have decided to use the 64 bit version of MinGW instead, that'd be x86_64-w64-mingw32-gcc-4.5.3 and his friends, to be precise.
A side note: I am sure that the slowdown is not a flaw in my multithreading, the multithreaded application works correctly and faster on the linux machine.
The actual Problem
Setting up GMP was easy, it can be compiled from source without any trouble and then works like a charm. Compiling the following easy example with -fopenmp also works like a charm:
#include <gmp.h>
#include <omp.h>
int main() {
#pragma omp parallel
{
mpz_t t;
mpz_init(t);
mpz_set_si(t,omp_get_thread_num());
# pragma omp critical
{
gmp_printf("Hello From GMP'd Thread %Zd!\n",t);
fflush(stdout);
}
mpz_clear(t);
}
return 0;
}
However, executing it gives me
$ ./test
test.exe: error while loading shared libraries: ?:
cannot open shared object file: No such file or directory
I am aware of this question, but I would like to make this work without downloading any binaries other than those from an official Cygwin repository. Since my example compiled with the -fopenmp switch, I am convinced that this should also be very much possible.
Can someone help me with that? Thanks a bunch in advance.
I think that "error while loading shared libraries: ?:" means that cygwin does not know where to find libgmp-10.dll and/or libgomp-1.dll.
Both DLL are required according to Dependency Walker
Your program worked after I added the directory that contains both DLL to my PATH:
#$ x86_64-w64-mingw32-g++ -fopenmp -o w64test gmp_hello.c -lgmp
#$ file ./w64test.exe
./w64test.exe: PE32+ executable (console) x86-64, for MS Windows
#$ ./w64test.exe
/home/david/SO/hello_openmp/w64test.exe: error while loading shared
libraries: ?: cannot open shared object file: No such file or
directory
#$ ls /cygdrive/c/dev/cygwin/usr/x86_64-w64-mingw32/sys-root/mingw/bin/*mp*dll
/cygdrive/c/dev/cygwin/usr/x86_64-w64-mingw32/sys-root/mingw/bin/libgmp-10.dll
/cygdrive/c/dev/cygwin/usr/x86_64-w64-mingw32/sys-root/mingw/bin/libgomp-1.dll
#$ export PATH=$PATH:/cygdrive/c/dev/cygwin/usr/x86_64-w64-mingw32/sys-root/mingw/bin/
#$ ./w64test.exe
Hello From GMP'd Thread 1!
Hello From GMP'd Thread 0!
note
I compiled and installed gmp-5.0.5 with the following commands:
./configure --build=i686-pc-cygwin --host=x86_64-w64-mingw32 --prefix=/usr/x86_64-w64-mingw32/sys-root/mingw --enable-shared --disable-static
make -j 2
make check
make install
update
Your program also works with cygwin "GCC Release series 4 compiler".
#$ g++ -fopenmp -o cygtest gmp_hello.c -lgmp
#$ ./cygtest.exe
Hello From GMP'd Thread 1!
Hello From GMP'd Thread 0!
#$ g++ -v
Target: i686-pc-cygwin
Thread model: posix
gcc version 4.5.3 (GCC)
You might need to install the following packages:
libgmp-devel (Development library for GMP)
libgmp3 (Runtime library for GMP)
libgomp1 (GOMP shared runtime)
I am trying to debug a crash from one of my kernel module ; I am trying to get source code listing along with output of objdump but it is not listing. Is there something I am missing ?
mips-linux-objdump -S <filename.o> > temp
Most likely either a) all debugging information was stripped off the kernel module object file at some point during the build or b) even if the debugging information is there, objdump can't locate the source code files, in which case you might try to cd to where the source files are before running objdump.
You need to compile your kernel module with the debug information to have the interleaved source code in the dumped output. Recompile your kernel module with -g -ggdb for CFLAGS.