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.
Related
I am new to C and using GCC. How do I compile multiple C files and then run them? I have multiple miles and each has different functions and they are supposed to run through the main.c file. My friend showed me through Windows but I am having issues figuring out how to do it on Mac.
What I was told:
Compile both files individually first:
gcc -Wall -c .\main.c
gcc -Wall -c .\file.c
Then compile both together into an executable:
gcc -o program file.o main.o
Then run executable with .\program.exe
You should probably investigate makefiles, but this is quite easy. The following should do the trick.
gcc -o program file.c main.c
Feel free to add in whichever -W warning flags you want.
Note also that Macs do not use \ as a directory separator but rather /, and executable files do not typically end in .exe.
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
Sorry. I think this question would be very easy to you guys.
I have two c files and one h file, I put those two .c files stack.c and main.c and one .h file stack.h inside a folder named "test" at Desktop.
So they are in C:\Users\user\Desktop\test
However when i try to test this code by writing
gcc -c stack.c sq_main.c -l stack.h
It continuously shows "unkown type name ..."
I think the header file is not included into those two .c files.
Actually I wrote the code
#include "stack.h"
Inside stack.c and main.c
Can anyone tell me how to include header file properly?
You are using GCC wrongly. I guess you are on Linux (or on something emulating it like MinGW ...)
If you insist on giving several commands in a terminal, you'll need to run
gcc -Wall -Wextra -g -c stack.c
gcc -Wall -Wextra -g -c sq_main.c
these two commands are building object files stack.o & sq_main.o (from stack.c & the #include-d stack.h, and sq_main.c & the #include-d stack.h, respectively). The options -Wall -Wextra are asking for all warnings and some extra warnings. The -g option asks for debugging information. The -c option asks for compiling only. Assuming that they are enough for your program, you need to link these object files to make an executable:
gcc -g stack.o sq_main.o -o myprogram
You might need to add -Iinclude-directory options to the compiling commands (the first two), and you might need to add -Llibrary-directory and -llibrary-name to the linking command. Order of arguments to gcc matters a lot. You could also add -H to ask the compiler to show which files are included. And GCC has a lot of other options. Read the Invoking GCC chapter of its documentation.
The .o suffix might be .obj on most Windows systems. You might also need myprogram.exe instead of myprogram. I never used Windows so I cannot help more.
In practice, you should use GNU make and write some Makefile; this answer might inspire you.
I am trying to learn the C Calling conventions in assembly language. To do so, I made a simple program using the puts function from the C standard library.
I assembled and linked the program with the following commands :-
nasm -f elf file.asm
gcc -m32 file.asm -o file
The nasm produces the right object file but when running the gcc to link the object files, I am getting error.
Looking at the error I have figured it out that I don't have the 32 bit version of glibc on my system. How can I install it. I already have installed this package installed.
I have 64 bit ubuntu 12.04 as my OS.
EDIT :- I have installed the following packages, but the problem is still not solved :-
1)ia32-libs
2) libc6-i386
This command will install the 32bit glibc libraries on 64 bit Ubuntu:
sudo apt-get install gcc-multilib
This is the proper syntax for linking assembly object code into an executable using gcc:
gcc -m32 objectfile.o -o executablefile
(nasm -felf32 already creates objectfile.o; the .asm file should not appear on GCC's command line. GCC can assemble+link a .S file in one step using GAS syntax, but NASM is a separate package.)
I assembled and linked the program with the following commands :-
nasm -f elf file.asm
gcc -m32 file.asm -o file
This is wrong. Your first nasm command is probably creating a file.o file (and you should check that, e.g. with ls -l file.o). The second gcc command does not do what you wish.
But gcc does not know about *.asm file extensions (it knows about .S for preprocessable GNU assembler syntax, and .s for assembler code, but probably handle unknown extensions like .asm as ELF object files by default, however file.asm is not an ELF object file). You should try linking with
gcc -Wall -v -m32 file.o -o file
Notice that you give to GCC an object file in ELF (for the linker invoked by gcc) which you previously produced with nasm.
(you might later remove the -v option to gcc)
Alternatively, use the GNU as assembler syntax (not the nasm one), name your file file.S (if you want it to be preprocessed) or file.s (without preprocessing) and use gcc -v -Wall -m32 file.s -o myprog to compile it.
BTW, to understand more about calling conventions, read the x86-64 ABI spec (and the similar one for 32 bits x86 ...), make a small C example file some-example.c, then run gcc -S -fverbose-asm -O some-example.c and look into the produced some-example.s with an editor or pager.
Learn also more about ELF then use readelf (& objdump) appropriately.
You want to install a package called 'ia32-libs'
I want clang to compile my C/C++ code to LLVM bitcode rather than a binary executable. How can I achieve that?
And if I have the LLVM bitcode, how can I further compile it to a binary executable?
I want to add some of my own code to the LLVM bitcode before compiling to a binary executable.
Given some C/C++ file foo.c:
> clang -S -emit-llvm foo.c
Produces foo.ll which is an LLVM IR file.
The -emit-llvm option can also be passed to the compiler front-end directly, and not the driver by means of -cc1:
> clang -cc1 foo.c -emit-llvm
Produces foo.ll with the IR. -cc1 adds some cool options like -ast-print. Check out -cc1 --help for more details.
To compile LLVM IR further to assembly, use the llc tool:
> llc foo.ll
Produces foo.s with assembly (defaulting to the machine architecture you run it on). llc is one of the LLVM tools - here is its documentation.
Use
clang -emit-llvm -o foo.bc -c foo.c
clang -o foo foo.bc
If you have multiple source files, you probably actually want to use link-time-optimization to output one bitcode file for the entire program. The other answers given will cause you to end up with a bitcode file for every source file.
Instead, you want to compile with link-time-optimization
clang -flto -c program1.c -o program1.o
clang -flto -c program2.c -o program2.o
and for the final linking step, add the argument -Wl,-plugin-opt=also-emit-llvm
clang -flto -Wl,-plugin-opt=also-emit-llvm program1.o program2.o -o program
This gives you both a compiled program and the bitcode corresponding to it (program.bc). You can then modify program.bc in any way you like, and recompile the modified program at any time by doing
clang program.bc -o program
although be aware that you need to include any necessary linker flags (for external libraries, etc) at this step again.
Note that you need to be using the gold linker for this to work. If you want to force clang to use a specific linker, create a symlink to that linker named "ld" in a special directory called "fakebin" somewhere on your computer, and add the option
-B/home/jeremy/fakebin
to any linking steps above.
If you have multiple files and you don't want to have to type each file, I would recommend that you follow these simple steps (I am using clang-3.8 but you can use any other version):
generate all .ll files
clang-3.8 -S -emit-llvm *.c
link them into a single one
llvm-link-3.8 -S -v -o single.ll *.ll
(Optional) Optimise your code (maybe some alias analysis)
opt-3.8 -S -O3 -aa -basicaaa -tbaa -licm single.ll -o optimised.ll
Generate assembly (generates a optimised.s file)
llc-3.8 optimised.ll
Create executable (named a.out)
clang-3.8 optimised.s
Did you read clang documentation ? You're probably looking for -emit-llvm.