Trying to link from a .dll file in Windows.

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?
Last edited on
What happens if you type
g++ main.cpp C:\Users\User\Desktop\precision.dll
(That is, without the '-l' ).


Failing that,
Open a command window.
Type dir C:\Users\User\Desktop > out and hit enter.
Then paste the file out here, please.

Last edited on
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 built a simple mylibrary.dll file using the prescription given in
https://www.transmissionzero.co.uk/computing/building-dlls-with-mingw/

I then compiled and linked a test file with
g++ main.cpp c:\test\mylibrary.dll
(without the '-l' option)
and it worked fine.

I guess it may depend how the original .dll file was created.
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

Directory of C:\Users\User\Desktop

01-Jan-19 12:23 PM <DIR> .
01-Jan-19 12:23 PM <DIR> ..
12-Nov-18 04:21 PM 1,007,244 Animation.blend
04-Aug-16 07:03 PM 1,975 ATI System Monitor.lnk
25-Jun-16 06:10 PM 1,654 Audacity.lnk
14-Jun-18 05:38 PM 1,160 Blender 3D.lnk
30-Dec-18 01:32 PM 979,840 bookmarks.html
22-Dec-18 05:31 PM 153 Christmas Presents for Self.txt
09-Aug-17 07:53 PM 1,907 Comodo Killswitch.lnk
17-May-16 07:22 PM 1,035 DBDesigner 4.lnk
13-Nov-15 02:13 PM 1,266 Defragment.lnk
01-Jan-19 12:16 PM 1,076 Dev-C++.lnk
11-Dec-17 02:35 PM <DIR> Development Software
17-May-16 07:22 PM 1,229 DHTML Menu Builder.lnk
06-Oct-18 05:48 PM 1,481 dllChecker.lnk
03-May-17 03:42 PM 1,071 EitherMouse.lnk
10-Nov-18 01:11 PM 1,147 FormBuilder.lnk
15-Oct-18 02:35 PM <DIR> Frog
22-Oct-18 08:27 PM 951 GIMP.lnk
02-Jul-16 01:44 PM 872 Handbrake.lnk
13-Nov-15 02:13 PM 1,900 HTML Kompozer.lnk
17-May-16 07:22 PM 2,098 IJ Scan Utility.lnk
28-Jul-18 01:03 AM 1,330 Internet Explorer.lnk
28-Oct-17 11:50 AM <DIR> javadoc Creation Directory
08-Aug-15 03:54 PM <DIR> jd-gui-windows-1.4.0
01-Jan-19 12:23 PM 382 main.cpp
16-May-18 10:24 PM 1,417 Microsoft Edge.lnk
01-Jan-19 12:11 PM 364,932,326 MinGW-64.zip
27-Jul-16 11:13 PM 1,662 Mozilla Thunderbird.lnk
31-Dec-18 09:26 PM 12,978 Notes.txt
24-Apr-18 12:14 PM 1,038 OpenOffice Calc.lnk
24-Apr-18 12:14 PM 1,046 OpenOffice Impress.lnk
24-Apr-18 12:14 PM 988 OpenOffice Math.lnk
24-Apr-18 12:14 PM 1,060 OpenOffice Writer.lnk
01-Jan-19 12:23 PM 0 out
17-May-16 07:22 PM 1,256 Paint.lnk
29-Dec-18 04:03 PM <DIR> precision
29-Dec-18 04:03 PM 111,047 precision.dll
29-Dec-18 03:32 PM 1,280,018 Precision.zip
31-Dec-18 12:53 PM <DIR> Present Matters
12-Nov-18 09:00 PM 142 Property Suburbs.txt
12-Oct-17 04:45 PM 1,026 Putty.lnk
08-Oct-17 04:23 PM 2,021 Razer Synapse.lnk
30-Oct-17 11:35 AM 246 Restore MBR et al.txt
22-Oct-17 11:39 AM <DIR> Resume Material
13-Nov-15 02:13 PM 262 Run.lnk
10-Nov-17 01:18 PM 858 SpeedCrunch.lnk
28-Nov-18 11:50 AM <DIR> Web Page Downloading
12-Jun-18 12:11 PM <DIR> Weekly Finance Projections
17-May-16 07:22 PM 1,104 Windows Explorer.lnk
28-Jul-16 03:03 PM 1,835 Windows Media Player.lnk
04-Nov-18 01:48 PM 1,526 Wise Uninstaller.lnk
21-Oct-17 04:24 PM 1,659 WordPad.lnk
42 File(s) 368,365,286 bytes
11 Dir(s) 44,386,365,440 bytes free

****************************************************************
Compilation attempt error message:

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?
Last edited on
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 ...
Last edited on
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?
Last edited on
If you don't have the library and do not know the protoptypes then the only way is to reverse engineer the DLL.

Even LoadLibrary/GetProcAddress wont work ( it will work, but most likely crash )

You say that this "celebre" dll is public domain, how it is so that the source code for it is not available ?
Last edited on
@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).
Last edited on
OK, @powerusm, let's take a guess that this library actually comes from here:
http://www.hvks.com/Numerical/arbitrary_precision.html

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.


or the use of windows.h

Why on earth would you need windows.h?
Last edited on
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:

https://www.learncpp.com/cpp-tutorial/a3-using-libraries-with-codeblocks/

-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?

Last edited on
.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?
Last edited on
A library if is written in C it usually works with another compiler ( not always ).

If it is written in C++ there is no way to work when linking with another compiler due to different calling conventions between them.

Of course there are 32 bit and 64 bit libraries, it must match exactly your bitness executable.

There is no such thing as creating a header file from an DLL ( binary ) without reverse engeneering.



A DLL is NOT a library, it is a binary, just like an executable.
-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.)
Last edited on
closed account (E0p9LyTq)
-If I simply rename a .a file as .lib, will everything be exactly the same, and run as described?

No. Entirely different compilers, entirely different layout of data in the library files.
My 'point of view' is the 64 bit Windows TDM compiler (stable version).
And the Dev-C++ environment.

-so from there, with an .a file, I can update the linked with -l to it, and do an #include to the .a file's header?

-With this being the case, what exactly does this assertion mean:

No. Entirely different compilers, entirely different layout of data in the library files.


?
Last edited on
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.
Topic archived. No new replies allowed.