According to this question,
Dynamic linking is done at run time, by the operating system.
Until now, using g++ with eclipse CDT, I statically linked odbc32.lib I got from windows SDK to get some ODBC functions to my program. But I deleted the file by accident and was surprised to find my program still running and connecting to the database. Since the file no longer existed the the path I specified to the -L option, I thought it must still exist somewhere in one of the subfolders of the path. But then I deleted the library path to see what happens but my program still works! I began searching for odbc32.lib and I really can't find it. However, I do found a odbc32.dll file located in C:\Windows\System32 and I thought it might be dynamically linked to my program.
If I'm right, How does the compiler find odbc32.dll when I never specified C:\Windows\System32 as my library path?
To test my theory, I began grabbing many .dll files in the system32 folder and linked them using -llibrary. I've managed to link some of the files I got because my program run successfully, but some files can't be found by the linker, why is that?
Am I right? Is this an example of dynamic linking?
Note: I also removed C:\Windows\System32 from my path but it's still, for some reason, working.
From your comments, you stated you are using g++ with cygwin. Basically this means that linking is now done as it is on linux (or unix or whatever) and one library is needed. In your case this is static library so it links upon compilation and doesn't need it again.
Related
When I compile the release target, everything is built correctly and I can run the program via windows explorer (the install script copies all the libraries to the .exe folder).
The problem that I am having, is that the program does not run inside QtCreator (in both debug and release) unless I manually copy the libraries to the .exe folder. This was not how it used to work but somehow, since I upgraded to Qt6 and start to use mingw instead of vc++, this behaviour started to happen.
There is an option in the project tab to "Add build library search to the PATH" that apparently is intended for exactly this reason (sip copying the libraries every time we compile), but somehow this is not working. I see the PATH change in the Environment form, but the program just crashes on loading with a "This application was unable to start correctly". If I copy the libraries and try again, it works.
So it turns out that it can't find just the onnxruntime.dll library. I assume that it has trouble finding any library that does not start with lib from the path. My solution for now was to copy just this file to the .exe folder.
I am creating a project using mingw under windows. When run on another PC (without wingw in PATH, respectively), get errors, missing: libwinpthread-1.dll, libgcc_s_seh-1.dll, libstdc++-6.dll. How can I build the project so that everything starts up normally?
A C++ program needs runtime libraries to run. They're usually not part of the program itself! So you'd need to ship these libraries alongside with your program (which is what most software does).
You can, for many things, however, also use "static linking", which means that the parts of the libraries used by your program are included in your program itself! The -static flag supplied to executable-generating step in your project will do that. If your program consists of but a single file, that would be g++ -o test -static test.c (your g++ might be called x86_64-w64-mingw32-g++ or so).
If your distributed .exe file won't run because of missing .dll files that's because it is linked against those files and you need to distribute these files with your .exe file.
But actually there are 2 solutions to this problem:
Shared build (= using .dll files): distribute the .dll files with your application. The best place to put the .dll files is in the same folder as the .exe file(s). You can use Dependency Walker to figure out which .dll files your .exe file needs (and which .dll files those .dll files need etc.) or you can use the command line tool copypedeps -r from the pedeps project to copy your .exe file(s) along with any .dll files required.
Static build (= everything rolled into the .exe file(s)): when building your .exe file(s) use the --static linker flag (and if needed also -static-libgcc and/or -static-libstdc++). This create a static .exe file, which means all the static libraries are rolled into the .exe file. This may make your .exe quite large (though you can try reducing its size with the strip command or the -s linker flag) and doesn't have the advantage of .dll files where common code is only distributed once. It may also cause longer loading times for your application, since everything is loaded at once.
recently I realized my c++ program was detected as a virus and I think it must be a compiler problem. so I uninstalled my compiler and reinstall it through msys2. the output is ok in my system but when I run EXE outputs created by a new compiler in a Virtual machine or another system I've got this error: libstdc++-6.dll not found
I don't have any idea how to fix this problem. I appreciate any help.
Error Image
Some people call this DLL hell, but that's usually because they don't really understand completely how shared libraries work on Windows.
You can avoid DLL dependancies by building your .exe file with linker flag -static and linking with the necessary dependencies static library files (*.a).
Specifically for the C++ standard library libstdc++-6.dll you will need to specify linker flag -static-libstdc++.
Or you can use shared libraries (*.dll), but then you need to distribute them in the same folder as the .exe file.
I wrote a tool called copypedeps as part of https://github.com/brechtsanders/pedeps to copy .exe files along with all the required .dll files.
Update
I was being foolish - I had a check to see if the file existed (in the same folder) before passing it to dlopen().. so the question is not valid, I will close it.
Original Question
For an exectuable that needs to link to a bunch of shared libraries in a different folder you can just do export LD_LIBRARY_PATH=/some/other/folder and then when you run your exectuable it can find them - and that is all working as expected for me.
However one of my applications uses dlopen() to open a shared library at runtime (in a plug-in like way). I am using dlopen("libsome_lilb.so", RTLD_NOW).
So, this works if the plugin shared lib is in the same folder, but not if its in some other folder. So then I set LD_LIBRARY_PATH and re-try, but it still fails to find the library.
This is related to this question: c-linux-dlopen-cant-find-so-library
But that OP seems to have a varaition of this issue where they are trying to open a .so in the same folder... so I can't see a solution there.
Not quite sure what to tinker with now... maybe some of the options for dlopen("name", options);? (that's a guess)
I made a program with Microsoft Visual Studio 2010. It uses additional libraries (Allegro), and it runs perfectly from MSVC, but I can't run it from it's directory. (...\"project name"\Debug\"project name".exe) It writes that it can't find some kind of .dll files.
That's not good, because I want to make it work for everyone! What to do to make it work?
I know that I have to put the necesarry .dll files, but I don't know where?
When an executable is started, Windows searches the current directory, the PATH and then some other places. The exact description can be found here
You need to make sure either the PATH includes the library you need, or place it in the same directory (or in some other automatically searced directory, but that's typically not a good solution).