When we are using delphi-10 exe we are getting below issue,but i couldnt find this file in my machine where I installed delphi10
"This application failed to start becuase rtl140.bpl was not found.Re-installing the application may fix this problem"
Your executable is compiled with runtime packages and requires them to run; you should deploy them on the target computer during installation. Alternatively, you could turn off runtime packages (compiler options) and have a stand-alone executable.
On a computer where Delphi is installed the runtime packages should be installed in the system directory; Delphi IDE itself is compiled with runtime packages.
Related
I wrote a Win32 VCL application in Delphi 11.1 Alexandria, the application uses runtime packages that I also wrote myself. The application runs correctly on my development machine.
I'm now trying to remote debug this application. The remote debugger (paserver) is setup correctly on the second machine (windows 10).
When I try to run the application, the deployment process starts and copies runtime packages from c:\program files (x86)\embarcadero\studio\22.0\bin\ and C:\Users\Public\Documents\Embarcadero\Studio\22.0\Bpl\ but stops with the error:
[Error Error] Required local file "MSTools280.bpl" not found. Deployment failed.
MSTools is one of the custom built packages. In the build event I copy the bpl to C:\Users\Public\Documents\Embarcadero\Studio\22.0\Bpl\ so it should be visible to my local machine like the other runtime packages.
Both the packages and the application are compiled with Debug Information = True and Include remote debug symbols = True
I have tried to build a little test application without the custom packages and the remote debugging works correctly for that application.
What can I do to make this work correctly with my custom packages?
I have tried having the WebView2Loader.dll in the same directory as my executable. And I have also instead to tried to download the evergreen build from https://developer.microsoft.com/en-us/microsoft-edge/webview2/ and install it into my system (and have LoadLibrary find the DLL there instead)
In both cases the following happens. In my 32bit executable builds everything loads and works fine. In my 64bit executable my code:
Windows.LoadLibrary(PChar('WebView2Loader.dll'))
Gives this error:
%1 is not a valid Win32 application
I am on latest Windows 10 64bit
Any ideas what I can try...?
I installed the ISE from Xilinx to my windows PC and it ended up very bad. It isn't working, since when I try to run it, the next message appears Warning: VC++ 2008 runtime libraries are not installed. Please install the runtime libraries by running the redistributable {Install Root Dir}\common\bin\nt64\vcredist_x64.exe from the installed area. You will need to have adminstrative privilege to run VC++ 2008 Redistributable.
Obviously I went to the directory, run as administrative, repaired the C++ libraries, but nothing changed, it still failed to open.
I've uninstalled my RAD Studio 10.2.2 and installed 10.2.3 in my Win10 development VM. Along the way I uninstalled all the previous 3rd-party libs, including the Jedi GetIt packages, and per the instructions got rid of all the old Jedi source and DCP/DCLs. I'm attempting to install them back into 10.2.3 via GetIt. The JCL libs install fine, but when I try to install JVCL, the installation batch file hangs after compiling the installer and the VM comes to its knees. I rebooted, started taskmgr and watched as the batch file ran - it appears to go into a loop creating many instances of msgfmt. I've tried removing it all again, downloading and installing the 3.8 version myself and running the install batch file by itself, same problem; then backing up to the 3.6 version that had installed OK in 10.2.2, and it does the same thing. If I edit the batch file to skip the language-setup section, the batch file completes OK, but trying to re-run the GetIt update causes it to re-download and replace that batch file. :(
The installer does compile before the languages part of the batch file is reached, so I tried running the installer directly. I assume I'm not passing it cmd line info it needs, because it compiles the 64-bit libs fine but chokes immediately on compiling the 32-bit version of JvCore250.bpl with an unspecified compile error.
Anyone else run into this? Is a solution known?
Turns out to ultimately be a pathing problem. When multiple installations of the IDE exist on a machine (e.g. my VM has or previously had D2007, XE2 and 10.1 on it), the PATH environment variable can be too long - edit the PATH in the system to remove the old/stale paths. Then make sure that the library paths in the IDE includes $(BDSLIB)\$(PLATFORM)\release or you'll get "can't find RTL" when building the packages.
For me the problem is generated from the msgfmt.exe of dxgettext.
msgfmt.exe generates multilanguage messages, for a multilanguage support of jvcl installation.
For the specific problem of msgfmt.exe try to see this: dxgettext and Windows 10
I resolved the problem opened the install.bat file in jvcl folder, and I commented (with ::) every line where the msgfmt is executed.
Attention:
If you use getit I suppose you have to open the folder where jvcl is downloaded and search install.bat (I didn't use getit)
Instead I downloaded jvcl directly from github in my component folder, and I did what is written above in that folder.
Recently i got a chance to work on delphi 7. I just created a sample application which display a welcome message and that exe is working fine on Delphi machine. if i moved that exe to non-delphi machine(where delphi is not installed), it is throwing error as "The program can't start beause rtl70.bpl is missing from your computer. Try reinstalling the program to fix the problem".
if i follow the same process with Delphi 5, it is working fine.
You have built the program to rely on runtime packages. That means that each machine that needs to run the program needs to have the runtime packages available.
There are two solutions:
Distribute the runtime packages that you use alongside the executable.
Disable runtime packages and so build an executable that contains the runtime.
The runtime packages options are determined by settings specified in the project options.
Unless you have some compelling reason to use runtime packages, the second option is much simpler because it allows the executable file to stand alone, with no external dependencies.