C compiler not finding gmp linked library - c

I'm trying to compile a simple C program on an M1 Mac that includes gmp.h. For whatever reason, however, it continuously says that it can't find the library. I checked to see if it exists via locate libgmp.a to which it says it is located in /opt/local/lib/libgmp.a. I also attempted to install it via brew to no avail. I really don't understand what I'm doing wrong here. I also checked the PATH environment variable to make sure this path was included, which it is.
The output of find /opt/local -type f -name "gmp.h" is /opt/local/include/gmp.h, and the output of find /opt/local -type f -name "libgmp*" is
/opt/local/libgmp.a
/opt/local/lib/libgmpxx.4.dylib
/opt/local/lib/libgmp.a
/opt/local/lib/libgmpxx.a
/opt/local/lib/libgmp.10.dylib
I compiled by linking via -L/opt/local/lib -lgmp does not fix the issue.
Command used: gcc main.c -o main.o -L/opt/local/lib -lgmp

To compile a program that relies on a header file:
#include <gmp.h>
located in a non-standard location /usr/local/include/gmp.h you need to tell the compiler where to find it by setting the directory where to find the header file:
gcc -c main.c -I/usr/local/include
Note: gpp -x c -v
To link the program, you need to tell the compiler which library to use (-l) and where to find that library (-L) which in this case /usr/local/lib/gmp.a:
gcc main.o -o main -L/usr/local/lib -lgmp
Note: gcc -print-search-dirs | grep ^libraries
If you are using a dynamic library (.so), you may also need to tell the linker where to find the library at run-time:
export LD_LIBRARY_PATH=/usr/local/lib
./main

Related

Problem compiling C-Function to Postgres; compiler didn't find postgres.h

I was asked to create a C-Function to integrate with Postgres. The Postgres documentation to this kind of function is available here: Postgres documentation.
The function I am trying to compile is from the manual and it is called add_one, just for test. But I had a problem while compiling it. The command I followed of the documentation was:
cc -fPIC -c foo.c
cc -shared -o foo.so foo.o
And the problem it returned was:
[igoralberte#localhost inside-postgres]$ cc -fPIC -c serializacao.c
serializacao.c:1:10: fatal error: postgres.h: Arquivo ou diretório inexistente
#include "postgres.h"
^~~~~~~~~~~~
compilation terminated.
In English, it means: Non-existent file or directory (postgres.h).
I have tried to copy some files I thought were important to /usr/lib directory. They were on /usr/include/pgsql or on /lib64. Those files were:
libpq.so
libpq.so.5
libpq.so.5.13
libpq (directory)
postgres_ext.h
Some important informations about my system:
I am using CentOS 8
System architecture: x86-64
GCC version: gcc (GCC) 8.4.1 20200928 (Red Hat 8.4.1-1)
Postgres version: 13.3
Thanks in advance!
It is a bold step to write a postgres plugin before you have a solid grasp on linux/unix, shell programming and how to compile c programs.
Typically your c compiler has to be told where to find header files using the -I compiler switch. So if postgres.h is in /path/containing/headerfile, you must add -I/path/containing/headerfile to the compile command:
cc -I/path/containing/headerfile -fPIC -c foo.c
The postgres documentation you linked to tells you to use pg_config --includedir-server to find out where the the header files are stored.
I am not familiar with pg_config, but if it acts like similar tools and
gives the output -I/path/containing/headerfile when calling it with the paramater --includedir-server, then you don't have to hardcode the path in your compile command. But just write:
cc `pg_config --includedir-server` -fPIC -c foo.c
See "Command Substitution" in your favorite shell documentation.
I also recommend learning how to use a build-tool like make. Things are soon going to be tedious if you have to retype compilation and link commands all the time.
Oh, and by the way, you probably want to write #include <postgres.h> and not #include "postgres.h" (Unless you are a postgres contributor and postgres.h is part of your project files)

Shared library not found when compiling a C program

So, I have a simple program which looks like so:
#include <amqp.h>
#include <amqp_framing.h>
int main(int argc, char const * const *argv) {
amqp_connection_state_t conn;
conn = amqp_new_connection();
amqp_destroy_connection(conn);
return 0;
}
This program depends on rabbitmq-c library. I compiled it with no errors. So, when I run
$ ls /rabbitmq-c/_install/include/
I get all its header files, that I need:
amqp.h
amqp_framing.h
amqp_tcp_socket.h
And when I run
$ ls /rabbitmq-c/_build/librabbitmq/
I see all needed ".so" files:
CMakeFiles
Makefile
cmake_install.cmake
config.h
librabbitmq.a
librabbitmq.so
librabbitmq.so.4
librabbitmq.so.4.4.1
And finally I compile my own program like so:
$ gcc -I/rabbitmq-c/_install/include/ -g -Wall -c main.c
$ gcc -L/rabbitmq-c/_build/librabbitmq/ -g -Wall -o rabbit main.o -lrabbitmq
It compiles with no errors. However, when I do:
$ ldd ./rabbit
I get this message:
librabbitmq.so.4 => not found
So, what am I missing and how can I fix it?
When you link shared library into an executable, the linker will recorder the library name (in this case librabbitmq.so.4) into the executable. It is the job of the dynamic linker (ld.so), to locate the libraries, and combine them for execution.
To locate the libraries, the dynamic linker constructs a search path (similar to PATH). This include:
LD_LIBRARY_PATH
Hard-coded directories added to the executable.
Default folders (/lib, /usr/lib, etc.).
In the above case, looks like neither #1 nor #2 were used, and the library is not in the default location. Can be fixed using #1 or #2
# Option 1.
# Both gcc, and ldd consult LD_LIBRARY_PATH
export LD_LIBRARY_PATH=/rabbitmq-c/_build/librabbitmq
gcc -g -Wall -o rabbit main.o -lrabbitmq
ldd ./rabbit
# Option #2
# Inject SO directory into the executable with -Wl,-rpath,...
gcc -L/rabbitmq-c/_build/librabbitmq/ -Wl,-rpath,/rabbitmq-c/_build/librabbitmq/ -g -Wall -o rabbit main.o -lrabbitmq
ldd ./rabbit
Consult man ld.so for the full details.
From personal experience, when dealing with 'one-off' libraries, better to use the 'rpath' (#2) approach. Trying to add lot of locations into LD_LIBRARY_PATH can easily result in hard to manage, long, LD_LIBRARY_PATH. Using LD_LIBRARY_PATH works best when a wrapper script is created to launch the program
File: rabbit-run (same folder as executable)
# Prepend rabbitmq SO location to current LD_LIBRARY_PATH
LD_LIBRARY_PATH=LD_LIBRARY_PATH=/rabbitmq-c/_build/librabbitmq${LD_LIBRARY_PATH+:$X}
# Execute the binary, from the same location of the launcher
${0%/*}/./rabbit
If your binary don't find your "librabbitmq.so.4", that means this shared object is not found by ld (the dynamic linker)
First step, do a "ldconfig". Does this solve your problem ?
Yes ? Cool.
if not, then you have to tell ldconfig where to look to find "librabbitmq.so.4".
So either you move it in a knowed folder (LD_LIBRARY_PATH for exemple) or add it so it will be knowed by ld.
echo '/rabbitmq-c/_build/librabbitmq' > '/etc/ld.so.conf.d/name_this_file_yourself.conf'
ldconfig
This should fix your issue.

How to let gcc compiler know where a certain file is

I'm trying to compile my C code but I need to tell the GCC compiler where two file are.
The two files are located here
/usr/local/ssl/include/
/usr/local/ssl/lib/
I want to add this to my gcc -o file file.c so that my program can work.
In gcc, the -I option is used for adding a directory to the set of directories to search for header files, and the -L option is used for adding a directory to the set of directories to search for libraries. Since you're not explicitly linking in any libraries, you shouldn't need the -L option in this case.
gcc -I/usr/local/ssl/include -o file file.c
If you were linking in libraries, something like the following format should work, assuming that file.c calls a function in libmyLib.a:
gcc -I/usr/local/ssl/include -o file file.c -L/path/to/my/library -lmyLib
See this question for more details regarding library linking order.

a linker issue when learning static library [duplicate]

When I try to build the following program:
#include <stdio.h>
int main(void)
{
printf("hello world\n");
return 0;
}
On OS X 10.6.4, with the following flags:
gcc -static -o blah blah.c
It returns this:
ld: library not found for -lcrt0.o
collect2: ld returned 1 exit status
Has anyone else encountered this, or is it something that noone else has been affected with yet? Any fixes?
Thanks
This won’t work. From the man page for gcc:
This option will not work on Mac OS X unless all libraries (including libgcc.a) have also been compiled with -static. Since neither a static version of libSystem.dylib nor crt0.o are provided, this option is not useful to most people.
Per Nate's answer, a completely static application is apparently not possible - see also man ld:
-static Produces a mach-o file that does not use the dyld. Only used building the kernel.
The problem in linking with static libraries is that, if both a static and a dynamic version of a library are found in the same directory, the dynamic version will be taken in preference. Three ways of avoiding this are:
Do not attempt to find them via the -L and -l options; instead, specify the full paths, to the libraries you want to use, on the compiler or linker command line.
$ g++ -Wall -Werror -o hi /usr/local/lib/libboost_unit_test_framework.a hi.cpp
Create a separate directory, containing symbolic links to the static libraries, use the -L option to have this directory searched first, and use the -l option to specify the libraries you want to use.
$ g++ -Wall -Werror -L ./staticBoostLib -l boost_unit_test_framework -o hi hi.cpp
Instead of creating a link of the same name in a different directory, create a link of a different name in the same directory, and specify that name in a -l argument.
$ g++ -Wall -Werror -l boost_unit_test_framework_static -o hi hi.cpp
You may also try LLVM LLD linker - I did prebuilt version for my two major OSes - https://github.com/VerKnowSys/Sofin-llds
This one allows me to link for exmple: "Qemu" properly - which is impossible with ld preinstalled by Apple.
And last one is - to build GCC yourself with libstdc++ (don't).

arm-gcc unresolved reference 'sinf'

I'm getting this error when trying to compile:
error: undefined reference to `sinf'
I have included math.h, and verified that it is defined in there:
#include <math.h>
However, I get an error while trying to link to the math library:
arm-none-eabi-ld -L/usr/lib -lm --gc-sections -T ../standalone.ld -o "main.elf" ./main.o ./startup_gcc.o
error: cannot find -lm
However, the library is obviously there:
Kens-MacBook-Pro:lib Ken$ pwd
/usr/lib
Kens-MacBook-Pro:lib Ken$ ls | grep libm
libm.dylib
libmecab.1.0.0.dylib
libmecab.dylib
libmecabra.dylib
libmenu.5.4.dylib
libmenu.dylib
libmx.A.dylib
libmx.dylib
Kens-MacBook-Pro:lib Ken$
What am I doing wrong? I'm using Eclipse.
Judging by your arm-none-eabi-ld command, I'm assuming you're cross compiling. You need to install some sort of math library into the toolchain for whatever your platform is.
The ls output you posted contains a list of libraries available for your host, not your target. On my machine, the libraries for my ARM cross-compiler resides in /opt/local/arm-none-eabi/lib/ for example.
danieltang ~$ ls /opt/local/arm-none-eabi/lib/
crt0.o ldscripts libm.a libssp_nonshared.a libstdc++.a-gdb.py libsupc++.la
elf2flt.ld libc.a libssp.a libssp_nonshared.la libstdc++.la thumb
fpu libg.a libssp.la libstdc++.a libsupc++.a

Resources