RAD Studio 10.4.2 C++Builder running on Windows 10 Pro 64-bit PC. Target VCL Win64 (ie Clang64 compiler).
I have a large C++ project that is under development using VCL Clang64. I am compiling using static linking of all RTL libraries and all installed component packages.
It was compiling and running OK before. I've added some new stuff, and now it compiles and links without reporting any errors, but when I run it I get an error box and the application doesn't run (doesn't even start up). The error box says.
Error reading OKBitBtn.Kind: Resource BBOK not found
I have used Notepad++ "find in files" to search all directories for a file containing BBOK, but it says "none found".
If I compile with the "Use runtime packages" project option enabled, I get an AV when I try to run the EXE file.
If I compile and link using Clang32 (target = Win32) with static linking, it runs ok - no sign of any errors (but I need a 64-bit application to interface to my PostgreSQL database using FireDAC, so this experiment won't talk to the database, as expected).
I am at a loss as to what can cause this error, and what debugging steps I should take to track it down and solve it.
(thanks to Remy for making edit improvements to my mquestion)
Thanks to help from David Millington and Miguel Moreno (provided by skype conversation I now have the solution:
I have some of my own VCL components that are written in C++ (and work with the classic compiler). I had these de-selected in the "installed packages" list - but they were still listed (with empty check boxes). I know that RAD studio 10.4.2 (and earlier) does not work well with VCL components written in C++ and compiled with clang32 or clang64 compilers.
If I "remove" these components from the list then the problem is solved. At this point I have no idea why this happens.
This is a bit of a pain as it means swapping from projects that use the components with classic compiler (many) to the big project I am spending a lot of time on is not convenient. However it is an acceptable workaround. I am hoping that this issue will be fixed in the coming RAD Studio 11 version.
Related
A few weeks ago, our company migrated from Delphi 5 to Delphi 10.3 Rio. After some problems, we've reached our goal to compile our solutions (many EXEs) with the new IDE. We're using DCC32 to compile our projects every day.
Unfortunately, some of them have encountered a visual issue. They are using the old VCL visual style from Delphi 5, whereas others use the newer style.
After much research, we've noticed that every executable that works has a manifest (thanks to ResourceEditor.exe), but the others which don't work don't have any manifest.
Projects seem very similar, no forced manifests files, same compiling way, same resources generator.
It seems that the default manifest (default_app.manifest) located in the Embarcadero directory is used during the generation.
Does anybody know why some EXEs contain this default manifest and others don't have it?
EDIT:
Thank you everyone for all your replies, i'm a bit late but i have managed to solve my problem.
Unfortunately one of our libraries owns a manifest on one of his res file. But some of our applications don't use this library and have this issue.
For those who point the IDE solution, we use dcc32 compilations which, tell me if i'm wrong, don't use the dproj file where the runtime theme is specified. The IDE solution works well but since we use dcc32 compilations, we can't use it.
This is probably an issue with option "Enable Runtime Themes" not being selected (Project / Options / Application / Manifest).
With XE8 update 1, Win 7 64 bit and a single component added to an otherwise empty folder I get:
error: [dcc32 Fatal Error] F2039 could not create output file .\Win32\Debug\MountTest.
The test will compile and run fine the first time but XE8 has to be shut down and restarted to compile again. The component is a gauge from Mitov Software.
The component vendor say's that this is a known bug with no fix. If so its a showstopper and project end'r for me. Is it really the end of the line for Delphi?
I hope some one can pull this rabbit out of a hat somehow.
This is what I have done to isolate the problem.
Started with a failing application (will not compile a 2ed time)
Remove all external units used
Remove al references to those units
Remove all references in the 'Uses' clause
Comment code until it compiles
It should compile every time you hit run (no problem).Now add a blank form to the project. Don't do anything to the form just add it. Add it to your uses clause.
Its should compile every time you hit Run.
Now open the blank form and simply touch it so that it needs to be recompiled.
When you run the application its back to failing when you run it a second time.
Notice that happens when you simply add a form and 'touch' it. No code needed.
This problem is not something wrong with my code - it can't be. Its a bug in the UI - must be.
Coincidentally, I just fought with this issue yesterday testing some components I ported to XE8. The output file in my case is the project executable.
After spending several hours trying to figure out what was going on (including efforts to reconfigure my AV software, disabling it entirely, moving the project to a different location, etc.), I was able to solve the problem by disabling Castalia. If I run the IDE without Castalia, the problem does not occur. If I enable Castalia again, it starts happening again.
You can find instructions for disabling/enabling Castalia in How can I disable Castalia in XE8?
I'm removing the above content because the issue has reappeared (with Castalia disabled). Further investigation shows a couple of things:
The problem seems to be related to any sort of exception being raised in the debugger (even those that are handled in the code). Clicking either Break or Continue in the debugger exception dialog works as always. However, the next attempt to compile or build the application fails with the F2039 error. Deleting the executable in Windows Explorer allows compilation and running once, and then the error recurs.
Restarting the IDE fixes the issue, until the next debugger exception occurs.
Neither taskkill or a batch file with del worked in either a pre- or post-build event.
There is an open QC entry for it at Embarcadero which indicates that it was reported in XE7, XE7.1, and XE8, and is currently an open internal ticket. I can't find a way to add the information in the two points above to that open ticket in the new JIRA-based Quality Portal. Perhaps someone who has access and can do so will on my behalf (or at least add a link to this post).
It's not linked to a specific project. The original answer (as mentioned above) was related to a test app while porting some components to XE8 from an earlier version. When the problem reappeared for me, it was in a brand new project, totally unrelated, that does not use any non-standard components.
(I previously had access to EMBT QC, and had a few open tickets. The accounts appear to have not migrated to the new QP, and I can't locate any tickets there under my account.)
Found It.
I decided to start from scratch on my development system and uncovered the problem.
I installed Windows 10 on a virgin disk
Installed XE8 update 1
Installed MITIOV Instruments for XE 8 and tested them. All working find
Installed AsyncPro - Still working
Installed the JEDI Jcl - Fails
Remove JEDI Jcl - now works
Trash JEDI completly - Everything works fine
Something in the JEDI Jcl version 3.48 is causing the problem. I can code around the JEDI components I was using without to much trouble but its a shame.
How about automatically kill your "hang-up" application before build?
I also had this problem on Win 7 Pro 64 bit with XE8.
Removing JCL fixed the problem. If I was a betting man, I would look closer at the JCL Debug IDE extension.
Guy's..
There is no reason to upgrade to Delphi 10.1, because all previous versions are equipped with an older version of the Android SDK.
Now, how to solve this annoying issue:
Just find the map where the Android SDK is located.
See: Tools/Options/Delphi Options/SDK Manager/Android Location
Now run the ..\sdk\tools\android.bat as Admin
This will show the Andoid SDK Manager.
Next is to update to the newest Android SDK and SDK Tools.
If all completed, you don't have to upgrade to Delphi 10.1 or whatever "advised".
Restart Delphi and problem:= solved!
btw:
It took some effort to find out what's happening here, because the Eclipse compiler suffered the same issue as Delphi. Finally all was related to bugs in earlier versions of the Android SDK causing adb.exe to keep a filehandle held hostage.
I have developed a Delphi application (XE4) on a Windows XP machine.
When I copy all the project files to a Win 7 machine (also Delphi XE4) it will not compile.
The source has uses Vcl.Grids and the compiler complains it can't find vcl.grids.dcu.
Changing to uses grids works but I don't want to edit all the source.
I've checked the Embarcadero website for information on Namespaces but couldn't find anything useful.
I know it's possible to say uses vcl.grids under Win 7 so there must be some setting somewhere in the project that is preventing the resolution.
I've tried deleting the dproj files but that had no effect.
How do I get the source to compile with minimal changes?
The error has nothing to do with OS. It means your IDE/Projects's search paths are not configured correctly, or your project is missing references to the relevant packages, so double check that.
Also, you can use uses Grids in the code, and then make sure Vcl is listed in the Unit scope names field in the Project Options.
The information that you describe seems to be erroneous. The compiler is not affected by the operating system on which it runs. Running the same compiler on the same source code on a different operating system does not result in compiler errors.
Here are the reasonable explanations for your problem:
You are compiling the code on different versions of the compiler. Your error message matches what happens when you compile modern namespace aware code on XE or earlier.
Your are not compiling the same source code on both machines.
It is extremely hard to see beyond these two explanations.
Ok, red face time. Turns out I was running an earlier version of Delphi on the Win 7 machine. Delphi XE4 was installed along with an earlier version and I was invoking the earlier version.
Once I actually brought up XE4 on the Win 7 machine the issue vanished.
So I will don a hair shirt and crawl under my rock.
Thanks everyone who contributed.
I have upgraded a project from RAD Studio 2010 to RAD Studio XE4. The project is mostly C++ using the C++ Builder half of RAD Studio, with smatterings of Delphi.
Under 2010, the Release build was 22MB. Under XE4, the same Release build is 55MB.
This is a problem because:
55MB is remarkably large for an EXE
It takes noticeably longer to start the program (not much, but some.)
Many of our customers download new versions from remote areas or on board ship while at sea. Size matters.
What could cause this, and how do I fix it?
Notes
Oddly enough, the debug build is still only 23MB. Project settings seem very similar. I diffed an export of the option sets and saw only <UsePackages>True</UsePackages> as something present in Release not Debug; removing it made no difference. Beyond that there's code optimisation turned on and lack of a _DEBUG define.
Debug info is generated for the Release build, but goes into an external .tds file. (This will be used for EurekaLog in future, and currently allows us to debug release builds of the program.) I wondered if the linker was linking in debug info, but as far as I know the C++ linker always places the debug info in an external file, which exists, plus EurekaLog is not yet enabled in the build.
The project files (.cbproj) were created in XE4, not upgraded from old 2010 ones. I made new projects and added the old .cpp and .pas files. This was to avoid issues caused by upgrading - on the Embarcadero forums it's often recommended to create projects anew when upgrading IDE versions. Until this occurred, I had indeed encountered fewer issues than in 2010.
There are many mentions of Delphi XE2+ EXEs being noticeably larger than those produced by old versions of Delphi. (1, 2, 3, 4, 5, 6.) While the C++ linker is different to that used by Delphi, it is possible the causes are similar.
The cause there appears to mostly be RTTI used by the Delphi RTL code, which in a Delphi project can be removed by specifying {$WEAKLINKRTTI ON}. The XE4 documentation does not mention an equivalent C++ linker pragma. There is #pragma explicit_rtti (the C++ analog of {$RTTI}) and __declspec(delphirtti) (the C++ analog of {$M}/{$TYPEINFO}).
The project is linked using runtime packages and the dynamic RTL. It is a 32-bit VCL forms application. I have XE4 Update 1 installed on Windows 7.
Edit: David Heffernan asks in a comment below about the .map file sizes of each project.
The release .map size is 17MB, and .tds size is 80MB.
Debug has now stopped linking, with the linker reporting it is out of memory (an old, old bug that should have been fixed years ago.) There are no .map or .tds files generated and so I can't give a comparison size accurately. From memory the .tds was about 100MB, and unfortunately I don't recall the .map size. If I get the project linking I will update the question.
Edit again: I found the answer (sortof) - turning 'Expand inline functions' OFF reduces the EXE size to the expected value. This is puzzling itself though - see my answer below. Note that the debug build already had this turned off and still won't link, giving an out of memory error.
I haven't marked my answer as correct yet, in case someone can provide some insight into exactly what is going on, which would be a much better answer than just 'turn this option off'.
Solved (sortof.)
The Release build had "Expand inline functions" turned on. Turning this off reduced the EXE size from 55MB to 17MB.
This is an astounding difference and I don't know why the difference is so big. I find it unlikely we have 38MB worth of inlined functions, even counting templates and headers, let alone ones using the inline keyword. If there is a way to examine the linker steps, output, or obj files to see what is being expanded, please comment - I'd find this really valuable.
After many years of trouble-free use, Delphi 7 is now throwing an Access violation at address
40233A3E in module 'vclx70.bpl'. Read of address 0000021C.
When starting the IDE, the default empty project and unit/form appear and compile and run fine.
I'm developing Windows apps, running on Windows 7 (x64).
I haven't installed any new packages or tools in many, many months.
I stopped, dead in the water, unable to work.
Any suggestions other than a complete rip and re-install (which takes many hours...)
EDIT: I un-installed and re-installed Delphi 7. Now I'm getting Access violation in vcl70.bpl. I would have thought that uninstalling D7 would completely remove all of its libraries, etc... Are there folders that I should manually delete after uninstalling D7?
Problem fixed (and major machine rebuild averted)!
Gerrit Beuze of ModelMaker Tools suggested elsewhere:
Remove all .dsk (project desktop) files for the project you try to load, Temp remove all *.dst (desktop files) from C:\Program Files\Borland\Delphi7\Bin
After performing these steps, the problem appears to have been fixed.
A read at that low a memory address is typically a problem in a third-party component. However, you say you haven't installed anything new in months.
The other thing that's strange is that you're getting the error in vclx70, which is one of the CLX libraries. Are you doing anything using the CLX (leftover cross platform - Kylix) forms or dialogs?
If not, you might do a search in your source for QDialogs, QForms, or any of the other units in %PROGRAMFILES%\Borland\Delphi7\Source\Clx, and see if something mistakenly was added that you didn't intend that's pulling CLX into your project. If so, change it to the VCL version instead (by just removing the 'Q' from the front of the unit name in your source).
EDIT: You might try going into the registry (D7 would be HKCU\Software\Borland\Delphi\7.0) and temporarily changing the name of the delphiCLXide entry in Known IDE Packages to something else (put an underscore in front of the name or something). Then start the IDE. You should get an error message about Delphi being unable to load the package, and asking if you want to try and load it again in the future. Answer 'Yes', and let the IDE continue to load. Then try again with your project and see what happens.
The step above removes CLX temporarily from loading in the IDE designer. (Don't worry, you can just rename the key again to put it back if it's not the problem. If it doesn't come back, make sure the IDE didn't add an entry in the Disabled Packages entry; if it did, just remove it.)
If this works, you can open the project options (.DOF) file for your project, and remove the CLX libraries from the Packages list. This prevents it from being included when your project is loaded.
Once you've established whether the problem actually
My first suggestion would be to use XP Mode or another VM infrastructure to run such an old Delphi version on Windows 7 (I do it that way).
Another potential method is to use the compatibility settings in Windows 7 to set it to XP and to exempt the Delphi 7 process from DEP (data execution prevention) policies the system may otherwise impose. I've had some trouble with enabled DEP with older Borland IDEs and also VS 2003.