I downloaded RSA-OAEP example from https://github.com/Rupan/rsa. Next I compile in linux kali:
gcc -O0 -ggdb -Wall -W -DTEST tiger.o sboxes.o oaep.c -o oaep && ./oaep SomeRandomString
Output of this was:
gcc: error: tiger.o: No such file or directory , gcc: error: sboxes.o: No such file or directory.
I compile this files using:
gcc -c sboxes.c and gcc -c tiger.c
Next i compiled
gcc -O0 -ggdb -Wall -W -DTEST tiger.o sboxes.o oaep.c -o oaep && ./oaep SomeRandomString
and it doesnt work output is wrong can you help me ?
Related
I'm trying to link an external library but not linking. Using gcc version:
gcc (MinGW.org GCC Build-2) 9.2.0
Windows 10
Command I'm tried:
gcc -g test.c -Wall -I ../inc/ -L ../lib -l:libFp.a -o test.exe
gcc -g test.c -Wall -I ../inc/ -L ../lib64 -l:libFp.a -o test.exe
gcc -g -Wall -I ../inc/ -L ../lib -l:libFp.a test.c -o test.exe
gcc -g -Wall ../lib/libFp.a test.c -I ../inc/ -o test.exe
Error:
c:/mingw/bin/../lib/gcc/mingw32/9.2.0/../../../../mingw32/bin/ld.exe: C:\Users\XXXXXXXX\AppData\Local\Temp\cciWnORn.o: in function `main':
D:\C_Training\utils\XXXXXXXX\testApp/test.c:35: undefined reference to `addition'
collect2.exe: error: ld returned 1 exit status
Folder Hierarchy:
XXXX
==docs
==inc
==lib
--libFp.a
--fP.lib
==lib64
--libFp.a
==src
==testApp [cwd]
--test.c
Tried different solutions from StackOverflow but still same error.
Update: gcc -g -Wall -I ../inc -L ../lib test.c -o test.exe -lFp -Xlinker --verbose command output
Linker Output Verbose
I try to build PDCurses using MinGW, but have a problem in the second file which is specific for win32a:
..PDCurses-master\win32a>mingw32-make -f mingwin32.mak WIDE=Y UTF8=Y
...
gcc -c -O4 -Wall -I.. -DPDC_WIDE -DPDC_FORCE_UTF8 ../pdcurses/window.c
gcc -c -O4 -Wall -I.. -DPDC_WIDE -DPDC_FORCE_UTF8 ../pdcurses/debug.c
gcc -c -O4 -Wall -I.. -DPDC_WIDE -DPDC_FORCE_UTF8 ../win32a/pdcclip.c
gcc -c -O4 -Wall -I.. -DPDC_WIDE -DPDC_FORCE_UTF8 ../win32a/pdcdisp.c
../win32a/pdcdisp.c:451:1: error: unknown type name 'GLYPHSET'
GLYPHSET *PDC_unicode_range_data = NULL;
^
And some other errors in lines 450 - 470.
I have already reinstall MinGW, but the problem is the same. What am i doing wrong?
consider c.c a code that includes a.h and b.h, and main.c a code that includes c.h
i tried to compile it like so
gcc --std=c99 -o a.o -c a.c
gcc --std=c99 -o b.o -c b.c
gcc --std=c99 -o c.o -c c.c a.o b.o
but when I run the last one, gcc yells at me
gcc --std=c99 -o c.o -c c.c a.o b.o
gcc: warning: a.o: linker input file unused because linking not done
gcc: warning: b.o: linker input file unused because linking not done
and then when I try to compile the main.c file using gcc -o main main.c c.o it says that there are a lot of undefined references, which is predictable once the c file was not correctly compiled.
I've seen some similar questions here at stackoverflow, but I couldn't get it to work neither way.
I'm on Arch Linux running gcc v4.9.2-3
First, it is -std=c99 with a single dash.
I guess you are on Linux.
Then, you always should pass -Wall -Wextra -g (especially since you are a newbie) to gcc : -Wall ask for nearly all warnings, -Wextra for even more warnings, -g ask for debug information.
At last, you want to produce an executable myprog (don't name executables as c.o, this is supposed to be an object file) with
gcc -std=c99 -Wall -Wextra -g -o myprog c.c a.o b.o
You need to remove any -c since you want the linking to happen.
If you really mean -but that is very unusual today, better make shared libraries!- to agglomerate several object files into one all.o (to be linked later with other objects) you might try the -r linker option
gcc -std=c99 -Wall -Wextra -g -r c.c a.o b.o -o all.o
But last time I tried it was in the previous century, so details could be wrong.
There are very few reasons to agglomerate objects using the -r linker option. Unless you really know what you are doing, you are very probably wrong (in trying -r).
Perhaps you want to make a software library. These days it is much better to make a shared library. A shared library (technically an ELF shared object) should contain position independent code. So, assuming you have three translation units t1.c, t2.c, t3.c you first compile them as PIC :
gcc -std=c99 -Wall -Wextra -g -fPIC t1.c -c -o t1.pic.o
gcc -std=c99 -Wall -Wextra -g -fPIC t2.c -c -o t2.pic.o
gcc -std=c99 -Wall -Wextra -g -fPIC t3.c -c -o t3.pic.o
then you link all these PIC object files into a shared library libmyt.so
gcc -std=c99 -Wall -Wextra -g -shared \
t1.pic.o t2.pic.o t3.pic.o \
-o libmyt.so
Later you'll use this shared library e.g. as
gcc -std=c99 -Wall -Wextra -g main.o -o myprog -Wl,-rpath . libmyt.so
or as
gcc -std=c99 -Wall -Wextra -g main.o -o myprog -Wl,-rpath . -L. -lmyt
You might consider static linking with ar to make a static library libmyt.a but I don't recommend that.
Of course, you'll debug your program using gdb ./myprog and you could try running it with ./myprog. To use valgrind, try valgrind ./myprog
If you have several translation units, better learn how to use GNU make. Read the Program Library HowTo and this and these hints.
I have a file test.pyx and a test.c generated by $ cython test.pyx. I want to create a shared object test.so with gcc so that I can import it into Python. Compilation for linux x86-64 with
gcc -Wall -fPIC -I /usr/include/python2.7 -shared -o test.so test.c
Terminates successfully.
I want to compile the same file to a .dll for windows with mingw32. However when I attempt to execute
i586-mingw32msvc-gcc -Wall -fPIC -I /usr/include/python2.7 -shared -o test.dll test.c
I get this error:
test.c:1: warning: -fPIC ignored for target (all code is position independent)
In file included from /usr/include/python2.7/Python.h:58,
from test.c:16:
/usr/include/python2.7/pyport.h:338:24: error: sys/select.h: No such file or directory
Am I doing something wrong?
You do this with it:
<your_compiler> <cython_generated_c_file> -o <your_outputfilename> -fPIE -lpython<python_version>
<cflags> <ldflags>
To get cflags:
python-config --cflags
For ldflags:
python-config --ldflags
I'm trying to compile a C project I've been working on on a remote server that runs OS X. The project depends, in part, on libcurl. I only have access to the machine through my administrator account remotely.
When I attempt to make the project I keep getting errors relating to libcurl functions and constants not being defined. I conclude that libcurl is not being properly included by the compiler.
I'm using fink to install opensource software for all the dependencies ( postgres, curl, a few others ) and all the dependencies appear to work except curl.
My compiler command looks like:
gcc -ggdb -ansi -Wall -D_GNU_SOURCE -L `/sw/bin/pg_config --libdir` `/sw/bin/curl-config --cflags` -I `/sw/bin/pg_config --includedir` -lpq -lcurl -lpthread -lm `/sw/bin/curl-config --libs` -c Client.c
If I make a test file like so:
/sw/bin/curl http://www.google.com/ --libcurl test.c
And then attempt to compile it with:
gcc test.c `/sw/bin/curl-config --cflags` `/sw/bin/curl-config --libs` -o test.o
It also fails. Can anyone help me shed some light on this problem?
One compilation line is:
gcc -ggdb -ansi -Wall -D_GNU_SOURCE -L `/sw/bin/pg_config --libdir` \
`/sw/bin/curl-config --cflags` -I `/sw/bin/pg_config --includedir` \
-lpq -lcurl -lpthread -lm `/sw/bin/curl-config --libs` -c Client.c
This will take Client.c and generate Client.o, an object file. It doesn't need the library information; there is no linking taking place because of the -c option.
The other compilation line is:
gcc test.c `/sw/bin/curl-config --cflags` `/sw/bin/curl-config --libs` -o test.o
It is aconventional to end the names of executables with '.o'; it leads to confusion. However, if test.c only references functions from the standard libraries and libcurl, it should 'work'.
On my Mac, there is a copy of curl-config in /usr/bin.
Try this test program:
$ cat curltest.c
#include <stdio.h>
#include <curl/curl.h>
int main(void)
{
if (curl_global_init(0) == CURLE_OK)
{
printf("CURL version %s\n", curl_version());
curl_global_cleanup();
}
else
fprintf(stderr, "Failed to initialize CURL\n");
return 0;
}
$ cc -o curltest $(curl-config --cflags) curltest.c $(curl-config --libs)
$ file curltest
curltest: Mach-O 64-bit executable x86_64
$ otool -L curltest
curltest:
/usr/lib/libcurl.4.dylib (compatibility version 6.0.0, current version 6.1.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11)
$ curltest
CURL version libcurl/7.19.7 OpenSSL/0.9.8r zlib/1.2.3
$
This is on MacOS X 10.6.8.