Watch, Follow, &
Connect with Us

QualityCentral

Public Report
Report From: Delphi-BCB/ActiveX/IDE/Import ActiveX Control/Type Library    [ Add a report in this area ]  
Report #:  102805   Status: Closed
Tlibimp: failing to import 64-bit typelibs with dependencies
Project:  Delphi Build #:  16.0.4276.44006
Version:    16.0 Submitted By:   Davy Kox
Report Type:  Basic functionality failure Date Reported:  1/22/2012 11:37:54 PM
Severity:    Serious / Highly visible problem Last Updated: 12/19/2012 7:53:30 PM
Platform:    All versions Internal Tracking #:   289588
Resolution: Fixed (Resolution Comments) Resolved in Build: : Update 4
Duplicate of:  None
Voting and Rating
Overall Rating: No Ratings Yet
0.00 out of 5
Total Votes: 6
Description
I'm working for a company that mostly develops code in C++. Central is a huge amount of COM servers and we have one developer here who also writes Delphi code on top of all this. At this moment we're porting all of our code to 64-bits and the Delphi code must come along too. Therefore we started working with the Delphi XE2 suite.

In the build process several TLBs are pulled in using the tlibimp tool. All went well, until we started a 64-bit only build on a clean build-pc. The trouble started with TLBs that had dependencies to other TLBs or DLLs which were also 64-bit.

After some investigating it seemed that all typelibs were neatly registered in both the 32- and the 64-bit registry. All guid-branches in the typelib part of the registry have a win64 branch. When I rename the 'win64' branch of the typelib that my typelib depends on to 'win32', the import succeeds when I do this in the 32-bit registry.

So my best guess is that there's something wrong with the lookup mechanism of the tool with regard to the depending libs. It seems that it only looks at the win32 branches in the 32-bit registry.
Steps to Reproduce:
Two IDL files for a testcase:

coordinate.idl:
[

uuid(A0A0A0A0-A0DE-11D4-A6AA-00C04F010BFD),

version(1.0),

helpstring("Coordinate 1.0 Type Library")
]
library CoordinateLib
{

importlib("stdole32.tlb");
// IUnknown, etc.



[


version(1.0),


dual,


oleautomation,


helpstring("Interface ICoordinate"),


uuid(A0A0A0A0-8FC7-4f33-9FDD-63F834B25634)

]

interface ICoordinate : IDispatch

{


[propget, id(1), helpstring("property x")] HRESULT x([out, retval] DOUBLE* pVal);


[propput, id(1), helpstring("property x")] HRESULT x([in] DOUBLE pVal);


[propget, id(2), helpstring("property y")] HRESULT y([out, retval] DOUBLE* pVal);


[propput, id(2), helpstring("property y")] HRESULT y([in] DOUBLE pVal);

};


[


version(1.0),


helpstring("CoCoordinate"),


uuid(A0A0A0A0-44A7-4a63-AC59-420F4F1B5DAA)

]

coclass CoCoordinate

{


[default] interface ICoordinate;

};
};


linearmath.idl:
[

uuid(A0A0A0A0-A45E-11D4-A6AA-00C04F010BFD),

version(1.0),

helpstring("LinearMath 1.0 Type Library")
]
library LinearMathLib
{

importlib("stdole32.tlb");
// IUnknown, etc.

importlib("coordinate.tlb");



[


version(1.0),


dual,


oleautomation,


helpstring("Interface ICoordinate"),


uuid(A0A0A0A0-8FE7-4f33-9FDD-63F834B25634)

]

interface ILinearMath : IDispatch

{


[id(0x00000001)]
        double CalcDistanceBetween ( [in] ICoordinate* A, [in] ICoordinate* B );


};


[


version(1.0),


helpstring("CoLinearMath"),


uuid(A0A0A0A0-44A5-4a73-AC59-420F4F1B5DAA)

]

coclass CoLinearMath

{


[default] interface ILinearMath;

};
};

- Build typelibs from the IDLs, (Make sure you generate 64-bit TLBs. I used the 64-bit midl compiler from VS2010, because GenTLB.exe from EX2 only creates 32-bit TLBs.)
- "c:\Program Files (x86)\Embarcadero\RAD Studio\9.0\bin64\TRegSvr.exe" coordinate.tlb (Check that the TLB is registered in the registry with a 'win64' part only.)
- "c:\Program Files (x86)\Embarcadero\RAD Studio\9.0\bin\tlibimp.exe" -P linearmath.tlb
Workarounds
Have the 32-bit dependencies available (in same dir or registered) when using tlibimp on the first TLB.
Attachment
Mutual_NDA.zip
Comments

Tomohiro Takahashi at 1/23/2012 3:30:01 AM -
> Build No: 16.0.4276.44006
Does your issue still occur with XE2 Update 3(16.0.4358.45540) ?

Davy Kox at 1/24/2012 1:26:32 AM -
Unfortunately update 3 yields the same results.

Davy Kox at 1/23/2012 6:59:51 AM -
I'll be able to test this tomorrow and I'll reply a.s.a.p.

This issue is currently also being addressed by Jean-Marie Babet on the forum: https://forums.embarcadero.com/thread.jspa?messageID=429386. He asked me to create this QC.

Davy Kox at 1/24/2012 6:53:24 AM -
I'd like to send some of our productioncode TLBs so you can try those, but my company won't let me without a signed NDA. Would it be possible for Embarcadero to sign this? I've uploaded it to the attachements section. A scan of a signed document should be sufficient.

Tomohiro Takahashi at 1/24/2012 5:50:28 PM -
If you need more intensive support and official reply from Embarcadero, please contact technical support service.
http://support.embarcadero.com/

Davy Kox at 1/25/2012 2:16:08 AM -
I've stated that tlibimp showed the same erroneous behaviour on Windows XP64 as on Windows 7. Probably I've been doing things wrong. I've retested the TLBs on Windows 7 and everything goes fine there.

This still leaves the problem for Windows XP64. This is used for all of our 64-bit buildservers, so I must get this working anyway.

Davy Kox at 3/18/2012 9:10:10 PM -
Meanwhile we've introduces some Windows 7 buildservers in our company and they show the same problems.

Jean Marie Babet sent me an experimental version of a 64-bit version of the tlibimp tool. That one uses 64-bit equivalents of API calls, which makes things go fine. However there were some other changes as well in the version that he sent me, so it's still not usable for our situation.

Server Response from: ETNACODE01

Copyright© 1994 - 2013 Embarcadero Technologies, Inc. All rights reserved.