I am using Windows 10 64 bit Home Edition.
I amd using the 64 bit TDM compiler.
I am using Dev-C++.
I am trying to carry out the following command from the Dev-C++,
and am getting an error message that I can't fix. I am attempting
to submit the following as a Linker command, and am only being told
that the compiler/linker "can't find". I have been led to believe
from this forum that the more recent C++ compilers are capable of
linking directly into .dll files, without .h or .lib files involved.
I want to accomplish the following effect:
g++ main.cpp -l C:\Users\User\Desktop\precision.dll
I am updating Dev-C++ with:
-l C:\Users\User\Desktop\precision.dll
so that I can compile main.cpp, which has the line
trying to access an internal class inside the .dll:
#include "fprecision.h"
When I try this from the command line, I am getting:
C:\Users\User\Desktop>g++ main.cpp -l C:\Users\User\Desktop\precision.dll
C:/Program Files/TDM-GCC-64/bin/../lib/gcc/x86_64-w64-mingw32/5.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lC:\Users\User\Desktop\precision.dll
collect2.exe: error: ld returned 1 exit status
Am I using the correct 64 bit Windows compiler to achieve this?
What am I doing wrong/not telling Dev-C++ correctly? Can someone
steer me to a clearer direction, please?
Are you sure GCC does understand .dll files ?
Normally the extension for a dynamic library is .so
Since you have a .dll it seems it was build with a different compiler / linker
I am using 64 bit Windows 10 Home Edition.
I am using 64 bit TDM 4.9.2.
I am using Dev-C++.
I don't have the option to use any version of MS Visual Studio.
****************************************************************
Contents from the out file:
****************************************************************
Volume in drive C is Zachary
Volume Serial Number is 1E55-3A23
C:\Users\User\Desktop>g++ main.cpp C:\Users\User\Desktop\precision.dll -o make.exe
main.cpp:6:24: fatal error: iprecision.h: No such file or directory
#include "iprecision.h"
^
compilation terminated.
****************************************************************
I am trying to do #include, or a one line equivalent, straight from a 64 bit .dll file.
Failing that, I wish to do the same with a 64 bit .lib file. All without any adjoinging
header files.
Can anyone tell me why my .dll file can't be used plain and simply?
Well, it is now happy to find precision.dll, so that's a start.
Where have you put the header file iprecision.h? That will not be inside precision.dll: only the function definitions will be in the latter. iprecision.h is a separate file: it won't be found "inside" another.
iprecision.h isn't among the list of files on your desktop, so where have you put it? You do have a directory called precision on your desktop. See if you can find it in there. There will probably be other header files too ...
There aren't any .h files to be obtained. From what I have been learning, there are various (larger) IDEs for C++ that will allow .lib file access to be injected straight into a programming text window. The idea being that the .lib file can be referenced via an IDE setting, and #include used to access such a class (as per an adjacent, #included .cpp class file) again.
-I would like to know if there is an easy way, inside a graphical program or utility, excluding MS Visual Studio or its Runtime, to simply have a Windows 64 bit *.lib file generated.
-I would then like to #include (or similar, via a short reaccessing statement) classes inside that .lib, so that I can compile direct calls to the class to compile, link, and run.
-Without resulting to complex calls or the use of windows.h, is there an automatic (or graphical IDE) way that I can do this (also without any .h or other adjoining files) for classes in a 64 bit .dll, or is such ease of class loading, from .dll files, impossible? Is there someone who might be able to respond with particular answers?
@poweruserm, perhaps you can provide a link to this particular library, so that we can see what files are needed. Where did you get the file Precision.zip from?
What is actually in the "precision" directory that is on your desktop?
Please post your main.cpp file (also currently on your desktop).
The download link is in the middle of the page and yields Precision.zip.
Unzipping this gives a Precision directory containing the following files:
Arbitrary Precision Math Packages.pdf
complexprecision.h
fprecision.h
intervalprecision.h
iprecision.h
precisioncore.cpp
There are the original source files (.cpp) and headers (.h).
So why are you trying to use some .dll file?
Let's look at some other things you have been saying.
There aren't any .h files to be obtained.
Well how exactly do you expect any other program to know the prototypes of the library functions?
From what I have been learning,
Where and from what have you been "learning"?
there are various (larger) IDEs for C++ that will allow .lib file access to be injected straight into a programming text window.
What?
#include used to access such a class (as per an adjacent, #included .cpp class file)
#include <somefile> will effectively put that separate file into the code you are compiling. <somefile> is commonly a header file (extension .h) containing prototypes. It won't be extracted from a .dll or anything else. It is a separate file, which must be accessible.
The header contains the declarations (i.e. prototypes, or calling sequences of functions); this is needed by the compiler to compile the procedures that call them.
The definitions of functions may well be in a separate source file, or imported from a .dll file. These separate files are needed by the linker.
I am trying to avoid the situation where you have to use the code in windows.h to access a class inside a .dll whatsoever. That approach is simply to time consuming for my purposes. I also need to avoid Visual Studio for what I am aiming to do.
I am now updated a bit. The library that I am trying to focus on is named MathGL. In this instance, notwithstanding a bunch of .a files, they provide (in the includes) their header, .h or class files, alongside .dll files in the other directory. I am (hoping) to use the .dll files, but very directly.
Most of the time, windows libraries all suplly header files and .dll files.
I have been trying to work from the images, the example which is viewable from the top of this webpage:
-Once I have gone #include on the particular header that I want, how do I update Dev-C++ (or the compiler) with the .lib files? Or in fact in this real case, with the .dll files? So that I can code with classes directly from there, without any other (class assisting code or source code ceremony). Such that my classes will instantiate and compile and run in a main method? Can someone give me an example using links to at least 2 library files?
-In the case that this all can't happen directly with 64 bit .dll files, is there a direct and easy way to create 64 bit windows .lib files? How are they created at all?
.lib files are usually created with visual studio compiler, gcc on windows creates .a files ( they are equivalent ).
Libraries are created the same time with dll's. You include header files in your application, link with provided library files and only then for your application binary to run it also requires dll's in the same folder as the executable ( for shared linking at least ).
You seem to have a huge lack of understanding how to compile, link and run an application.
My issues are just to do with library/class access. Now that I must always use a .h header file via #include and a unix style path name,...
-If I simply rename a .a file as .lib, will everything be exactly the same, and run as described?
-If, when it comes to a .dll library, in my main method file, I #include the correct class header,
and -l update the linker to the location of that .dll file, then will everything also run as described, similar to a .lib (.a ?) file?
-Are there 32 bit .lib files and 64 bit .lib files, or in fact not?
-The final thing is, is there an option or utility via TDM or Dev-C++, or a public domain
Windows utility, that will produce a .h file for .cpp classes destined for a .a file?
Could someone give a command line for such to produce the .h file from a .cpp file?
-If I simply rename a .a file as .lib, will everything be exactly the same, and run as described?
-If, when it comes to a .dll library, in my main method file, I #include the correct class header,
and -l update the linker to the location of that .dll file, then will everything also run as described, similar to a .lib (.a ?) file?
-Is a .lib file always multiplatform, or is it heir the the platform that a Windows/Linux compiler has defaultingly compiled it for?
(I just need someone to confirm my logic on these points.)
Everybody (including me) keeps telling you the same thing in different ways. I'll try to elaborate a bit.
As you know, there are various companies and entities that produce C++ compilers and associated build systems. Some of the best known ones of course are Microsoft's VC++, GCC Open Source compiler (TDM , which you use is one version of that), and Intel's compiler. All these entities and companies attempt to implement the evolving C++ Standards. For example, if you create a class in your source code and compile/link it with GCC, chances are very, very, very good that you could take that source code text file and successfully build it with MSVC or Intel's compiler. If there's nothing platform specific in your class you could very likely build it on a Linux or Unix system, or any other platform for that matter that closely provides a C++ Standard build system.
However, we're talking textural source code here. As you know, source code must be converted to binary op codes for the processor to execute it. Let's think about what happens when your compiler encounters one of your classes that you've created. Let's assume you've created a class that has three member variables of 8 bytes each (maybe three doubles. Let's further assume the class has three member functions or methods. Here are some of the ways a compiler might implement this at the binary level....
1) It might do a memory allocation for 48 bytes and place function pointers to the three member functions in the 1st 24 bytes, and put the three doubles in the 2nd 24 bytes;
2) It might do the reverse, i.e., member variables in 1st 24 bytes and function pointers in 2nd 24 bytes;
3) It might just allocate 24 bytes for the member variables, and create a Virtual Function Table (VFT) somewhere else in memory containing function pointers to the member functions.
4) It might do something else entirely.
The point being, there is nothing in the C++ Standards that specify how a C++ compiler implementor has to implement the C++ language at the binary level.
So, assume you have a dll created by MSVC and it exports a class. Further assume that when Microsoft wrote the compiler they decided to store member variables of the class at the base allocation for the class. Then assume you somehow successfully link to the dll with GCC which might expect to find a virtual function table at the base allocation for the class. What do you think will happen at runtime if you call a function and random op codes in the member variables execute? Nothing good, I can tell you that.
If lastchance is right about the code and download you are referring to, I don't see why you don't just build the library with the compiler you are using and then everything will work for you.
This is a tricky issue that I believe a lot of folks don't understand. A very, very good discussion of the issue can be found in the 1st chapter of Don Box's book "Essential COM" published by Addison-Wesley, 1998. The title of the 1st chapter is "COM As A Better C++". Don Box is a Microsoft fellow and works on .NET, COM, OLE, language interoperability and such things.
I believe the book can be downloaded free from various websites. Do a search on it and I believe you'll find it.