I am trying to implement a cryptography code and for that I need to include the pbc libraries into my code the basic code is as follows
#include "pbc.h"
int main(void)
{
/* call PBC functions */
return 0;
printf("it's there");
}
and I am working in ubuntu environment and after installing the pbc and gmu I am using this command
gcc -o foo foo.c -I home/Mtech/Desktop/Alok/pbc-0.5.14/include/pbc/ -L home/Mtech/Desktop/Alok/pbc-0.5.14/include/ -l pbc
but the system shows me the following error
:~/Desktop/Alok$ gcc -o foo foo.c -I home/Mtech/Desktop/Alok/pbc-0.5.14/include/pbc/ -L home/Mtech/Desktop/Alok/pbc-0.5.14/include/ -l pbc
foo.c:1:17: fatal error: pbc.h: No such file or directory
`enter code here`compilation terminated.
install gmp library first
sudo apt-get install libgmp3-dev
install pbc library,pbc uses gmp library
[download]: https://crypto.stanford.edu/pbc/download.html "follow guide for installation"
for compiling
gcc <program_name>.c -lgmp -lpbc
for c++
g++ <program_name>.cpp -lgmp -lgmpxx -lpbc
run
./a.out
Related
I want to use libxml2 as parser for a c program on a system with ubuntu. I used the following command to install libxml2:
sudo apt-get install -y libxml2-dev
I try to compile the following file: http://xmlsoft.org/examples/reader1.c
My makefile looks like this:
xml_reader: xml_reader.o
gcc -o xml_reader xml_reader.o -lxml2 -lm
xml_reader.c: xml_reader.c
gcc -c xml_reader.c -I/usr/include/libxml2
But sadly I get the following response:
fatal error: libxml/xmlreader.h: No such file or directory
Did I miss something, which I had to do before compiling or am I even using the right -l argument?
The target of your second Makefile rule should be xml_reader.o and not xml_reader.c. Right now make is using a default rule instead which does not make use of -I/usr/include/libxml2 and thus gcc cannot find the required header.
I have 2 files:
func.rs
#[no_mangle]
pub extern fn double_input(input: i32) -> i32 { input * 2 }
main.c
#include <stdint.h>
#include <stdio.h>
extern int32_t double_input(int32_t input);
int main() {
int input = 4;
int output = double_input(input);
printf("%d * 2 = %d\n", input, output);
return 0;
}
I want to create static lib in Rust and link the library to main.c. My active toolchain is stable-i686-pc-windows-gnu. I'm doing this in cmd:
rustc --crate-type=staticlib func.rs
But the file func.lib is created, so I do:
gcc -o myprog main.c func.lib -lgcc_eh -lshell32 -luserenv -lws2_32 -ladvapi32
But I get an error:
undefined reference to __ms_vsnprintf'
If I do:
rustc --crate-type=staticlib --target=i686-unknown-linux-gnu lib.rs
Then libfunc.a is created, but when I do:
gcc -o myprog main.c libfunc.a
I get an error:
main.c:(.text+0x1e): undefined reference to `double_input'
What am I doing wrong?
TL;DR: Install a different flavor of GCC
pacman -R local/gcc
pacman -S mingw-w64-i686-gcc
Half-informed guessing follows...
After some help on Rust IRC, it sounds like the issue is that the MSYS2 / MinGW gcc is a "stock" compiler, one without special knowledge of MSYS / MinGW / Windows special features.
mingw-w64-i686-gcc (or mingw-w64-x86_64-gcc) does know about Windows-specific symbols, which libbacktrace, a part of the Rust distribution, requires.
The "correct" GCC build should have the string "Built by MSYS2 project" in the gcc --version output.
With that, the full process looks like:
$ rustc --version --verbose
rustc 1.17.0 (56124baa9 2017-04-24)
host: i686-pc-windows-gnu
$ gcc --version
gcc.exe (Rev2, Built by MSYS2 project) 6.3.0
$ rustc --crate-type=staticlib func.rs
note: link against the following native artifacts when linking against this static library
note: the order and any duplication can be significant on some platforms, and so may need to be preserved
note: library: advapi32
note: library: ws2_32
note: library: userenv
note: library: shell32
note: library: gcc_eh
$ gcc -o main main.c func.lib -ladvapi32 -lws2_32 -luserenv -lshell32 -lgcc_eh
$ ./main
4 * 2 = 8
sorry for my bad english, to use a static rust library (.lib) you must add the following libraries to your linker:
shell32.lib advapi32.lib cfgmgr32.lib comctl32.lib comdlg32.lib
d2d1.lib dwrite.lib dxgi.lib gdi32.lib kernel32.lib msimg32.lib
ole32.lib opengl32.lib shlwapi.lib user32.lib windowscodecs.lib
winspool.lib userenv.lib ws2_32.lib bcrypt.lib msvcrt.lib
oleaut32.lib uuid.lib odbc32.lib odbccp32.lib
works in visual studio 2022
I'm trying to make a repository collecting all the examples, tutorials and instructions I could find on the internet for C mathematical and algebra libraries (BLAS, CBLAS, LAPACK, CLAPACK, LAPACKE, ATLAS, openblas, GSL...). but it seems that I just can't get the compiled BLAS .a files working on mac OS X.
So far I have been able to compile BLAS and use it on ubuntu:
BLAS source code from netlib website downloaded and compiled (rename blas_LINUX.a to libblas.a)
Then I can compile the C file on ubuntu using the command below:
gcc foo.c path/to/libblas.a
On my mac OS X (EL Capitan), I can compile BLAS (changing LINUX in the make.inc to DARWIN), but when I try to compile a C code using the command above I get errors like below:
Undefined symbols for architecture x86_64:
"_ddot_", referenced from:
_main in foo-3a35db.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
("ddot" part differs for different functions)
possibilities:
Maybe I'm not compiling the library correctly on mac and there are some differences I'm not aware of
The builtin Accelerate framework of mac OS X is messing up with the compiling process
P.S. Guys I know BLAS/LAPACK is already built into the mac OS X Accelerate framework and I can easily compile using the command gcc foo.c -lblas or gcc foo.c -framework Accelerate but I want to use the compiled .a from netlib. I want to know why it works properly on ubuntu but not mac OS X?
P.S.2. Please notice that I can compile the source code successfully without any errors on mac OS X. I just can use it!
Example code: source
#include <stdio.h>
#include <stdlib.h>
double ddot_(const int *N, const double *a, const int *inca, const double *b, const int *incb);
int main(int argc, char **argv) {
double *a = (double *)malloc(3 * sizeof(double));
a[0] = 1.0;
a[1] = 2.0;
a[2] = 3.0;
// on the stack
double b[3] = {4.0, 5.0, 6.0};
int N = 3, one = 1; // one really doesn't look good in C
double dot_product = ddot_(&N, a, &one, b, &one);
printf(" The dot product is: %f \n", dot_product);
return 0;
}
(edit1) solution:
open make.inc
change the line OPTS = -O3 to OPTS = -O3 -pipe -c and make.
(edit2): better solution:
since I asked this question I have realised that I have been doing everything wrong. Netlib BLAS is actually a collection of fortran routines/subroutines/functions. and the Makefile in the source code just gives us a static library libblas.a which is a collection of all .o object files compiled with gfortran. when we want to compile a C code which want to call one of those routines, we also need to link to the gfortran library libgfortran.* so if you have gcc installed (brew install gcc). look for libgfrotran* (sudo find / -name "libgfortrn.*") and then link your gcc to this folder too. to make it easy I put a Makefile here:
all:
gcc -c foo.c
gcc -o bar.out foo.o -L path/to/libgfortran.*/ -lgfortran -L path/to/libblas.a -lblas
or alternatively compile the code directly with gfortran:
all:
gcc -c foo.c
gfortran -o bar.out foo.o -L path/to/libblas.a -lblas
or simply compile with:
gcc foo.c bar.out -L path/to/libblas.a -lblas -L path/to/libgfortran.*/ -lgfortran
the wonder is how/why the former solution actually worked and why on ubuntu you don't have to link to -lgfortran!
It seems you compiled BLAS library from Netlib with compiler options that changed the mangling scheme of Fortran routines.
By default, Netlib's make.inc uses gfortran to compile BLAS:
$ grep FORTRAN make.inc
# Modify the FORTRAN and OPTS definitions to refer to the
FORTRAN = gfortran
It is compiled without any flags:
gfortran -O3 -pipe -c ddot.f -o ddot.o
and you get the ddot() routine:
$ grep -i ddot ddot.o libblas.a
Binary file ddot.o matches
Binary file libblas.a matches
And you can find it with the command line tools:
$ nm ddot.o libblas.a | grep -i ddot
ddot.o:
0000000000000000 T _ddot_
libblas.a(ddot.o):
0000000000000000 T _ddot_
Your example compiles with the library:
cc ex.c libblas.a
or with the ddot.o file:
cc -pipe ex.c ddot.o
I cannot reproduce your problem. You should use the nm and grep commands to find out what happened to the name of the ddot() routine.
PS. Your code has extra semicolon ; after the end of definition of main().
I'm new to developing for embedded systems, but I have installed arm-linux-gnueabi-gcc via the Linux Mint package manager and managed to build a few programs successfully.
I'm currently struggling with getting a program to compile using libusb. I've done the following:
Downloaded and unpacked the libusb 1.0.20 sources from https://sourceforge.net/projects/libusb/.
Compiled and installed them using the following commands:
~/Downloads/libusb-1.0.20 $ ./configure --host=arm-linux-gnueabi --prefix=/opt/ --disable-udev
~/Downloads/libusb-1.0.20 $ sudo make
~/Downloads/libusb-1.0.20 $ sudo make install
(The reason for sudo-ing the make commands was because I encountered permission problems related to removing old files.)
Copied a small sample file from somewhere on the internet:
#include <libusb-1.0/libusb.h>
#include <stdio.h>
int main()
{
int i=0;
libusb_context **c = NULL;
i = libusb_init(c);
printf("\nusing libusb.h\n");
return 0;
}
Tried to build it and run it with gcc:
~/Desktop/libtest $ gcc libtest1.c -o libtest1 -lusb-1.0
~/Desktop/libtest $ ./libtest1
using libusb.h
However, when I try to do the same with arm-linux-gnueabi-gcc, it can't find the library:
~/Desktop/libtest $ arm-linux-gnueabi-gcc libtest1.c -o libtest1 -lusb-1.0
/usr/lib/gcc-cross/arm-linux-gnueabi/4.7/../../../../arm-linux-gnueabi/bin/ld: cannot find -lusb-1.0
collect2: error: ld returned 1 exit status
Where did I go wrong? Is there something else I need to do in order to use the library? Did I fail at compiling the library for the arm compiler? I didn't include the compiler output here since it's quite long, but there are no obvious errors. This might be a very stupid question, but I'm completely clueless.
I have installed in /usr/ the distribution provided version of SQLite - version 3.4.2.
I have installed in /usr/local/ SQLite version 3.7.4.
/usr/include/sqlite3.h defines SQLITE_VERSION_NUMBER as 3004002
/usr/local/include/sqlite3.h defines SQLITE_VERSION_NUMBER as 3007004
Version 3007004 has the function sqlite3_initialize(), version 3004002 does not.
$ nm -D /usr/local/lib/libsqlite3.so | grep sqlite3_initialize
00018e20 T sqlite3_initialize
When I compile the following example program:
#include <stdio.h>
#include <sqlite3.h>
// This should fail if including /usr/include/sqlite3.h
#if SQLITE_VERSION_NUMBER != 3007004
#error "SQLite version is not 3.7.4"
#endif
int main() {
printf( "%d\n", SQLITE_VERSION_NUMBER );
sqlite3_initialize();
return 0;
}
When compiled and linked (with gcc 4.2.4) like this the preprocessor finds the sqlite3.h header for version 3.7.4 in /usr/local/include/, but the linker fails as it's looking in /usr/lib/libsqlite3.so for the symbols.
$ gcc -Wall test.c -o cpp -lsqlite3
/tmp/cc4iSSN6.o: In function `main':
test.c:(.text+0x26): undefined reference to `sqlite3_initialize'
test.c:(.text+0x2b): undefined reference to `sqlite3_shutdown'
collect2: ld returned 1 exit status
Of course I can specify the lib directory and it links the correct version of the library.
$ gcc -Wall test.c -o cpp -L/usr/local/lib -lsqlite3
$ ./cpp
3007004
$
It seems by default gcc looks in /usr/local/include/ before /usr/include/ for headers, but not for libraries when linking. Why?
Edit 1: As suggested by Tim Post:
$ sudo ldconfig -n /usr/local/lib
$ ldconfig -p | grep sqlite3
libsqlite3.so.0 (libc6) => /usr/local/lib/libsqlite3.so.0
libsqlite3.so.0 (libc6) => /usr/lib/libsqlite3.so.0
libsqlite3.so (libc6) => /usr/local/lib/libsqlite3.so
libsqlite3.so (libc6) => /usr/lib/libsqlite3.so
$ gcc -Wall cpp.c -o cpp -lsqlite3
/tmp/ccwPT9o0.o: In function `main':
cpp.c:(.text+0x26): undefined reference to `sqlite3_initialize'
cpp.c:(.text+0x2b): undefined reference to `sqlite3_shutdown'
collect2: ld returned 1 exit status
The include file search path is defined by gcc, but the library search path is encoded into ld, which is from a separate project; these are not necessarily synchronized.
One thing you could do is patch the specs file, which, if it exists, can be found in the same directory as libgcc; you can get the path to the latter using
gcc -print-libgcc-file-name
If there is no specs file there, create one using
gcc -dumpspecs >specs
and verify that gcc is reading it, by calling
gcc -v
Look for a line containing %{L*}, and add -L/usr/local/lib behind it (separated by spaces). Gcc will then pass this argument following any -L options from the command line to ld when linking.
In order to restore the defaults, just revert the specs file to its initial state (i.e. delete it if it didn't exist before).
This may be symptom of using the gold linker, which does not search /usr/local/lib, at least in some versions. Try removing the package binutils-gold.