(Original question: I added a VERSIONINFO resource to the project, but it is missing from the compiled executable. I did a text search both in ANSI and Unicode, but the pattern is not found. Of course, the "Include version information in project" checkbox is ticked. Is it a bug or something I missed?)
Edited:
I try to reproduce the problem step by step with an empty project, but I can't, because the compiled program will contain the required version info. The steps are:
– I created an empty VCL forms application project
I repeated 2 steps below for all combinations of platforms and configurations:
-- in Project options/Version info I added a key "foobar" with value "barfoo"
-- I set Locale ID to $040$
saved and compiled the project
checked with Resource Hacker, the version info contains VALUE "FooBar", "BarFoo"
But then in the original problematic project, I see very similar version info settings: all platform/target combinations contain the specific key/value pair, locale ID's are set to $040$. So there are some magically wrong settings, perhaps in the .DPROJ file, that cause that the compiled exe won't contain the added key/value pair in the version info.
Edit2:
Sorry, the correct Locale ID is $040E (Hungarian). Both projects use the same toolchain. GExperts and a hacked version of DDevExtensions is installed. I tried to use ProjectMagician but later uninstalled. But those do not affect the problem. I use UPX, but the examined exe is unpacked. Later I re-imported the problematic project into XE11 as if it was a D7 project: I deleted all the project files except the .DPR, reopened the project and added target platform Win64, version info values and all other project settings manually. After a succesful compile, the problem still persists. I think, the project has a hidden or erroneus reference to an invalid resource file. But I still can't find it.
Related
I encountered the following puzzling situation while installing a third-party library, in this case Virtual Treeview, which I will use as an example herein.
After following the installation procedure from INSTALL.txt, the new components appeared in Delphi's component palette, and can be added to a form.
However, building one of the supplied example projects, in this case "Minimal" fails, saying:
'Cannot resolve unit name "VirtualTrees" at line xxx', which is the uses statement in which VirtualTrees is listed.
Congruent with that symptom, in the source code editor, (uses) VirtualTrees, and subsidiary component declarations, were marked with red squiggles, indicating identifier undeclared or not resolved.
The supplied demo project was set to target Windows 32. But puzzlingly, if I switch the target to Windows 64, it will compile.
Installation consisted of:
Unzip the supplied zip file to wherever you locate source packages.
In Delphi, open the project group: File > Open .... VirtualTreeView.groupproj
Once loaded, in the project tree, right click on VirtualTreesD26.bpl > Install.
Add VirtualTreeView's "Source" folder to the Library Path, using
"Tools > Options > Language > Delphi Options > Library > Library Path > [...]"
What's allowing the IDE to know about the component, but then failure to compile for Windows 32, yet success for Windows 64?
Each target has its own library path. You have added the VT paths to the Win64 target, but need to do the same for the Win32 target.
Alternatively, remove the VT paths from the Win64 target search path, and add them instead to the target that applies to all projects, and then they will be inherited by the other projects.
In the options dialog there is a drop down control that allows you to specify the target to which your settings are to be applied.
The short answer is that the Library Path was not set correctly. And credit to David Heffernan for pointing that out.
But how and why?
The key piece that I missed was that the Library Settings dialog captures different sets of paths applicable to each of the different platform targets. So at the top of the Library Settings dialog there's a "Selected Platform" dropdown that governs which platform the settings beneath will be applied to.
To be able to build a Win 32 VCL application, the Library Path needs to be set specifically for Windows 32, which means setting the Selected Platform dropdown to Windows 32 before performing the step of adding the path to Virtual TreeView's Source directory.
Obvious in retrospect, and perhaps this SO post will help connect "Cannot resolve unit name" to this potential cause.
There are a couple of gotchas to add regarding why this happens.
a) Users coming from older versions of Delphi may be familiar with this Library Settings dialog before it handled multiple platforms, thus not realize that it now has a "Selected Platform" feature.
b) On my installation of Delphi 10.3, which is a fresh one, that "Selected Platform" dropdown reverts to Windows 64 every time you open the Library Settings dialog. It neither coordinates with the platform of the currently open project, nor does it remember what you last set it to, it seems. So it's easy to miss that it's not set to the platform you assumed, unless you know to look explicitly.
It may also be useful to know that while this functionality sets the library path for the entire Delphi installation ("globally"), there are overlapping settings at the project level, accessed as follows (for the example "Minimal" project):
Project tree, ProjectGroup1 > Minimal.exe > Build Configurations > Right-click > (Project options dialog) Building > Delphi Compiler > Target (All configurations, or particular target) > "Search path" slot.
Delphi apparently merges "Search path" with Tools > ... > Library settings > Library path.
Finally, for Virtual Treeview, its maintainer Joachim Marder has added a note to the installation instuctions to avoid the pitfall described here.
I have set the file version in Project->Options->Version Info (yes the "Include version information" is ticked).
I have for example FileVersion: 0.95.1.73 set in all release configurations.
But when I rebuild, the File version is always set to 0.7.8.28
It doesn't matter what I set the FileVersion to, I always get 0.7.8.28.
The Copyright text is also from a very old version.
I tried to clean delete all files obj, res, tds etc in the Win32/Release folder of the project. But same result every time.
The project file (XML) do have the new FileVersion of 0.95.1.73.
This problem only happen on Release config, Debug config is working fine.
Any clue of where to look? Any compiler/preprocessor directives that can override this?
No, there is no compiler/precompiler directive to override this. You have a conflicting version resource defined somewhere. If it is not in the .cproj file (which can have multiple build configurations defined, each with their own version info), then there has to be an offending .rc/.res file somewhere on your project's search path that is being linked into the final executable. Version info does not come from anywhere else, it is either defined in the project itself, or it is linked from a resource script/file.
Got this error whenever I try to compile something: "F1027 Unit not found: 'System.pas' or binary equivalents (.dcu)".
Got it after installing a component, removed it, reinstalled RAD studio, but still same.
In order to get it fixed, I need the Library path and browsing path. Please anybody post yours so I get it working.
A workaround I found is including the path "$(BDS)\lib\win32\debug" to Library path, but this is not the correct way. So I need your paths. Thanks!
This is from the HKLM\Software\Embarcadero\BDS\8.0\Library key in the registry - you can save it to a .reg file and then import it (making any necessary fixes to the paths first, of course):
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Embarcadero\BDS\8.0\Library]
"Browsing Path"="$(BDS)\\SOURCE\\VCL;$(BDS)\\source\\rtl\\common;$(BDS)\\SOURCE\\RTL\\SYS;$(BDS)\\source\\rtl\\win;$(BDS)\\source\\ToolsAPI;$(BDS)\\SOURCE\\IBX;$(BDS)\\source\\Internet;$(BDS)\\SOURCE\\PROPERTY EDITORS;$(BDS)\\source\\soap;$(BDS)\\SOURCE\\XML;$(BDS)\\source\\db;$(BDS)\\source\\Indy10\\Core;$(BDS)\\source\\Indy10\\System;$(BDS)\\source\\Indy10\\Protocols;$(BDS)\\source\\database;"
"Debug DCU Path"="$(BDSLIB)\\$(Platform)\\debug;$(BDS)\\RaveReports\\Lib"
"HPP Output Directory"="$(BDSCOMMONDIR)\\hpp"
"Language Library Path"="$(BDSLIB)\\$(Platform)\\release\\$(LANGDIR);$(BDS)\\lib\\$(LANGDIR)"
"Package DCP Output"="$(BDSCOMMONDIR)\\Dcp"
"Package DPL Output"="$(BDSCOMMONDIR)\\Bpl"
"Package Search Path"="$(BDSCOMMONDIR)\\Bpl"
"Translated Debug Library Path"="$(BDSLIB)\\$(Platform)\\debug\\$(LANGDIR)"
"Translated Library Path"="$(BDSLIB)\\$(Platform)\\release\\$(LANGDIR)"
"Translated Resource Path"="$(BDSLIB)\\$(Platform)\\release\\$(LANGDIR)"
"Search Path"="$(BDSLIB)\\$(Platform)\\release;$(BDSUSERDIR)\\Imports;$(BDS)\\Imports;$(BDSCOMMONDIR)\\Dcp;$(BDS)\\include;C:\\Program Files\\Raize\\CS4\\Lib\\RS-XE;;$(BDS)\\RaveReports\\Lib"
For MSBuild to work properly (and for project configurations), you need to make sure the following environmental variable is set properly:
PLATFORM=ANYCPU
Top Line of the library path:
$(BDSLIB)\$(Platform)\release
Some installers mistakenly parse this as two lines and split them out.
Check on your Delphi IDE menu: Tools * Options, to see what is defined.
My default installation has 2 important "Environment Variables",
BDSLIB, defined as "c:\program files\embarcadero\rad studio\8.0\lib"
Platform, defined as "Win32".
On that same form, under Library, is defined
Library path:, the path begins "$(BDSLIB)\$(Platform)\release;...
That should equate to C:\program files\embarcadero\rad studio\8.0\lib\Win32\release", which is where you should find System.dcu. Make sure that file is there. Maybe it was removed or damaged by your component work.
There is also a "Debug" directory under Win32 which should have the dcu with the debug information included. If the release dcu is missing or damaged, you can probably copy the debug version in as a quick test.
It sounds like the compiler couldn't find the dcu then also looked for the source file to recreate it. But it should normally use the dcu.
I believe the source is in PF\Embarcadero\Rad Studio\8.0\source\rtl\sys as system.pas.
All of the above is the default Delphi Options. The options can also be changed for a project, which could interfere with the above. Try the above first. Then create a new project and see if it will complile, as that will use the defaults only.
Patrick
New York
Take a look at the -cleanregistryide option on this page:
http://support.embarcadero.com/es/article/42597
It will allow you to restore the IDE's default installation paths. If you use this option, third-party add-in's would need to be reinstalled. I have experienced this problem after upgrade installations when there were installed 3rd party IDE tools.
HTH
Navid
For XE4 use this restore.reg
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Embarcadero\BDS\11.0\Library\Win32]
"Search Path"="$(BDS)\Imports;$(BDSCOMMONDIR)\Dcp;$(BDS)\include;C:\Program Files (x86)\Embarcadero\RAD Studio\11.0\lib;C:\Program Files (x86)\Embarcadero\RAD Studio\11.0\include;C:\Program Files (x86)\Embarcadero\RAD Studio\11.0\Imports;$(BDSLIB)\$(Platform)\release;$(BDSUSERDIR)\Imports;$(BDS)\Imports;$(BDSCOMMONDIR)\Dcp\$(Platform);$(BDS)\include"
You can change 11.0 to your version of Delphi
There are bunch of helper filess in 'iPublicUtility' folder of several audio related Apple sample codes, such as aurioTouch:
http://developer.apple.com/library/ios/#samplecode/aurioTouch/Introduction/Intro.html
I can build these samples fine. But whenever I create a new project for testing and include the files from 'iPublicUtility' folder, I get:
'CADebugPrintf.h: no such file or directory ... ' error in 'CADebugMacros.h' file.
I made the settings of my test project to coincide with Apple samples, but this error is
not going away. Any suggestion?
SDK: iOS 4.2,
iMac OSX 10.6.6
Thanks all.
sy
select the Target, open the Build Settings pane, search for "Preprocessor Macros". Leave the fields blank (I've got rid of a DEBUG entry)
I used the answer provided by Justin and it worked fine, until I installed Xcode 4.3.1 and the problem came back.
Currently I solved this by downloading CADebugPrintf.h and .cpp.
I found the 2 files at this link:
http://svn.perian.org/trunk/CoreAudio/PublicUtility/
Cheers.
i have three distributions of Xcode installed.
the file exists in all three.
1) verify that the file exists on your system.
2a) add a search path to your project for the PublicUtility directory
or
2b) add the header to the target's "copy headers" build phase
depending on how many depends you have for these files, you may want a more reliable approach (which exists). one (fairly) safe/easy way to do this if you use a lot of the audio technologies and sources is to add its parent dir's parent dir to your search paths or source trees (recursively).
another way is to add it to a shared build settings file.
you could also copy a specific release someplace, then add that to your search paths. just be aware that the sources get updated somewhat regularly, so you'll have to update it when it's a good time for you. in this case, you'll should change your project references as well.
Edit: Adding the search path (2a)
One way to add a search path (assuming Xcode tools are installed at : /Developer/):
1) In Xcode (3), select the target.
2) cmd+i (get info)
3) select the "Build" tab of the info window
4) enter HEADER_SEARCH_PATHS into the search field
5) if the value is not defined at this level (e.g., it is not bold), then set the value to /Developer/Extras/CoreAudio/PublicUtility/ $(inherited)
if it is already defined at that level, then add /Developer/Extras/CoreAudio/PublicUtility/ to the list of directories to search (the value).
if you want to search the library recursively, use /Developer/Extras/CoreAudio/**. this may be useful when building AUs, or other projects which require the AU includes and PublicUtility includes.
Same problem, but seemed to have fixed it by downloading from the link below and adding in the missing CADebugPrintf.h and CADebugPrintf.cpp files.
https://developer.apple.com/library/ios/samplecode/CoreAudioUtilityClasses/Listings/CoreAudio_PublicUtility_CADebugPrintf_h.html
I was having the same problem and downloading the files into the iPublicUtility folder did not solve it. I found the answer by accident while learning about .mm extension files on this page:
Objective C Project using C++ POSIX Classes
I renamed my implementation file with a .mm and the compiler errors disappeared. Hope this may help someone down the line!
I'm trying to build 3 packages, A, B and C. A defines some base classes that are used in B and C. I've got all 3 of them in the same project group, all set up to output to the same custom BPL output folder. This folder is in the search path for B and C. But when I go to build B and C, the compiler chokes on the Requires list. "Required package 'A' not found."
How do I tell B and C where to find A so they'll build correctly?
Either the package can't be found, or the compiler is confused. In the later case, a restart sometimes helps. Then a manual build from all packages in order.
If it really can't be found, check if all package (bpl and dcp) and dcu files are available. You need both.
If this happens when the IDE is trying to load a package: your package output directory (where the *.bpl files go) has to be on your system's PATH environment variable. Packages are statically linked DLLs, Windows has to be able to find them to load them.
If this happens when building the packages: any/all of your DCP output directories (where the *.dcp files go) have to be in the dependent projects' search path so that the compiler can find the compiled packages.
You can also leave the DCP output directory of the package project empty - in which case the global DCP output directory set in Tools\Options\Library is used; the dependent projects then don't need to include it in their search path.
It is possible that the name of the required package is incorrectly specified in the 'requires' clause of the package you are trying to compile. Let's take an example:
We have two packages - VirtualTreesR.dpk and VirtualTreesD.dpk. VirtualTreesD requires VirtualTreesR. They both have the '16' suffix, so they both are displayed in the Delphi project manager window as VirtualTreesR16.bpl and VirtualTreesD16.bpl. You may think that these are the names of the packages, but you are wrong. The names of the packages are still VirtualTreesR and VirtualTreesD, not VirtualTreesR16 and VirtualTreesD16.
When VirtualTreesR.dpk is compiled Delphi produces two files (I don't talk about DCUs here) VirtualTreesR*16*.bpl and VirtualTreesR.dcp. See the difference?
Then we attempt to compile VirtualTreesD.dpk and get the error: "[DCC Fatal Error] VirtualTreesD.dpk(35): E2202 Required package 'VirtualTreesR16' not found".
The error happens because the 'requires' clause of the VirtualTreesD.dpk package contains the following lines:
requires
designide,
VirtualTreesR16;
Delphi tries to find VirtualTreesR16.dcp and fails even if the Delphi search path and the PATH environment variable are set correctly because there is no VirtualTreesR16.dcp. Only VirtualTreesR.dcp.
The solution is to fix the 'requires' clause so it will look like the one below:
requires
designide,
VirtualTreesR;
Hope it helps.
P.S. This a quite frustrating issue because this name mismatch is not obvious and its fragments are scattered across different settings. Delphi could be more specific if it specified what file exactly it tried to find (e.g. 'VirtualTreesR.dcp' instead of 'VirtualTreesR').
I would check to make sure where you are writing the .dcp files for the packages. once you have this, check that the search path of each package has an entry for the .dcp output folder.
I sometimes receive the "package not found" error when adding required packages via the Delphi Project Manager context menu. (Open a package, right click "Requires", choose "Add Reference..." command)
Instead it's easier to add the required package by editing the package project file manually:
Select the package in the Project Manager. MyPackage.bpl for example.
Ctrl+V to open the project file.
Add the required package to the requires clause.
Ensure the required package *.DCP file is in the package search path.