I have a C file, which uses multiple lib files.
I am trying to compile the file in the following way:
gcc -o myprogram main.c list.lib filelib.lib
However, when trying to compile I get a bunch of undefined reference errors of all the lib functions that I'm using.
I came accross a solution on the internet and tried the following:
gcc -o myprogram main.c -l list -l filelib
Now I get the following errors:
cannot find -llist
cannot fint -lfilelib
What am I doing wrong?
Edit:
Both the libs were originally created using Visual Studio 2019, Release mode x64.
I am using Windows 10, 64 bits architecture.
In the folder I'm running gcc from I have the following files:
main.c
list.lib (copied from VS)
list.h (copied form VS)
filelib.lib (copied from VS)
filelib.h (copied from VS)
In my lib code in VS I made sure the functions have c-linkage:
#ifdef __cplusplus
#define C_LINKAGE extern "C"
#else
#define C_LINKAGE
#endif
(each declared function in both the libs starts with the C_LINKAGE macro)
The .lib files are MSVC specific, gcc can not handle them, gcc can handle .a libraries or dll's (on windows)
If you want to use gcc, rebuild the libraries with gcc, or let MSVC create DLL's.
Or stick to microsoft and use MSVC for everything.
Just put "-l:liblist.lib" instead of "-llist" when the suffix is not ".a". That should solve the "Not found" issue at least.
I would like to give a BIG thanks to #Harkaitz for this hint.
I spent several days to figure out why GCC (arm cross compile on Windows) was not able to find my libs in group. I wish those spelling issues to be more documented somewhere...
Basically the ':' in between '-l' and 'lib.a' was solving the issue, like this:
-L./my_path_to_libs -Xlinker --start-group -l:libmain.a -Xlinker --end-group
Depending on arm gcc verzion, -Xlinker could be -Wl
Related
How can I create dll from separate source and heading files (written in C).
I have
extrfunc.h
tricclib.c
tricclib.def
tricclibql.c
And I need to create dll (using c not c++) from these components.
These files are just here:
https://drive.google.com/drive/folders/1EyvxHxiOLJqNp7sZwn0YOsOT2eRJLCL1?usp=sharing
Thank you!
That depends on what compiler you're using. Because you are calling it a DLL, I am assuming you are running Windows. When I compile on Windows I use the MinGW port of GCC. Assuming this, do the following:
Make sure you have the correct __declspec on your functions.
Compile each source file to an object file with commands like: gcc -c -o example.o example.c
Link it with something like gcc -shared -o output_dll.dll object1.o object2.o -Wl,--out-implib,libexample_dll.a
I have MinGW and I wish to compile the SQLite amalgamation source into a 64-bit dll. I'm fairly new to this sort of compilation and my efforts so far have resulted in failure. (I first started using the autoconf amalgamation and used the configure & make tool on Linux. But apparently that will never work for Windows binaries.)
Anyway, I've been told I need the following preprocessor defines:
Here are the compiler pre-processor defines I use for a 64-bit release build:
WIN64 NDEBUG
_WINDOWS
_USRDLL
NO_TCL
_CRT_SECURE_NO_DEPRECATE
THREADSAFE=1
TEMP_STORE=1
SQLITE_MAX_EXPR_DEPTH=0
Here are the compiler pre-processor defines I use for a 32-bit release build:
WIN32
NDEBUG
_WINDOWS
_USRDLL
NO_TCL
_CRT_SECURE_NO_DEPRECATE
THREADSAFE=1
TEMP_STORE=1
SQLITE_MAX_EXPR_DEPTH=0
I had no idea where to put these in. I eventually took an educated guess, made a new file (for neatness) called sqlite3w64.h and pasted in the following:
#define WIN64 NDEBUG
#define _WINDOWS
#define _USRDLL
#define NO_TCL
#define _CRT_SECURE_NO_DEPRECATE
#define THREADSAFE 1
#define TEMP_STORE 1
#define SQLITE_MAX_EXPR_DEPTH 0
I then compiled the source with the following command:
gcc sqlitew64.h sqlite3.h sqlite3ext.h shell.c sqlite3.c -o sqlite_x64.dll
What resulted was a 733KB DLL file. Nice! Did it actually work? Did it nuts - I got a BadImageFormatException. I also then tried doing an x86 compilation using the same method. Once again, I got a 733KB DLL file (that's odd?) and once again, I got a BadImageFormatException.
Help.
Update
Used the following command instead:
gcc -shared -DWIN64 -DNDEBUG -D_WINDOWS -D_USRDLL -DNO_TCL -D_CRT_SECURE_NO_DEPRECATE -DTHREADSAFE=1 -DTEMP_STORE=1 -DSQLITE_MAX_EXPR_DEPTH=0 -I. shell.c sqlite3.c -o sqlite_x64.dll -Wl,--out-implib,sqlite3.a
Resulted in a 740KB DLL file which still gives a BadImageFormatException.
Final Update
Turns out my MinGW build was 32-bit only. Getting a 64-bit version then allowed me to make SQLite for 64-bit. Adding the flag -m64 sets the compiler into 64-bit mode.
64-bit:
gcc -shared -DWIN64 -DNDEBUG -D_WINDOWS -D_USRDLL -DNO_TCL -D_CRT_SECURE_NO_DEPRECATE -DTHREADSAFE=1 -DTEMP_STORE=1 -DSQLITE_MAX_EXPR_DEPTH=0 -m64 -I. shell.c sqlite3.c -o sqlite3_x64.dll -Wl,--out-implib,sqlite3_x64.a
32-bit:
gcc -shared -DWIN32 -D_WINDOWS -D_USRDLL -DNO_TCL -D_CRT_SECURE_NO_DEPRECATE -DTHREADSAFE=1 -DTEMP_STORE=1 -DSQLITE_MAX_EXPR_DEPTH=0 -m32 -I. shell.c sqlite3.c -o sqlite3_x86.dll -Wl,--out-implib,sqlite3_x86.a
MinGW-64 Precompiled: http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Automated%20Builds/mingw-w64-bin_i686-mingw_20111220.zip/download?use_mirror=ignum
Installation Instructions: http://code.google.com/p/tonatiuh/wiki/InstallingMinGWForWindows64
You are compiling to an EXE. Calling it a DLL won't magically make it a DLL.
You need to pass special linker options to gcc to make it create DLLs.
Quoted from Mingw site: (Sort of, I replaced g++ with gcc)
gcc -c -DBUILDING_EXAMPLE_DLL example_dll.cpp
gcc -shared -o example_dll.dll example_dll.o -Wl,--out-implib,libexample_dll.a
The page also explains that functions you want your DLL to export, must be declared with __declspec(dllexport). (Further down, there is an example on how to export all global functions to the DLL, like usually happens in Unix.)
The -Wl argument to gcc is what tells gcc to pass on the further arguments --out-implib,libexample_dll.a to the linker.
I would also make 100% sure that the built DLL is actually a 64 bit DLL and not a 32 bit DLL. Do you have any way to check that? On Linux you can run the "file" command.
You can also try adding the -m64 option to the gcc commandline, that should force gcc to target the amd64 target.
If that doesn't work, you may have the wrong compiler altogether. Make sure you have the x86_64/amd64 version of the Mingw toolchain. Installation is as simple as finding the right ZIP, unpacking it, and setting the path.
If all of that fails, or if you just want to verify against a supposedly correctly compiled setup, try precompiled 64-bit binaries here or from here.
What would work in your case is this single link-and-compile command:
g++ -shared
-DWIN64
-DNDEBUG
-D_WINDOWS
-D_USRDLL
-DNO_TCL
-D_CRT_SECURE_NO_DEPRECATE
-DTHREADSAFE=1
-DTEMP_STORE=1
-DSQLITE_MAX_EXPR_DEPTH=0
-I.
shell.c sqlite3.c
-o sqlite_x64.dll
-Wl,--out-implib,libsqllite_x64.dll.a
The compile and link stage will be performed at once. The defined can be added on the commandline. The headers need not be compiled, but you need to pass the current directory as a header search directory, and specify the names of the dll and import file.
Can I use a socket library from TCC? I can't find any reference to winsock or sys/socket.h in the include directory.
If i remember correctly, winsock was part of the windows platform SDK (?) If so can I link that with TCC?
According to Tinycc-devel mailing list
you should give this a try:
tiny_impdef winsock.dll -o winsock.def
tcc yourcode.c winsock.def -o yourcode.exe
Use tiny_impdef.exe to export definitions from the DLL file using the command line:
tiny_impdef.exe wsock32.dll -o .\lib\wsock32.def
You will also need the header files for your source code to include them. MinGW's ones (such as winsock2.h, ws2tcpip.h, ws2spi.h...) can be reused with TCC.
The MinGW compiler can be downloaded from here. Just copy the headers you need from MinGW's include directory to TCC's include\winapi directory.
At compilation time, you will need to tell the compiler you are using the Windows socket library:
tcc.exe path\to\code.c -lwsock32 -o path\to\program.exe
tiny_impdef winsock.dll
copy winsock.def to lib/
run:
tcc -lwinsock yourcode.c -o yourcode.exe
I used f2c to translate a huge Fortran subroutine into C. The header says the following:
/* fourier.f -- translated by f2c (version 20090411).
You must link the resulting object file with libf2c:
on Microsoft Windows system, link with libf2c.lib;
on Linux or Unix systems, link with .../path/to/libf2c.a -lm
or, if you install libf2c.a in a standard place, with -lf2c -lm
-- in that order, at the end of the command line, as in
cc *.o -lf2c -lm
Source for libf2c is in /netlib/f2c/libf2c.zip, e.g.,
http://www.netlib.org/f2c/libf2c.zip
*/
I am using ubuntu 10.04. How can I link the object file with libf2c?
You would have to install the libf2c2-dev package -- but as the f2c package already depends on it, all you may need is to add -lf2c to your Makefile.
Are you compiling the resulting C file with gcc? Then add "-lf2c -lm" to the gcc compile command.
Why not compile with a Fortran compiler, such as gfortran? It's easily available for Ubuntu.
By passing -lf2c -lm to the line which will create the executable from the objects. Which compiler are you using on Ubuntu? GCC?
gcc -c fourier.c -lf2c -lm
Could be as simple as that.
Well - no direct answer to your linking problems, but:
Since you're working with Linux: Why don't you compile you fortran code as is and link it directly with the C-code? GCC can do that. Converting the code is of course doable but it is by no way required.
Nils
I am attempting to cross-compile on AIX with the xlc/xlC compilers.
The code compiles successfully when it uses the default settings on another machine. The code actually successfully compiles with the cross-compilation, but the problem comes from the linker. This is the command which links the objects together:
$(CHILD_OS)/usr/vacpp/bin/xlC -q32 -qnolib -brtl -o $(EXECUTABLE) $(OBJECT_FILES)
-L$(CHILD_OS)/usr/lib
-L$(CHILD_OS)/usr/vacpp/lib/profiled
-L$(CHILD_OS)/usr/vacpp/lib
-L$(CHILD_OS)/usr/vac/lib
-L$(CHILD_OS)/usr/lib
-lc -lC -lnsl -lpthread
-F$(CHILD_OS)$(CUSTOM_CONFIG_FILE_LOCATION)
When I attempt to link the code, I get several Undefined symbols:
.setsockopt(int,int,int,const void*,unsigned long), .socket(int,int,int), .connect(int,const sockaddr*,unsigned long), etc.
I have discovered that the symbols missing are from the standard c library, libc.a. When I looked up the symbols with nm for the libc.a that is being picked up, the symbols do indeed exist. I am guessing that there might be a problem with the C++ being unable to read the C objects, but I am truly shooting in the dark.
Sound like it might be a C++ name mangling problem.
Run nm on the object files to find out the symbols that they are looking for. Then compare the exact names against the libraries.
Then check the compilation commands, to ensure that the right version of the header files is being included - maybe it's including the parent OS's copy by mistake?
I was eventually able to get around this. It looks like I was using the C++ compiler for .c files. Using the xlc compiler instead of the xlC compiler for C files fixed this problem.