Version 9.3 unable to link on C++Builder 10.1


I just downloaded and installed the 9.3 version. Everything went ok with the installation, the components got installed without problems, and I was able to compile my projects, but when trying to link any module that links to the BPLs of RemObjects (BPIs, actually) then I got an error like this:

ilink32 Error: Error detected (LIB266)

Version 9.2 works fine (except for the other problem I just reported: Is there a way to split the _Intf file in multiple ones?). I tried rebuilding manually the RemObjects libraries but the results were the same.

This is a Win32/VCL project. My C++Builder is 10.1, patched up to the latest available update.

can you share your RODL, pls?
you can send it directly to support@

It is not needed to produce this error: I managed to reproduce it just adding the Core and Indy packages (BPIs) to the Requires section on a package that does not include any of RemObjects code.

This is an application that is divided in several packages, all of them using runtime packages and dynamic RTL.

I will try to get you a test case, but I had to rollback to 9.2 as I just didn’t find any way to workaround that linker error. But hopefully it is easy for you to reproduce it anyhow.

try to apply solution from :

Hello Evgeny,

I did found that post while trying to solve this, but no matter how many times I cleaned up the “usual binaries” (I assume it’s talking about the compiled binaries created from the project) I never could bypass this error.

I would have to try again making sure that the RemObjects packages are built with the same settings than my project, but this has never caused any issues with RO or any other library before. Most of the libraries I use are without debug information and my apps are, at least in this stage, with debug info.

I assume you can compile and link without problems from a C++Builder app with 9.3?

Simple DA Server was built w/o any problems:

Hello Evgeny,

I’m just returning from a trip and haven’t had the time to recheck this issues. As soon as possible I will try again and let you know.


Hello Evgeny,

I just tried today with the 9.4 March 2018 release and I am getting the same error, LIB266, when trying to link a project that links with the RemObjects packages. I never updated to 9.3 because of this, and it looks like 9.4 has the same issue.

I don’t remember if I tried rebuilding the RO packages by hand, but I will try.

I did not know if the test project you created had the options to use Dynamic RTL and Use Packages set to true (that’s how I have my projects).

I’ve done more tests, rebuilding the RO packages, and so on, and no luck.

I created a simple test project that only includes a ROBinMessage and ROSuperTCPChannel components on an empty form and:

  1. If I set the Use Runtime Packages to true (the default, and how I need to work as some other libraries don’t work otherwise) then I get the LIB266 error. You can’t disable “Use Runtime Packages” for projects that are Packages, to begin with, which is the case of my real world app.
  2. Disabling the Use runtime Packages apparently works.

I don’t know what could be causing this error. As I said, I have already rebuilt the RO packages with some different settings (specially the one to disable the debug information) but it makes no difference.

I am using RAD Studio 10.1 Berlin, Update 2.

I’ve uploaded the test project. As it is here it should produce the linker error:
test-ro9.4.7z (54.7 KB)

Just FYI: I tried this on Tokio 10.2.3 (the trial version) and it produces exactly the same error.

I can reproduce LIB266 error in your project.
One problem - this error (LIB266) is mentioned only in one place and no additional information about this error isn’t found by google.
I’ll try to create packages and project with the same compiling options…

Hello Evgeny,

Yes, I did not find any other reference (except for this thread) in google about this.

I created a report for Embarcadero already, as I do think this is a bug in the linker:

Meanwhile, maybe you have more direct contact with them so they can point in the direction of a workaround? I am guessing that they can check the linker’s code and see where the error is being produced, having that should make easier to find a workaround.

There must be something changed between the package projects in 9.2 and 9.3/9.4 that is triggering this, but I haven’t found it. One thing I do find strange (but I dont’ remember if it’s the same in the 9.2 packages): the 9.4 are configured (at least when opening the project group in the IDE) as “designtime only”. I already tried changing them to runtime only and runtime & designtime and it made no difference, but I don’t know if this is intentional or not, or if when you compile the packages in the installer you use some other settings. This were the Tokio packages, I haven’t checked the Berlin ones.

I already tried disabling debug info in both as per the only other post related to this error (in the test app and the RO packages) and tweaking different options in both sides but no luck. Hopefully you will find something.


Ha, you’re funny :wink:

in all seriousness, though, Embarcadero do not talk to us or give us support, they don’t like us supporting their customers with our products because they’d rather have everyone shell out $$$ for Enterprise instead :(. You might have more luck contacting their support directly, ideally keeping the request abstract and unspecific to RO/DA being involved.

Oh… that’s true. I forgot you were basically direct competitors in several areas with them.

I would love to produce a more abstract non-RO related test case for them, although my personal experience is that it doesn’t really matter, and much less for a case like this where I appear to be the only soul having this issue, ever.

I guess I am out of luck :frowning:

Hopefully you can get some kind of workaround, knowing better the needed project options and the changes between 9.2 and newer versions. I did a quick diff between the two but couldn’t really see between the real changes and the ones the IDE make to the project files.

Is it possible to rebuild the projects as you do with the installer (meaning: without having to open the IDE and so on?) The projects as they are right now, for instance, don’t include the Delphi option to generate the C++ files, although it is being set when compiling from the installer. I don’t know if there are some other things being changed that are not reflected on the projects per se.

I’ll let Eugene provide the details on the where and how, but yeah, the same build script we use during install you could also (tweak as needed and) use directly form the command line.

answered via PM

Replied there, thanks!

I’m sorry to reopen this, but I want to leave a note for posterity… or mostly for myself, as today I was installing the latest ( version and found this again. As the reported bug hasn’t be solved by Embarcadero and there is no news since 2018, I guess the only thing left to do is to workaround this ourselves. Using the ilink32.exe from Rio in Berlin still produces the error, so as of now, this hasn’t been fixed.

The problem is related to using MetaClass with generics, which some of the units of RO use.

The solution is to compile RO without generics: In, near the end, disable the {$DEFINE ROUseGenerics}, the one that it’s commeted as // optionally.


you are right, here is 2 workarounds:

  • update as
  {.$DEFINE ROUseGenerics} //<--- updated
  • update uROUrlSchemes.pas as
{$UNDEF ROUseGenerics} //<-----added