I am trying to recompile/rebuild an old application program developed on Delphi5. I used the same Delphi5 software on an XP computer.
I did some minor corrections to the codes of a couple of forms and units. When I recompile using the .dpr file it comes with a fatal message: File not found System.pas
I added in .dpr file on the link path to this file BP folder. No success and the same message. Any clue will help.
Probably Library Path is broken after running some buggy component installer. In modern IDE's look for Tools -> Options -> Library -> Library Path from main menu (should be slightly different for Delphi 5).
System.dcu file lives in $(BDS)\Lib path for Delphi 2007.
The "File not found System.pas" error often isn't really because it can't find system.pas. It's some other problem that manifests as this error.
It can be:
Duplicate Path entries in the Library Path.
Too many entries in the Library Path - I think the limit is 99.
Path to a package in Library Paths too long.
Path to a package in Library Paths corrupt.
Environmental Variables not set correctly.
and possibly more if you Google "system.pas not found"
Marjan is right.
But also add ${DELPHI}\LIB\OBJ
If you still have a dcc32.cfg with the project, or a .cfg with the project, open it up to see if the settings in there are correct. Otherwise delete the .cfg or edit it to reflect the proper path to the bin and bin\obj directories.
A .dpr file is the main project file for a Delphi 2,3,4,5,6,7 project.
You have not given any details like WHAT WAY OF BUILDING SOMETHING of delphi you're using (the code is Delphi 5 level code, but you are not telling me for example, if you built the project inside the Delphi IDE or from the command line compiler DCC32), and what other files you have installed. You haven't mentioned if the library paths and so on are configured (either for the IDE, or for the command line environment, both of which are separate tasks).
An inability to find System.pas suggests to me that you might be running the command line compiler (Dcc32) instead of the IDE to build the project, and you have forgotten to mention that. That usually means you have to set up the Options (dcc32.dof) file for Delphi, so that command line building with Dcc32 can work.
What exactly do you mean by "When I compile with the .dpr file"? Instead of making people guess, show the commands you typed, exactly, and the error message, exactly. If it helps, use screenshots or text grabs.
Related
When I tried to compile one of my BPL files, I get an error:
dxGDIPlusClasses.pas not found.
I double checked the unit file exists on the hard drive.
I also added $(BDSCOMMONDIR)\Dcp to the DCP Output directory, and $(BDSCOMMONDIR)\Bpl to the Package Output directory. The runtime package containing the unit was also added to the BPL.
I searched online for answers, foound one suggestion to enable Build with runtime packages under the Project Options, but when I checked I dont have that option.
Does anyone know how to solve this?
The error message indicates that either:
the compiler can't find the source file it needs for the unit.
the compiler found a .dcu file compiled with a different version of the compiler and needs to recompile it.
.dcu files are not compatible across compiler versions (with the single exception of D2006->D2007), meaning that every new version release of the compiler means all your source needs to be recompiled in order to be compatible with it.
You need to add the path to the source to Project->Options->Directories and Conditionals->Search Path so it can find the source code it needs.
[DCC Fatal Error] Unit1.pas(7): F1026 File not found: 'MyBitBtn.dcu'
Unit1 is a VCL Form for test purposes.
I have installed a design time package which contains a custom component that derived from TBitBtn. I can load the MyBitBtn in the Delphi IDE, load up the custom images I coded in design time and it seems like it works fine, at least visually. I get the above compile time error when I try to compile the test project.
I have a package group that has one design time package and one run time package. Design time package registers the component and Runtime package inherits the TBitBtn and has the custom code in it. The design time package contains the RunTime DCP file in the requires section.
The moment I insert the custom button on the test form, IDE creates the USES clause for MyBitBtn file. And that file apparently can't be found. Shouldn't that be part of the package installed?
Most probable you did not set 'Unit output directory' option in your runtime package, so package .dcu's are not available; I usually set it to $(BDSCOMMONDIR)\Dcp and have no problems.
Generally, the .dcu's of a runtime package should be available via global IDE library path if you want your package to be available to any project:
.
You should either use one of the existing paths or add your own.
The design part works, but for run time, the compiler must be able to find the dcu.
You can do that either...
By adding the dcu folder to the library path of the IDE.
By adding the dcu folder to the search path of the project.
Or by adding the dcu explicitly to the project.
I would choose the first option. Since it's an installed component, you would want it to be available for any project, so setting the library path makes the most sense.
define the path where this dcu is stored in system environment. And dont forget to include it in Delphi env paths.
Go to ZEOS files, open packages, choose your version(DelphiXE10/Delphi7 ...) then go to the Win 32 file, open it and open Debug folder. Copy every thing, go to Program Files, Embarcadero, Studio, 17.0, lib, Win 32, Debug and paste, do the same in every win32 folder... Hope it helps :)
I have a component package in Delphi XE2 version 16.0.4429.46931, both a run-time and design-time package together. This package has existed for over a year, and the file/folder structure has always been the same. I keep all the units in a dedicated Source folder from the root, and the actual packages in a Packages folder in the same root. So the packages are found in \Root\Packages\ and units are found in \Root\Source\.
Today, after building the run-time package, I was going through the hints and warnings. One of the warnings was this:
[DCC Warning] Inno.TimeChart.pas(1): W1025 Unsupported language feature: 'class constructor'
The warning its self is not what worries me. The problem is when I double-click this warning, I get an error message from the IDE:
The one thing which I immediately noticed was that it is not looking in the Source folder, but rather directly in the Packages folder. Somehow, the IDE is expecting that the unit be in the same location as the package. Ever since I created the package over a year ago, I have never changed any of the library paths, locations of files, or structure of the package.
The file does exist, but in a different place than it appears to be looking. The file has never been saved in the folder with the projects, and in fact nothing other than the package projects themselves have ever been saved in the Packages folder. This all resides in the Source folder, but the IDE seems to think otherwise.
Why would the IDE think this file is in a different folder? All the other hints and warnings related to the same unit work just fine when I double-click them, but not this one.
EDIT
I've created a new test package to troubleshoot this issue.
Root\TestPackage.dpr
Root\Source\TestPackageUnit.pas
The specific piece of code which is causing this compiler warning is in this class:
type
TMyComponent = class(TComponent)
strict private
class constructor Create;
end;
When I compile, using Process Monitor, I see the IDE is searching in 30+ different places for this file (of course failing), it looks like it's searching in every library path, rather than in the one place the package says it's at.
Things I've Tried
Verified there is no difference between these paths between the DPR and DPROJ files
Installed all the latest updates and the IDE FixPack (actually gave me new problems)
Monitored file's access with Process Monitor
Filters: process name equals BDS.exe; Path ends with TestPackageUnit.pas
Result: "NAME NOT FOUND" --> Desired Access: Generic Read Disposition: Open Options: Synchronous IO Non-Alert, Non-Directory File Attributes: N ShareMode: Read, Write AllocationSize: n/a
Tried with designtime-only, runtime-only, and designtime/runtime combined
Tried with component registered and unregistered
Tried with directory in library path and not in library path
Removed about 20 unnecessary entries from library path to make it shorter
Moved directory to top of library path
Verified there is no DOF file associated with project (That I think is from older versions)
Restarted IDE and computer number of times
Cleaned up compiled and temporary files from project, including BPL and DCU files
Changed strict private to just private and even public
I do run into such problems when the delphi search path list is too long. I could always help myself in moving the relevant directories more to the front, i.e. up in the list.
Check that the file has not been added to the project file (dpr or dpk). Project - View Source will display the file.
If this isn't the case, try searching all the files in your project for the file name and see what turns up.
Found this on another website:
There is another QC that is probably linked to your problem.
http://qc.embarcadero.com/wc/qcmain.aspx?d=87693
Go to Project Options -> Delphi Compiler -> Output C/C++ and under
C/C++ output file generation select Generate DCUs only.
Dalija Prasnikar
Source: http://codeverge.com/embarcadero.delphi.general
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
In Delphi, I can include a folder's source code by adding it to the project Search Path, or adding it to the Library Path. The Search Path applies only to the current project, while the Library Path applies to any project opened with the IDE.
Other than that, is there any functional difference between the Search and Library paths?
My reason for asking: I have a folder X with source used by project A. When I include that folder under Project A's search path, it says it cannot find a specific file in that folder. When I include it under the Library path, then project A compiles fine.
Until now, I was always under the impression that the only difference was that one was project-specific, and the other was global.
While we're on the topic (and at the risk of making a fool of myself): What is the functional difference between "library path" and "browsing path"?
As far as I know, browsing path is where the debugger should look for files when breaking/stepping into source files thats not in the library path.
Lets say that you have a thirdparty component that you use. You point the library path to the directory where the pre-compiled dcu-files of that component are. Your project will use these dcu-files when you compile. This is good, because it wont be recompiled every time you do a build.
But by including the compiled dcu files, you loose the possibility to debug the thirparty component. If you include the path to where the source files are in the browse path, the debugger will find the source, and allow you to step in to it.
The default settings for the vcl show this. In library path they have put $(BSD)\Lib, and in the browsing path they have put $(BDS)\SOURCE\WIN32...
Update: There are two different kind of search paths: Compiler search path and debugger search path. The first is there the compiler looks for files during compiling, and the second is where the debugger looks for source files during debugging.
The compiler will only find files in the Library path or the projects search path.
The debugger will find identifiers in the compilers search path plus the browsing path, the debug source path for the project, and the global debug search path.
There should not be any difference in specifying things globally or pr project.
The “Library path” field
This is the path where the compiler looks for files that it needs when it compiles our project.
There are three main categories of paths that we will find here:
On the first lines we can see listed Delphi’s own precompiled DCUs. We will talk about precompiled DCUs soon.
These paths are added here by Delphi’s installer. Don’t touch them, or you will fuckup the whole Delphi and you will have to reinstall - unless you have a backup of the appropriate registry key, which is: KEY_CURRENT_USER\SOFTWARE\Embarcadero\BDS\21.0\Library\
Next, if you installed 3rd party packages/libraries using their automatic installers, you will see their paths here. Usually, only the folder containing the DCU files (not the Pas files) will be listed here. Here are some examples:
These paths are automatically added by the above-mentioned installers.
If you want to use 3rd party libraries (such as LightSaber) that don’t have an automatic installer, you will have to enter their path manually, as described below (point 3).
Finally, if we built our own library, we would want to manually put the path to this library here.
The “Browsing path” field
If we Ctrl+Click in the IDE on a routine (like Application.ProcessMessages), the IDE will take us to the source code of ProcessMessages which is in:
c:\Delphi\source\vcl\Vcl.Forms.pas
How can the IDE know where to look for Vcl.Forms.pas when the “c:\Delphi\source\vcl” folder is not in Library Path?
This is done by Browsing Path. If we look into the “Browsing Path” we see that the VCL folder is already there:
When the IDE cannot find an identifier (function, variable, etc) in project’s “Search path” it starts to search in “Library path”. If the identifier is also not there, the IDE looks into the Browsing Folder.
It is critical to understand that the folders listed in the “Browsing Path” are accessible to the IDE (and also to the debugger, so we can step into the source code of our libraries while debugging) but not to the compiler.
So, in “Browsing Path” we add the folders that hold units that we want to be able to see/browse with Ctrl+Click in the IDE, but we don’t want to be found by the compiler.
I think Embarcadero team screwed up a bit here. They should have used “Compiler paths” instead of “Library paths” and “IDE paths” instead of “Browsing paths”.
The “Debug DCU path” field
The documentation says, “Specifies the path for the Delphi-compiled units used for debugging”. What it means is that it contains the folder where the Delphi’s debug DCUs are located (see the “Precompiled DCUs” section). We should not touch this.
Usually, we will only have a single folder listed here:
The “Debug source path” field
“Debug source path” is a less obvious place where we can enter paths. Here we enter paths to the Pas files that we have them precompiled to speed up the general compilation speed of your project. Note that this is located under the “Embarcadero debuggers” page and not under the “Library” page:
The “Use debug DCUs” field
Delphi’s units are coming precompiled in two “flavors”: the debug and the release flavor.
So, one might be inclined to think that when we compile our application in Debug mode, the compiler will implicitly use the debug DCUs for RTL/VCL framework. It doesn’t. The compiler will use the debug DCUs for our code, but not the debug DCUs for the RTL/VCL library.
And we can test that easily: we simply build our application in Debug mode and put a breakpoint somewhere in its source code. We will speak about breakpoints and debugging soon. We will see that we can step into our routines when we press the F7 key. But if we try to step into a Delphi routine (let’s say Application.ProcessMessages), we simply can’t. The debugger won’t go in that routine because Delphi compiled the “release” version of Vcl.Forms.pas (the unit where ProcessMessages resides) even if our app was compiled in “Debug” mode.
To force the compiler to link the “debug” version of its VCL/RTL library, we need to activate the “Use Debug DCUs” check box in “Project options”. Careful here! I said, “Project options”, not Delphi’s “Global options”:
When to activate the “Use debug DCUs”?
If “Use Debug DCUs” option is not activated, and we debug our application, we can only single step through our own code. This is what we want in the most cases, because it is our code that is buggy, not Delphi’s code. It will be quite annoying to keep stepping into Delphi’s code.
We activate “Use Debug DCUs”:
• If we want to see how Delphi is working internally – for example, when we want put a break point inside ProcessMessages to see when it is executed.
• If we think we have found a bug in the RTL/VCL
Note: After we activate this option, we need to rebuild our project! For some changes it is enough to compile, but for others it is not enough. I haven't spent the time to make a list about which ones need to compile and which ones need to build. So, as any lazy person, I always Build, after changing project's options.
Debugger will also find files in Library Path.