gcc won't include libcurl on commandline for OS X - c

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.

Related

Problems building DBD Sybase on Debian

I am trying to build DBD::Sybase on Debian machine, but I am running into a problem. The problem is, BFD (GNU Binutils) 2.21.1 internal error when linking the program. Please help me resolve this.
I successfully installed freetds
Downloaded "DBD-Sybase-1.16"
Executed "perl Makefile.PL INSTALL_BASE=/usr/lib/perl5/" which was successfull
When I execute "sudo make", I get the following error. I tried googling but could not find help.
Here is the tail of the build.
Skip blib/lib/DBD/Sybase.pm (unchanged)
Skip blib/lib/DBD/dbd-sybase.pod (unchanged)
Running Mkbootstrap for DBD::Sybase ()
chmod 644 Sybase.bs
/network/glnxa64/gcc-4.7.2/bin/gcc -c -I/usr/local/freetds/include -DSYB_LP64 -DNO_BLK=1 -I/company/hub/share/apps/BuildTools/Linux/glibc-2.13/x86_64/perl/perl-5.20.2-mw-021/lib/site_perl/5.20.2/x86_64-linux-thread-multi/auto/DBI -D_REENTRANT -D_GNU_SOURCE -O2 -pipe -pthread -fPIC -fwrapv -fno-strict-aliasing -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -DVERSION=\"1.16\" -DXS_VERSION=\"1.16\" -fPIC "-I/company/hub/share/apps/BuildTools/Linux/glibc-2.13/x86_64/perl/perl-5.20.2-mw-021/lib/5.20.2/x86_64-linux-thread-multi/CORE" Sybase.c
/network/glnxa64/gcc-4.7.2/bin/gcc -c -I/usr/local/freetds/include -DSYB_LP64 -DNO_BLK=1 -I/company/hub/share/apps/BuildTools/Linux/glibc-2.13/x86_64/perl/perl-5.20.2-mw-021/lib/site_perl/5.20.2/x86_64-linux-thread-multi/auto/DBI -D_REENTRANT -D_GNU_SOURCE -O2 -pipe -pthread -fPIC -fwrapv -fno-strict-aliasing -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -DVERSION=\"1.16\" -DXS_VERSION=\"1.16\" -fPIC "-I/company/hub/share/apps/BuildTools/Linux/glibc-2.13/x86_64/perl/perl-5.20.2-mw-021/lib/5.20.2/x86_64-linux-thread-multi/CORE" dbdimp.c
rm -f blib/arch/auto/DBD/Sybase/Sybase.so
LD_RUN_PATH="/usr/local/freetds/lib" /network/glnxa64/gcc-4.7.2/bin/gcc -shared -L/usr/local/freetds/lib -pthread -L/usr/local/lib -fstack-protector Sybase.o dbdimp.o -o blib/arch/auto/DBD/Sybase/Sybase.so \
-L/usr/local/freetds/lib -lct -ldl -lm \
/network/glnxa64/gcc-4.7.2/bin/ld: BFD (GNU Binutils) 2.21.1 internal error, aborting at /local/greg/3p/sources/gcc-4.7/../binutils/bfd/reloc.c line 443 in bfd_get_reloc_size
/network/glnxa64/gcc-4.7.2/bin/ld: Please report this bug.
collect2: error: ld returned 1 exit status
Makefile:485: recipe for target 'blib/arch/auto/DBD/Sybase/Sybase.so' failed
make: *** [blib/arch/auto/DBD/Sybase/Sybase.so] Error 1
As #jww pointed out, the issue was the older version of binutils and gcc. I just edited the generated Makefile in Sybase base directory to point to newer versions of gcc and binutils. FYI, I the versions that worked are "gcc version 6.3.0 " and "GNU ld (GNU Binutils) 2.28.1"

How to compile with a .o file that was compiled with other .o files (C99)

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.

Error while compiling and linking dll

I am trying to compile a simple dll following the cygwin tutorial. I have been able to successfully do all but the last step. When I execute the command:
gcc -o myprog myprog.c -L./ -lmydll
I get an error saying that hello() is not declared in that scope. I followed the tutorial verbatim, yet I am still not able to compile the simple project and am lost as to why.
The code for the individual files are as follows:
(myprog.c)
int main(void){
hello();
}
(mydll.c)
#include <stdio.h>
int hello(){
printf("Hello World!\n");
return 0;
}
The example is working fine for me in my Cygwin
armathew#3NJ2VQ1 /cygdrive/d/userdata/armathew/Desktop/WWWW
$ ls
mydll.c myprog.c
armathew#3NJ2VQ1 /cygdrive/d/userdata/armathew/Desktop/WWWW
$ gcc -c mydll.c
armathew#3NJ2VQ1 /cygdrive/d/userdata/armathew/Desktop/WWWW
$ gcc -shared -o mydll.dll mydll.o
armathew#3NJ2VQ1 /cygdrive/d/userdata/armathew/Desktop/WWWW
$ gcc -o myprog myprog.c -L./ -lmydll
armathew#3NJ2VQ1 /cygdrive/d/userdata/armathew/Desktop/WWWW
$ ./myprog.exe
Hello World!
What is the Cygwin version you are using? Mine is 1.7.5
armathew#3NJ2VQ1 /cygdrive/d/userdata/armathew/Desktop/WWWW
$ uname -r
1.7.5(0.225/5/3)
well, the statement for linking library may be incorrect.
It should be
-L<library path> -lyoulibrarymane
as there is no "./" after the library path.
here is an example that I used, it may be helpful. the -I/usr/local/include is the header file path
gcc -o hello-world helloopencv.c -I/usr/local/include -L/usr/local/lib -lopencv_highgui -lopencv_core -lopencv_imgproc
You need to add a declaration at the top of myprog.c:
int hello(void);
Or you could put this in a new mydll.h and #include that in myprog.c.

Cython and cross-compilation

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

[C]undefined reference while compiling openCL program

I'm trying to compile something to try out openCl, but i'm having a few problems..
Here the code
prova.c
#include <stdio.h>
#include <CL/opencl.h>
#include "Utils\util.h"
#include <malloc.h>
int main(){
cl_int error = 0; // Used to handle error codes
cl_int max_platforms = 1; // The maximum number of platforms
cl_uint adviable_platforms = 0; //The adviable number of platforms
cl_platform_id* platform;
error = clGetPlatformIDs(0, NULL, &adviable_platforms);
if(adviable_platforms == 0)
{
printf("No adviable platforms.\n");
return -1;
} else {
platform = (cl_platform_id*)malloc(adviable_platforms * sizeof(cl_platform_id));
}
error = clGetPlatformIDs(adviable_platforms, platform, NULL);
printf("clGetPlatformIDs: %s\n", clErrorString(error));
return 0;
}
I'm compiling on win 7 64 with mingw32. The opencl headers are in the include directory of mingw while utils.h(inside the directory Utils inside the directory of prova.c) defines clErrorString(that simply convert the error into a more human readable string).
To compile i use
gcc -L\Utils prova.c
But i always get
C:\[stuff]\ccEjYQbj.o:prova.c:(.text+0x42): undefined reference to 'clGetPlatformIDs#12'
C:\[stuff]\ccEjYQbj.o:prova.c:(.text+0x8d): undefined reference to 'clGetPlatformIDs#12'
C:\[stuff]\ccEjYQbj.o:prova.c:(.text+0x9e): undefined reference to 'clErrorString'
I'm not so good with compilers, so i image i'm missing something, but i really don't know what..
EDIT:
Sincerely, i tried every command come to my mind. using -L to include directories, -l to link to files, using ar..
This is the last "script" i tried
set PATH=%PATH%;C:\Python26;C:\MinGW\bin;C:\MinGW\lib
cd Utils
gcc -c util.c -l"C:\Program Files (x86)\AMD APP\lib\x86_64\libOpenCL.a" -o util.o
ar rcs libutil.a util.o
cd..
pause
gcc -c prova.c -l"Utils\libutil.a" -o prova.exe
pause
EDIT2:
#echo off
set PATH=%PATH%;C:\Python26;C:\MinGW\bin;C:\MinGW\lib
cd Utils
gcc -Wall -c util.c -L"C:\Program Files (x86)\AMD APP\lib\x86_64\" -o util.o
ar rcs libutil.a util.o
cd..
pause
gcc -Wall -c prova.c -L"C:\Program Files (x86)\AMD APP\lib\x86_64\" -l"Utils\libutil.a" -o prova.exe
pause
No errors, the only warning is max_platform is unused. Then i find util.o and libutil.a(size 5kb) in Utils and prova.o(size 1kb). If i try to run prova.o, it says that the file version is not compatible with the current windows version, check the system version (x86 or x64) and contact the software distributor
Try something like this:
set PATH=%PATH%;C:\Python26;C:\MinGW\bin;C:\MinGW\lib
cd Utils
gcc -W -Wall -c util.c -o util.o
ar rcs libutil.a util.o
cd..
gcc -W -Wall -c prova.c -o prova.o
gcc -o prova.exe prova.o Utils\libutil.a
# Using a standard library
gcc -o prog.exe myprog.o -lzip # e.g. /usr/lib/libz.a
# Using a nonstandard library
gcc -o prog.exe myprog.o -lfoo -L/tmp/libfoo # uses /tmp/libfoo/libfoo.a
gcc -o prog.exe myprog.o /tmp/libfoo/libfoo.a # same effect
In general:
Compile single source files with -c:gcc -c myfile.c -o myfile.o.This creates object files.
Link all the object files to an executable (or shared library):gcc -o prog.exe myfile.o yourstuff.o sha257.o
You can combine object files into a static library, which you treat just like a single object file when linking:ar rcs libcoolstuff.a yourstuff.o sha257.ogcc -o prog.exe myfile.o libcoolstuff.aAlternatively:gcc -o prog.exe myfile.o -lcoolstuffThe latter syntax (automatic library linking with -l) requires either libcoolstuff.a or libcoolstuff.so to be findable in the library path (which you can amend with -L at linktime).

Resources