I'm trying to create .lib files from .def files downloaded from FFTW.
According to this instruction, I should use lib.exe to create lib files.
This screenshot shows how I run the command and what error I get.
Try running link.exe from the directory that contains the .lib file. You can use the full-path to link.exe if you don't have it in your path.
Related
From the download sqlite.org/download, they provide Precompiled Binaries for Windows for both x86 and x64.
So, what gets downloaded is a .def file and a .dll file.
Using this two files you can create the .lib file.
[Command: lib /def:yourfile.def /out:yourfile.lib]
On creating the .lib file and using it as a dependency, things are working fine for x86. But for x64, Visual Studio is showing the error:
LNK4272: library machine type 'X86' conflicts with target machine type 'x64'
Is anyone else facing this?
Found out where I was going wrong.
While creating the .lib file, we should be using the following command:
lib /def:sqlite3.def /machine:X64 /out:sqlite3.lib
I was skipping the /machine:X64 option before.
Better to see what are all the options provided by a command.
Example:
lib /?
The output will be:
usage: LIB [options] [files]
options:
/DEF[:filename]
/ERRORREPORT:{NONE|PROMPT|QUEUE|SEND}
/EXPORT:symbol
/EXTRACT:membername
/INCLUDE:symbol
/LIBPATH:dir
/LIST[:filename]
/LTCG
/MACHINE:{ARM|ARM64|EBC|X64|X86}
/NAME:filename
/NODEFAULTLIB[:library]
/NOLOGO
/OUT:filename
/REMOVE:membername
/SUBSYSTEM:{BOOT_APPLICATION|CONSOLE|EFI_APPLICATION|
EFI_BOOT_SERVICE_DRIVER|EFI_ROM|EFI_RUNTIME_DRIVER|
NATIVE|POSIX|WINDOWS|WINDOWSCE}[,#[.##]]
/VERBOSE
/WX[:NO]
I'm trying to use ffmpeg in my C++ project on VS2010, and the ffmpeg dev version provides the lib of .h files. I linked these .libs in my projects and the corresponding .dlls are required when running the .exe file. But I want to link the ffmpeg lib statically and running without .dlls.
I tryed to compile the ffmpeg source code on windows with Mingw, only resulting on some .a archive files. How to get ffmpeg static .lib files? And it's a 64bit program so 64bit static lib is required.
In your output directory, you have some *.def files. You can use these files to get your *.lib files. The syntax is:
lib /def:avcodec-54.def /out:avcodec-54.lib
Use the lib.exe of your VS version. Mine is located in C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin. Check the command line options (it way be useful to add /machine:i386).
Another way to do this: instead of using windows's cmd directly to start msys/mingw, first start VS command prompt (you can start it from Start menu). It will set some environment variables. From here, compile FFmpeg with msys/mingw: FFmpeg build will autodetect that VS is present, thus will auto-perform the libcall.
Edit: Sorry, I skipped the "static" part of the question. Here are some tips for a static build (note that I've never build a static FFmpeg used inside visual studio, so maybe it will not work).
First, of course, FFmpeg must be built with the static options: just to be sure, I use these options, so I have no .def of shared files:
./configure --enable-static --disable-shared [other options]
In order to have statically files, you may directly use the .a files (again: I never thried this). Check this question.
If it does not work, you can try the visual studio toochain instead of gcc. But be careful: last time I tried this (but a shared dll), FFmpeg decoding was slower when build from msvc than gcc's output. Check this page for detailed build instructions.
I use PDB files built with "Program Database for Edit And Continue (/ZI)" for Debug builds, which generates PDB files, as I want to be able to step into source of libraries I'm using in a project when debugging the project. When using DLLs with PDB files, according to MSDN, the compiler looks for the PDB files in the folder where the DLL (or EXE) files are. But I also have components that are static LIBs rather than shared. I usually set the compiler to generate PDB files named with the project, rather than the platform (the latter being the default) so I can move them around without filename conflicts. But where should I put these PDB files from the static LIBs? Do I put them in the same folder as the LIBs are? I keep my built LIBs in a different folder than the executables, as I have a folder hierarchy something like \bin \include \lib \data.
You should copy the PDBs to the same location as the LIBs they are associated with. When the linker is run to produce a DLL or EXE from the LIB, it will use the LIB PDB to produce the PDB for the DLL or EXE.
You can use Post-Build Event to add command-line operations to copy the LIBs/PDBs around after each build.
I am using dev c++ IDE which used ming gcc(i am not sure of it)
I wanted to use sqlite3 in my win32 c application
I downloaded sqlite3.dll and sqlite3.dev and used dlltool to create a .a file like libsqlite3.a and pasted in the lib folder of dev cpp and added this path in the project options -> parameters
i copied the header file sqlite3.h into the include folder(which i got from another website - http://www.opensource.apple.com/source/SQLite/SQLite-74/derived_source/sqlite3.h)
i executed the program and got the message 'the program can't start because sqlite3.dll is missing in your computer'
so i copied the sqlite3.dll into my working directory and then it worked
BUT
How to make the sqlite.* static while compiling?
I mean i thought by including the libsqlite3.a, the final exe will not be dependent of any external dll's.
So i want to know how to compile in a way that i will not be needing a dll and by doing so it makes my windows program standalone.
do i have a create a .lib file instead of .a file?
EDIT after answers and comments:
Besides, the devpak is working fine... yet i wanted to know how to include files to project or to create .a files so i am trying this way because if some components do not provide devpak then this will be the way we need to compile.. isn't it?
EDIT to show what i have done after the answer by CL and the two comments
This is how i have added the sqlite.c to project list
Here is the compile log
Compiler: Default compiler
Building Makefile:
"C:\Users\jayapalc\Documents\test-sqlite\Makefile.win"
Executing make...
make.exe -f "C:\Users\jayapalc\Documents\test-sqlite\Makefile.win" all
g++.exe -c sqlite3.c -o sqlite3.o -I"lib/gcc/mingw32/3.4.2/include"
-I"include/c++/3.4.2/backward" -I"include/c++/3.4.2/mingw32" -I"include/c++/3.4.2" -I"include"
sqlite3.c: In function `void strftimeFunc(sqlite3_context*, int,
sqlite3_value**)':
sqlite3.c:14727: error: invalid conversion from void*' tochar*'
The files i got in sqlite.org/sqlite-amalgamation-3071502.zip are
shell.c, sqlite3.h, sqlite3.c, sqlite3ext.h and i saw in other discussions that shell.c is not needed...
Besides, people were talking about gcc and g++... .
Apart from updating Dev-C++ itself, try this to compile sqlite.c as a C file:
Go to Project >> Project Options >> Files.
Find the C file we're talking about. Untick "Compile file as C++".
This should inform Dev-C++ that it should invoke gcc.exe, and not g++.exe.
If you don't want to compile sqlite yourself by adding it to your project, you can try passing the -static flag to GCC/G++ to force it to link libsqlite.a statically.
Just include the sqlite3.c file in your project.
You need only this filed, and it must be compiled as C, not C++.
Apparently, Dev-C++ does not allow mixing C and C++ source files in one project.
Instead, you could try to compile sqlite3.c as C and then include the generated .o file into the C++ project (on the Linker page).
I am having a linker error LNK 2001 unresolved external symbol.My point is I do have the respective include directory added under Project Settings->C/C++->General ->Additional Include .I see that this include directory does have the header file which contains the function which is causing the error.
I also add all the lib folders under linker options->general->additional lib dependencies.
What could be going wrong? How can I trace what file is missing?
You need more than just the library path, you need to specify the libraries explicitly. i.e something.lib
(under Linker->Input->Additional Dependencies in VS2005)
Linker errors have nothing to do with include files. You get compiler errors from missing include files/directories. The linker needs the actual definitions aka code to work its magic and create your binary file (exe/dll/static library etc...).
Are you linking to the library of which you are #includeing the headers from?