I need to build old components made for BCB6 (Borland C++ Builder 6) in Embarcadero RAD Studio XE5. Projects are CPP- projects, and the component code is contained in the *.PAS - files.
The project contain 6 packages:
three packages a design time
three packages runtime
First I build packages runtime. After that I start building and installing the packages design time that use packages runtime. And one design time package has a problem during installation:
I found a runtime package that causes this problem. My question is how do I find and resolve the following error? After all, when the package is installed, I cannot start the debugger, see the stack trace, nothing at all. What are the options? Thanks.
For that you need to run a second instance of the IDE in the debugger:
Uninstall the packages
Compile all packages with debug information
Load the project of the runtime package that causes the problem
In Run -> Parameters Set the Host application to $(BDS)\Bin\bds.exe
Press run with debug
This will start a second instance of the IDE. You might have to ignore some exceptions that it internally raises (and handles).
In that second instance, load the design time package which loads the runtime package that causes the problem
Hopefully you will now see what happens
Related
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.
I have a designtime package which is installed in the IDE and uses classes and functions defined in a runtime package.
Each time I compile or build the runtime package, it seems that the designtime package is automatically reinstalled.
This operation starts after pressing the "Ok" button of the "Compiling window" and takes a several seconds.
Is there a way to avoid this?
You cannot avoid that. The designtime package depends on the runtime package. When you recompile the runtime package it has to be unloaded and reloaded to make the new compilation effective. Unloading the runtime package requires all dependent packages to be unloaded before. At least the IDE is clever enough to automatically reload the dependent packages after loading the new runtime package.
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.
i have this problem: i compile and run application and all work in mine computer. When i try to run same application in other computer, i have error about rtl150.bpl not found.
I have searched on internet and all response that i have had tell me to verify if in PROJECT->OPTION->PACKAGES is checked: "BUILD WITH RUNTIME PACKAGE".
It is checked, i compile project but i have same every error. I have saw too that executable of application is very small for example: 186 KB, when usually it was about 2000 KB.
I use delphi xe and not know as i need to do for solve it.
Please, someone can help me to solve this problem?
Thanks very much.
If you build with packages you must distribute the packages (.BPL files) your application uses.
If you don't build with runtime packages you won't get this error.
The list of packages you must distribute is semi-colon delimited list next to the check box for Build with run time packages in the project options.
The Size of an Executable will drop when building with Runtime packages. That is because the code is now in the BPL/Package. But that means your application now needs these additional files. Think of a Package as a specialized DLL that has been renamed.
My Delphi7 project will not run on my clients computer if i don't have a few of the runtime packages in the path. eg rtl70.bpl
I have Build with runtime packages unticked, so shouldn't they be complied into the exe?
Edit: the Project uses Jedi Packages (TJvPlugin) and running the program with out any plugin installed works fine. As Soon as i add a Plugin, the bpl not found errors reappear. Seems like ill have to live with the extra packages.
It has been a while, but it seems like there was something where you needed to (1) check build with runtime packages, and then that enables some other editor (maybe list of packages to use), and you (2) make a change there. (3) Then do a full build, and then (4) remove the runtime packages check and do another (5) full build. It is important to do a full build each time.
From memory:
1. check the build with runtime packages
2. Remove all the run time packages from the list
3. Full build
4. Uncheck the build with run time packages
5. Full build.
Can't test, don't have D7 anymore...
Your project may use DLLs or COM objects that have been built with Delphi packages.
You also need to uncheck the "Use Dynamic RTL" on the Linker tab of the Project Options.
Caveat: I'm using C++Builder, but I believe the options are the same.
One may find this obvious, but check the size of the executable once you've compiled, if it's larger, it'll run. When we manually copy in our updates a smaller dll is a big red flag that something is wrong with the project options.