In BDS 4.0 I've build a VC-Style DLL, I want that this DLL includes all packages in order to be independant as well, I can use it and deploy it even on PC that haven't the Borland RTL installed.
(I've BDS in a Virtual Machine and VC++ on my host computer).
So, I modified compiling options like this:
Uncheck the use of dynamic RTL
Check "Build with execution packages:" and list all packages that I want to include (rtl, vcl, ...).
But when using this DLL in VC++, LoadLibrary fails and ask to me to add rtl100.bpl, vcl100.bpl, ... in the package.
If I copy all BPL that are on my virtual machine to my host computer, LoadLibrary works.
How can I include all these packages in my C++Builder DLL?
You have uncorrectly checked "Build with execution packages" option. When it's checked, all listed packages are linked dynamically so you'll need to distribute *.bpl files with your application. If you uncheck this option, all packages will be statically linked into your dll
Related
I have the same problem as described here:
https://github.com/NLua/NLua/issues/33
Though I have followed the instructions to create a console application...
http://www.screencast.com/t/M12TqePQxW
...which works just fine, when I create a library project and reference it from another project (in this case, a Web API project) the following error occurs:
Unable to load DLL 'lua52': The specified module could not be found.
At this line:
using (var lua = new Lua())
How can a library project be made with the NLua nuget package without failing?
It is the exact same issue as described in the GitHub issue, the Nuget package is missing two DLLs that you need to use lua52.dll. One small difference, the current package (version 1.3.2.1) includes a newer version of lua52.dll that was built with VS2013. And therefore has a dependency on msvcr120.dll and msvp120.dll.
Beware that this may change in the future when Nuget updates your project.
As-is, you need to download and install the Visual C++ redistributable package for VS2013. Run both vcredist_x64.exe and vcredist_x86.exe so your project can run either in 32-bit or 64-bit mode.
To avoid having to do this on the machine on which you want to deploy your program, I recommend you copy the two DLLs from the c:\windows\system32 (64-bit) or c:\windows\syswow64 (32-bit) directories into the same directory as your EXE.
The package author could have done a better job putting this package together. Short from including the DLLs in the package, the better solution would be for him to rebuild lua52.dll with the /MT option so these dependencies are linked in. Consider clicking the New Issue button to let him know.
I've written a Windows program using the C API of Tcl/Tk to create a nice GUI. I've installed ActiveState ActiveTcl for the dependencies and everything compiles and runs fine. Compiling required me to link against the import libraries provided by ActiveTcl.
Now that i want to distribute this program i have to make a choice on how to handle the dependency on ActiveTcl. One option is to require ActiveTcl be installed before my program, while another is to just distribute the ActiveTcl DLL's that my program actually uses.
If i view my program using a Dependency Walker i can see that three ActiveTcl DLL's are used. tcl86.dll, tk86.dll and zlib1.dll. So then i tried to move the DLL's.
If i moved these DLL's to the C:\Windows folder or to the program's folder, the program no longer functions. After moving the DLL's and viewing the program in the dependency walker, i can see the DLL's are being found in these alternative locations but the program refuses to start. I don't even get an error.
Do any of you guys know why this might be the case? That the only time my program runs is if the DLL's are located in the installation directory of ActiveTcl (C:\Tcl\bin).
The DDL's had dependencies of other files that should exist in the same folder.
I use API to make a programs. It runs pretty well on Windows 7 (with debug file .exe), but it doesn't when I run it on Windows XP. Are there any ways to solve this problem?
I suppose you are using Visual C++, according the the message you get.
Your project is set up (by default) to link the Microsoft C++ Runtime Librairy dynamically, so it saves up space in your final executable, but you need the dynamic linked libraries to be in your system or in your executable's folder.
To solve this in Visual C++, without any afford from who are executing the program in their machines, you can change how MSVC link their runtime library to your executable, that is, if you set it to be linked statically, all the dependencies will be linked inside your final .exe, with no need of additional .dlls.
To change this option, refer to /MD, /MT, /LD (Use Run-Time Library) - MSDN.
Or in short: Project Properties>Configuration Properties>C/C++>Code Generation>Runtime Library
If in debug mode, use /MTd, otherwise use /MT.
I am trying to make a program that works on every operating system by forcing it to load and use the DLL's in the current directory, not the windows directory, but it don't works. I tried to enable "copy local" and change the refference path, but without any success, the program tries to load the DLL's from the windows directory.
My question is: how can I fix this?
The Search Order for DLL's is documented here on MSDN. It also includes instructions on how you can modify the search order so that the local bin directory is searched first, instead of the GAC.
The directory %windir%\assembly is called the GAC. Assemblies are not copied there, but installed typically using gacutil /i or by installation packages.
GAC is a suitable folder for libraries referenced by lots of other libraries and applications in build versions that are not centrally coordinated. Using GAC allows you to have multiple versions of the same library, all of which might be indirectly required even by a single application, installed side by side on the system. Case in point is the .NET framework itself.
The assemblies that you build are probably not that kind. Application assemblies and libraries that are basically part of a single application should never make it to the GAC or you can get into trouble. There is a variety of possible trouble:
one accidentally or intentionally creates different (incompatible) builds of the same library with the same version number.
assembly in GAC references an assembly not in GAC
one app installs the same assembly into GAC, but another app wants to load it from its local folder (where application binaries reside).
Code in the GAC gets a preference when assemblies are loaded. To remove an assembly from the GAC, use gacutil /u.
I have already built a project, and run it in VS2010.
But if I want to run the .exe on other computers which does not
install Visual Studio, it will need .dll files (such as msvcrt.dll and
msvcp60.dll in WINDOWS\SYSTEM32, and some other dlls in the
development package). I didn't use MFC in this project. How to static
link all these dlls into the .exe file in Visual C++ so that I don't
have to copy all the dlls to the other machines?
BTW: I don't want to make install package either
Thanks
Siba
You can set your project to statically link the CRT, by using the /MT flag for the runtime library. Or, you could keep the /MD setting, and install the vcredist package along with your executable (you can get it from here, and also from one of your VS2010 installation folders). To get an idea of each options pros and cons, read this.
Oh, and a similar question has been asked before...