Problems installing on Delphi 2009

I have Rubicon setup for 3.998 which should install for Delphi 2009. I have attempted to install but it has failed.

I fixed the DBISAM bridge by modifying the .inc file as instructed and was able to recompile, but am unable to understand how to fix for the other error given the guide that was provided. Can you provide further instructions based on the error log?

I received the following error log:

rbc40_core_cpp_lib package FAILED to compile (Rubicon Core runtime for c16_win32)

rbc40_core_cpp_ide package FAILED to compile (Rubicon Core designtime for c16_win32)

rbc40_b_cpp_lib package FAILED to compile (BDE runtime for c16_win32)

Remedy for Bridge b, when Setup finishes…

  1. Keep Delphi closed

  2. Edit Packages\pkg_src\ in Notepad to correct the library filenames

  3. Recompile by running pkg_c16_win32\dccdpk.bat

  4. Then start RAD Studio

rbc40_b_cpp_ide package FAILED to compile (BDE designtime for c16_win32)

The IDE package usually compiles as soon as the LIB one is fixed.

rbc40_s_cpp_lib package FAILED to compile (dbExpress runtime for c16_win32)

Remedy for Bridge s, when Setup finishes…

  1. Keep Delphi closed

  2. Edit Packages\pkg_src\ in Notepad to correct the library filenames

  3. Recompile by running pkg_c16_win32\dccdpk.bat

  4. Then start RAD Studio

rbc40_s_cpp_ide package FAILED to compile (dbExpress designtime for c16_win32)

The IDE package usually compiles as soon as the LIB one is fixed.

rbc40_d_cpp_lib package FAILED to compile (DBISAM runtime for c16_win32)

Remedy for Bridge d, when Setup finishes…

  1. Keep Delphi closed

  2. Edit Packages\pkg_src\ in Notepad to correct the library filenames

  3. Recompile by running pkg_c16_win32\dccdpk.bat

  4. Then start RAD Studio

rbc40_d_cpp_ide package FAILED to compile (DBISAM designtime for c16_win32)

The IDE package usually compiles as soon as the LIB one is fixed.


Hi - welcome!

It has been a while since I worked with that version of Rubicon and Delphi. A couple of questions first. Do you want Delphi and CPPBuilder support or just one ? Do you want all those bridges B, S, D ? If not, if you toggle them off, you won’t get the error messages. I’m guessing that you might only want Delphi support for the DBISAM bridge ??

Everything in that error log depends on rbc40_core_cpp_lib, cpp being C++Builder.


Thank you for responding. I still have this version bc I have to maintain a legacy system. I only need Delphi installed and, yes, only DBISAM.

Legacy - I get it. :slight_smile:

So I wonder whether the Rubicon DBISAM components are in Delphi even though there are errors about C++Builder?

It should be possible to un-select C++Builder and the other bridges (S dbExpress and B BDE) when running the Rubicon Setup, and also, to turn them off using ZMAdmin to modify the configuration. ZMAdmin.exe is easy to find. In the same folder, you should also find a BAT file which starts ZMAdmin with a custom configuration panel for Rubicon. If you get that started, you should be able to click in a few levels and get to a place where you can disable bridges and most importantly, disable the attempt to compile for CPP.

And, if you find the Rubicon DBISAM components when you start Delphi (i.e. make an empty new VCL Project and then look on the palette), those errors are officially okay to ignore.

Let us know what happens.

PS. If you adjust configuration with ZMAdmin (via BAT), re-run the 3 bat files (with number 1, 2, 3 in their names) that regenerate the compilation instructions; they should create and run in a way that skips CPPBuilder and only tries to get the DBISAM bridge compiled and installed.

I uninstalled and reinstalled so that I could eliminate the issue with CPPBuilder. On reinstall, It seems I neglected to remove the checkmark defaulting to install CPPBuilder. This time I removed it and the install proceeded smoothly; however, it failed for DBISAM, which I understand I need to edit the .inc file to identify the currrent version of DBISAM I have (which is 4.29). So I changed the .inc file and ran the dccDPK.bat file to recompile that. I did not get any new error log, but the rbc40_d_pas_ide_d12_win32.bpl or the rbc40_d_pas_lib_d12_win32.bpl were not then created in the pkg_d12_win32 folder.

NOTE: The HREFTools bridge for BDE, DBExpress (which I needed as well, but no issue compiling that), and core all show in the IDE but are not able to load because the …ide…bpl modules cannot be found. Do I manually need to copy the bpl files for these which did compile to the pf (x86)\codegear\rad studio\6.0\bin folder?

Edit: I try it on my other development computer, making sure not to include CPPPBuilder and get additional and different issues.

During install, I get this error:

Serious warning: d16_win32 compiler not found in registry (HKLM) under SOFTWARE\Embarcadero\BDS\9.0

This is the error log I get at the end:
rbc40_core_pas_lib package FAILED to compile (Rubicon Core runtime for d16_win32)

rbc40_core_pas_ide package FAILED to compile (Rubicon Core designtime for d16_win32)

rbc40_b_pas_lib package FAILED to compile (BDE runtime for d16_win32)

Remedy for Bridge b, when Setup finishes…
0. Keep Delphi closed

  1. Edit Packages\pkg_src\ in Notepad to correct the library filenames
  2. Recompile by running pkg_d16_win32\dccdpk.bat
  3. Then start RAD Studio

rbc40_b_pas_ide package FAILED to compile (BDE designtime for d16_win32)

The IDE package usually compiles as soon as the LIB one is fixed.

I do have RAD Studio 10.3 installed as well, but am not installing Rubicon for that.

D12 or D16? That is what I am wondering now.
“D12” is HREF’s abbreviation for Delphi 2009.
“D16” is Delphi XE2.

Maybe … maybe what is going on is that Rubicon Setup is trying to install for too many compilers. Just like you had to de-select CPPBuilder, you might need to de-select some compilers so that it only tries for D12. If that is not easy during Setup (it should be) then there is a true/false flag for each compiler that you can tweak using ZMAdmin (started by BAT file as mentioned before).

rbc40_d_pas_ide_d12_win32.bpl should, and needs to, end up in the pkg_d12_win32 folder.

Copying BPLs generally does not help. It generally makes things more confusing to troubleshoot when there are multiple copies with potentially different content. I am not saying ‘never’ … just proceed with extra awareness.

Adding a global search path inside Delphi so that it knows where BPL files are – that can help the IDE to load packages. (do that after Project > CloseAll, so you are changing global settings ).

I suspect that the “serious warning” is basically indicating that the rest of the install will have trouble because the root path is unknown. While that should impact only D16, maybe it impacted the setting of the global search paths.

Which time zone are you in? Maybe we should coordinate with a bit of remote desktop support time via AnyDesk or equivalent. Or if you have a million other tasks and are okay doing this async, I am too.

I do apologie for the difficulties.


Thank you for your patience. I’m overcomplicating things by not making sure the correct compiler (Delphi 2009) is flagged and additional default ones are unchecked. I have redone the install and have reduced my problem apparently to just one thing.

First, the bridge files (rbc40_b…, rbc40_d…, rbc40_s… lib and ide) for BDE, DBExpress and DBISAM have all been successfully compiled and all exist in the C:\DLIB9\HREFTOOLS\RUBICON\PACKAGES\PKG_D12_WIN32 folder (DLib9 is where I installed Rubicon). Also, the rbc40_core_pas ide and lib files are there as well.

When I open Delphi 2009, the HREFTools packages fail to load. Under Install Packages area, those HREF packages show, but are not checked on. When I do attempt to check those so those components will be available, I get the error indicating that “Can’t load package. C:\DLIB9\HREFTOOLS\RUBICON\PACKAGES\PKG_D12_WIN32\rbc40_(core or b or d or s)_pas_ide_d12_win32.bpl. The specified module could not be found” although those files do exist in that directory.

Under Tools | Options | Library - Win32, the paths for C:\dlib9\HREFTools\Rubicon\Packages\pkg_d12_win32, C:\dlib9\HREFTools\Rubicon\Packages\source and C:\dlib9\HREFTools\Rubicon\Packages\source\inc all exist. (NOTE: I also tried adding the C:\dlib9\HREFTools\Rubicon\Packages\pkg_d12_win32 folder to the Browing path, but that didn’t help)

So now that it seems all the files are created and supposedly where Delphi should be looking for them, why does it still fail to load those packages? Do I need to copy these files somewhere else as well?

I am operating from Turkey and we can do a remote desktop support hookup if the above does not provide you with enough to guide me further along. Again thanks for your patience.


The Delphi docwiki has a pretty good page about the library paths

It sounds like that is what you have configured correctly in terms of the library search path, but you could check and make sure we are talking about the same configuration choices.

Some further ideas:

  1. It may help if you put the path-to-BPL-files into the Windows PATH. ( control panel, system, advanced, environtment variables, path…)

  2. In the IDE, it should then work if you load the packages individually “in order.” In order means that LIB has to be before IDE, and CORE needs to be before any particular bridge such as bde or dbisam.

Specifically: see if you can get CORE LIB to install. Then CORE IDE. Then exit Delphi and re-open, see if those stick. They probably will. Then add the DBISAM core then ide, and see if those stick. I highly recommend the extra Exit-Delphi-and-reopen steps because the IDE will save some knowledge to the registry when it exits, and that avoids losing your settings in case anything else crashes down the track.

Hopefully that is enough, and please let me know what happens.

I am extremely envious of your location in Turkey. I watch a lot of Turkish series ( thanks to netflix ) and hope to get there some day. I am currently in New Hampshire USA, fwiw.

Thank you for using our forum. It is running quietly 24x7 for exactly these situations. Some future user will be thanking you for writing all your details.



I think we’ve made it. The lib and ide files install for all packages except for one. The BDE. When I try to add the lib package for it (because its not showing in the package list), it gives me this message. 'Cannot load package…rbc40_b_pas_lib_d12… It contains unit ‘DBTables’ which is also contained in package ‘bdertl120’. My application compiles fine and I see the components for the other three package in the IDE. Is this error message something I can ignore and solve by simply removing that BDE package from the package list? If so, mission accomplished.

And regarding Turkey, we are on the western coast overlooking the Aegean. It is beautiful here, the Turkish soaps don’t lie. :slight_smile:

You can ignore the error about any IDE package as long as you don’t need its features while you are in the IDE. Otherwise, we’d have to patch the DPK to tell it to depend on bdertl120 and recompile everything.

This does lead to one of my favorite bits of advice : instantiate components at runtime instead of design time. Basically this means making PAS do what the DFM does behind the scenes.


ATable :+ TTable.Create( Self );
ATable.Name := 'somethingUniqueAtRuntime';  // the DFM does the Name automatically so you always add this 
ATable.Tablename := 'customer';  // etc. to set the properties

If you do it that way, you don’t actually have to get the components to install to the palette at all. It’s not RAD but for something like Rubicon which has a 2 tiers of dependencies (Delphi ← DBISAM ← Rubicon ) it can be much simpler, especially when compiling with 2 different versions of Delphi.

For my own projects, I use the Delphi components from the palette but instantiate the rest at runtime. And I also write FreeAndNil( ATable ); syntax into the OnDestroy of the datamodule.

It’s one of those habits which is easy for people who type fast (me) and necessary for people who work with a lot of beta software (me) and are often trying to make sure code doesn’t break in earlier Delphi versions (me).

I’m actually surprised you want/need the Rubicon BDE bridge installed. I would have expected DBISAM to be replacing BDE for you.

Smiles to the Aegean waters from the Atlantic waters ! It is cold but beautiful here today. The surfers were out to catch high tide with the relatively full moon.


Delphi and Rubicon seem to be all settled in and working well. I don’t use the BDE, it was something I apparently had to install (the checkmark was on, but checkbox grayed out so it couldn’t be removed when installing Rubicon) Thank you for all your help and patience.