How can I install my own copy of Indy10 from source, in Delphi XE4, if I get “not a valid win32 application” error?

3
votes

Using the latest Indy10 sources from subversion, installing in to Delphi XE4, I get this error when I try to install "dclIndyProtocols180.bpl":

Error: 
Can't load package C:\dev\..\comp\Indy10\Lib\Output\BPI\Win32\Debug\dclIndyProtocols180.bpl.
%1 is not a valid Win32 application.

The BPI\Win32\Debug folder in question contains these files:

dclIndyCore180.bpl
dclIndyProtocols180.bpl
IndyCore180.bpi
IndyCore180.bpl
IndyProtocols180.bpi
IndyProtocols180.bpl
IndySystem180.bpi
IndySystem180.bpl

How do I fix or work around this? I am not exactly new to Indy, or Delphi, but each time there's a new delphi release, there are interesting surprises for those of us who prefer to build from source code and track subversion rather than using that random point in time which ships with the Delphi XE4 installer.

As a general side question: Is there any place where the status of the Indy project's subversion code, compared with whatever Embarcadero ships in their products is noted, or recorded?

1
delphiindydelphi-xe4
first thing that comes to mind (even if the path says Win32) is that it could be a 64bit compiled bpl. – Mirco Ellmann
Yeah, I think it's because Indy10 is targetting Win32, Win64, and iOS now and its default DCP and BPL output paths are these new baroque subdirectory structures. I believe that by reverting the Win32 targets back to classic $(BDSCOMMONDIR)\Bpl and $(BDSCOMMONDIR)\Dcp I can get Win32 to build, which is all I care about. – Warren P
responding to your side question: the answer is in the svn log, Indy 10.6.0 (XE4 release) is revision 4990 in svn. current rev is 5004 – whosrdaddy
Yup, those will be 64 bit DLLs with that error message – David Heffernan
In Indy's SVN, various IDE releases (except for XE3, yet) from 2010 onwards have been tagged so you can see which SVN revision shipped with which IDE release. – Remy Lebeau

1 Answers

0
votes

By default a new package in Delphi might automatically be 64 bit, or you may have built a dependency as a 64 bit BPL, but not have switched to 32 bit for that BPL and rebuilt it.

Also you might have folders in your Library path that allow 32 bit and 64 bit BPls to try to load each other, causing this issue.