I've installed unDelphiX to my Delphi 2010, but I can't run even a simple example program, I always an error message:
F2051 Unit D3DX9 was compiled with a different version of Direct3D9.TD3DFormat
I never worked with unDelphiX and I have no idea what this error means.
Can someone please explain it to me and how can I resolve it?
Just Google for "was compiled with a different version of" (exact phrase) and you will find plenty of answers. Basically, the dcu files you are using have been compiled with a different version of Delphi than the Delphi version you are using.
Link to the Delphi Documentation: http://docs.embarcadero.com/products/rad_studio/delphiAndcpp2009/HelpUpdate2/EN/html/devcommon/cm_version_conflict_xml.html
Doc doesn't clarify much though. What you need to do to resolve it:
Compile the sources of the library with your Delphi version or obtain the dcu's compiled with the same Delphi version as yours.
Make sure that your environment or project's library path includes the folder in which either the library sources or the dcu's compiled with your Delphi version can be found.
Related
I use Delphi 10.1 Berlin Starter and have the following problem:
Is added some packages by opening them, and installing them by right-clicking on the package in the project manager and choosing "install". The compiled packages are now in the same folder as the other packages Delphi uses, so I think that there cannot be a problem with the library or search path.
The packages also added some Components that are now accessible in the tool palette. If I add one of these components to my program, Delphi automatically adds the unit name of the component to the "uses" section of the unit containing the component. But if I want to compile, Delphi throws the fatal error "could not find unit_name.pas".
How can I fix this? Does the units required to build and install the packages have to be included in a library path?
Maybe this is a compatibility problem. The packages were written in 2008 (Are Namespaces in Delphi younger?), so maybe the way the package wants to tell the compiler what to do does not work anymore.
This question might be difficult to understand (I had some problems to explain it...), so please comment, if you need more information.
Quite easy, I just had to add the units of the package to the library path (Tools->Options->Delphi Options->Library). Worked. Thanks to KenWhite.
I have my Delphi application up and running in XE2.
I am using fastreport provided with IDE.
When i tried to migrate from Delphi XE2 to delphi 10.1, I get issues for fastreport.
[dcc32 Fatal Error] fs_isysrtti.pas(615): F2051 Unit fs_iinterpreter was compiled with a different version of fs_isysrtti.TfsSysFunctions
I have added lib path in tools->options.
What can be issue over here?
The error message means what it says: there is a mismatch between the current version of fs_isysrtti and the one which was current when fs_iinterpreter was compiled. This is probably because the compiler is finding an out of date copy of fs_iinterpreter.dcu before the one it ought to find. Try searching your machine for versions of this .dcu file and renaming/hiding all except the newest (or the one in the same output folder as the compiler is trying to compile fs_isysrtti to, which is hopefully the same thing).
If your system is anything like mine (I have XE4 to D10 Seattle installed) you will find a number of versions of these dcus (fs_iinterpreter.dcu, that is).
Assuming this procedure removes the compiler's complaint, one-by-one reinstate the dcus you renamed or hid until the problem re-occurs and then you know which copy is causing the problem. Then work out how the D10.1 compiler is managing to find it and prevent it. Possibly, the compiler search path is causing it to look in the wrong place before the correct one.
Unfortunately, even if you manage to find the .dcu that's causing the problem, you may then find that the compiler raises a similar complaint about another Fast Report .dcu. If is does, then your easiest option may simply be to hide/rename all the FR files and reinstall it.
Uninstall FR, install it again and remove pas files from LibD24 folder
or
install all updates for Delphi 10.1 Berlin and use latest FR 5.5.11
I 've just got the same issue when I tried to convert old quickreport files to Fastreport 6.2.1 (Delphi 10.3.3 64 bit Target)
I found an easy solution here:
https://wiert.me/2016/06/30/built-in-delphi-xe6-xe7-and-xe8-fast-reports-have-issue-f2051-unit-fs_iinterpreter-was-compiled-with-a-different-version-of-fs_isysrtti-tfssysfunctions/
if the link wont work:
you have to move the *.pas files from the path
"c:\Program Files (x86)\FastReports\LibD26x64"
(it was my path, check yours. /where the fs_isysrtti.pas/)
and it works.
I'm running Delphi XE2 w/ update 3.
I've just checked out the read-only branch of DWScript from the svn repository. I try to install dwsLib.dpk from the DelphiXE2 folder but receive the following error:
[DCC Fatal Error] dwsLibRuntime.dpk(30): E2225 Never-build package 'designide' must be recompiled
I tried building dwsLibRuntime.dpk first, but I get an error about missing TdwsUnit component, so that doesn't work, either. I'm not having any luck finding contact info for the author, so am trying here.
Any advice would be greatly appreciated.
The short answer is: DWScript doesn't target Delphi XE2.
Quote:
DWScript lead platform is currently Delphi XE, compatibility with
Delphi 2009 & Delphi 2010 is maintained, but some features may be
restricted (RTTI f.i.).
You must fix the source code if you want it to work with Delphi XE2.
I.am using XE2 with the trunk code and it works fine. I loaded up each dpi (there are two) and built and installed the first. Then compile your code ensuring that you point to the source folders (there are at least three). Failing that I'll post you an innosetup exe that installs it into XE2 that I've made,
I'm trying to use the JclCompression unit, but when I do, the compiler always says:
Unit JclCompression was compiled with a different version of sevenzip.IOutArchive
What am I doing wrong here? I tried recompiling/installing my JEDI installation, but it didn't seem to help.
The compiler is finding a DCU that was compiled with a previous version of Delphi. You don't say what version of Delphi you are using, but DCU's from one version won't work with those of different version.
The first thing to check is to see if you have your paths right. If you have compiled the JCL previously, it may be that your path is causing the compiler to find the old DCU files, and thus the error.
In addition, the problem may be that you have an out of sync version of Sevenzip code as well.
Bottom line: the compiler is finding a DCU that isn't compatible with your current version of Delphi. Either:
get the right DCU version
find the source and compile it
Ensure that the compiler is looking in the right place for what you are trying to compile
This question already has an answer here:
Step by step upgrade of Indy 10 in Delphi 2009
(1 answer)
Closed 3 years ago.
Is there a step-by-step guide for updating the Indy 10 components in Delphi 2009?
I've read the uninstalling thread and have the latest build (IndyTiburon.zip). However there appears to be no installation instructions.
If you have accomplished this, please share the details.
Edit: I have managed to get the packages installed by messing with the "requires" section in dclIndyProtocols120 and dclIndyCore120.
Essentially removed all Indy package dependencies from "requires" section and just used the Library path resolve things. Added ..\Lib\Core, ..\Lib\System and ..\Lib\Protocols to the Lib path. Had to leave dclIndyProtocols120 in requires for dclIndyCore120 as it wont install without this.
All 3 packages compiled (including IndySystem120) and seems to be working okay now.
This should be easier for D2009 users. I had to update to resolve an SMTP bug in Indy (see link).
On this question there is a more satisfying answer.
For all versions before D2009 you can use a Fulldx.bat script to recompile the packages and then just open the BPL files in (for example Indy-10.5.5\D6\dclIndyCore60.bpl and Indy-10.5.5\D6\dclIndyProtocols60.bpl) in the Delphi 2009 IDE packages dialog. Now with Delphi 2009, the FullD12.bat is there but it is not doing anything.
My simple solution is to create Indy components at run time only. I add the Indy Tiburon Core, System and Protocols to the projects search path, and also use Apache Ant with a build script to run the compiler for the final build.
One IIRC needs to compile system core and protocols in that order.
Moreover a package is a .BPL and a .DCP. So you probably would have to copy the .bpl and the .dcp to that directory in a normal case. The .BPL is what programs need to run, but to compile something that uses the .BPL (statically) you also needs the .dcp.
But that doesn't work for the Indy caseafaik because it also needs includefiles, so you need to add all their paths to the library path.
IIRC is that Delphi (at least the versions that I know) don't add directories to paths when installed, and one must always add paths to directories with .dcp or .dcu's manually.
(contrary to Lazarus that builds a list of dirs from the installed packages. But partially that is maybe also a fix for not having something akin .dcp yet, and in generally be more source oriented)
Note that I don't have D2009, it is just experience from general manual Indy compilation.
Maybe a simple method for anyone looking 10 years later... (tested under Delphi XE5):
Download the latest Version from https://indy.fulgan.com/ZIP/.
Extract the ZIP-archive into a folder of your choosing (I made a folder "Delphi Lib" under my Documents).
Throw out all Indy .dcu Files (Indy[...].dcu and Id[...].dcu) from your Delphi installation (for Example: C:\Program Files (x86)\Embarcadero\RAD Studio\12.0 (The last folders name may vary on your installation))
Open Delphi and go to Tools -> Options. Get to the "Library"-Listing and add the following folders of your newly downloaded Indy: /lib/Core/, /lib/System, /lib/Protocols.
As always: Help yourself and make backups before deleting anything. You do not want to reinstall your comlete Delphi because you threw away a file you should've kept...