RAD Studio 10.2 Tokyo will be out very soon, and I'd like to let you know some of what you can expect to see new on the C++Builder side.  While the majority of work is for Linux, which will be available for C++ in 10.2.1, we've worked on three key areas:

  1. Improved linking
  2. Improved code generation
  3. Improved debugging

Today I want to discuss what's new in the linker.

The Win32 and Win64 linker

The Win32 linker, which we also use for Win64, is one of the oldest technologies we still use, and until today in recent years it hasn't had much work done on it.  As time has passed the applications people are writing, and so the data that needs to be linked, has changed significantly.  Today's apps are larger, with more debug info and importantly larger quantities of certain types of debug info than they were when the linker was first written. This led to problems allocating space for and handling large linksets. Sometimes, the problem was not the size of a specific type of data, so much as that the size was more than had been predicted in relation to other types when the linker was written.

We have addressed this in 10.2 in two ways:

  • The linker is now large address aware and can address up to 4GB on a 64-bit system, twice the previous amount. (Some customers hacked the linker to be LAE in the past by toggling the bit in the PE header; since the code wasn't written to be LAE-aware this hack prevented incremental linking and sometimes other functionality from functioning correctly.)
  • The linker has been tuned to modern debug usage.  That is, the various pools and heaps it uses have been modified to follow typical behaviour for debug information today.

The second means that many linksets that experienced problems will now link correctly. The first means that linksets that stressed the heap allocations, even when manually tweaked via command-line flags, can now access much more memory and link correctly. We hope to see the vast majority of linker errors solved with these two changes.

The vast majority? What if that's not me?

Glad you asked! In the past, we recommended users use command-line flags to change the allocation size of various pools or heaps.

Those flags are still available, and we have expanded their support. The settings are now available in the IDE's project options (C++ Linker > Linker Heap Settings) with some options for Win32 linking, and more for Win64 linking:

 If you encounter an error, the linker will emit a message stating what failed, and you can look up the appropriate option here to set a specific size. (Note if you're building in the IDE, you may need to set Verbosity to Diagnostic in Tools > Options > Environment Options.) However, the vast majority of users will not need to use these settings - they are there as a backup.

Future plans

We plan to continue working on the linker in future over the next few releases. If you have update subscription, you will get all changes as they are released. However, in 10.2, we've taken a large step in addressing issues customers have experienced. We hope that when you test out your projects with 10.2, you will find significantly improved behaviour.

 

  • 10.3Still [ilink64 Error] Fatal: Access violation.  Link terminated.

  • Since 1999 when Visibroker was a Borland product and was delivered together with C++ Builder 4 we use it in the main system of our company. Unfortunately, Visibroker and C++ Builder divorced when Borland created CodeGear. Since then our system is a child with two houses. To make matters worse Micro Focus (which bought Borland) has officially announced that it will not support C++ Builder with CLANG-based compiler. Our system controls one of the largest railroads in Brazil, it is huge and important but it is like an orphan today. Our managers and developers want to migrate to C++ Builder 10.x, so we have an approved project to upgrade our IDE in the next year, but if we can not upgrade Visibroker, the project will be canceled and a new strategy must be adopted. Visibroker will only maintain MSVC support in Windows so I´m studing a way to use MSVC libraries in C++Builder. We are still talking to Micro Focus but it seems that this market does not interest them anymore. Kind Regards from The Best Brazilian Railway.
  • We don't currently use LLD, but it's something we're investigating. Linking different object file formats together is not trivial, and there's a lot more to it than just different formats. Visual C++ uses a different ABI, different STL, etc, and so the C++ classes and objects are not compatible. Even if we could link COFF, we could not necessarily directly use a MSVC-generated DLL, in the same way MSVC can't use one built by MinGW. However, if you have a flat C API in your DLL, so you don't expose any C++, it's fine. You can build that in MSVC, dynamically link to it, no problems. What is your need for MSVC for one specific DLL? Can C++Builder compile it instead?
  • According to the LLD documentation, it links both COFF and ELF import libraries. Does it mean that C++ Builder will link COFF(MSVC) libraries too? lld.llvm.org/NewLLD.html I need just make a C++ DLL in MSVC and use it in C++ Builder. Is it possible in C++ Builder 10.x? Thank you!
  • Ok, I'll try to do it too. But for now: I installed from the ISO files : delphicbuilder10_2.iso for Tokyo 10.2 and then delphicbuilder10_2_1.iso for Tokyo 10.2.1. The program 'Large Address Aware.exe' (downloaded from www.techpowerup.com/.../large-address-aware.112556), as well as 'CFF Explorer.exe' (www.ntcore.com/exsuite.php) indicate that the bit is not set in the header of ilink.exe (10.2 and 10.2.1).
  • Hi Philippe, Not seeing the bit set is really odd - it's definitely set here on this side! Could you perhaps add a QP report with details about which version you have installed (the build number in Help > About), the installer mechanism you used to install, and attach the ilink executable to it, so we can check what's happening please?
  • No, the ilink32.exe is NOT large address aware. Code may be Ok but the bit is not set in the header, so Windows will not give access to 4MB memory. I changed the bit with CFF Explorer. Unfortunately, this did not help to solve RSP-18765 (which is a bug added by this version 10.2.1). It's probably not a memory shortage problem (the linker does nearly everything and even outputs some .bpl file, but it is not a valid file), it occurs on small projects. Bug disappears when delay-loaded library is no more specified. But it's not a workaround since I need it.
  • We're looking into it. Since it's intermittent, it's difficult to reproduce and we don't see it. If you have any further information, please add it to the Jira.
  • David You were asking for the bug report concerning dupliacte tags being added to project files. Here are some reports about this: RSP-9774 closed as fixed (duplicate) - but I can confirm it is NOT fixed in C++Builder 10.1 Berlin RSP-12577 still open This is an intermitent fault, hence difficult to report. However, it still persists and require hand-editing the cbproj file to remove the duplicate tag. You could easily track the problem down by checking for duplicate tags when the cbproj gets saved. I hope this helps
  • Hi Andrew - yes, looks like the one! If you want to check, verify against the linker command line shown in the Messages docked window, Build tab. The number: it will depend on your project, so "use whatever works for you", which isn't useful advice I know. Turn on diagnostic output in Tools > Options > Environment Options > Verbosity, and watch a failing link. It will write out a table (copy/paste this somewhere with a fixed width font to view as a table) showing the failing heap and the size it needed. Enter in settings larger than the amount it asked for. You might need to repeat this a few times, increasing each time.
  • Sorry, don't have dates to announce yet. But it's coming!
  • What is the duplicate in project file bug - can you point me at a QP please?
  • Have you checked that your environment variable PATH is below 2048 in size?