[omniORB] omniORB with VC7

[Kevin Wooten]

I successfully compiled omniidl with VC7, using VC6 headers and =
libraries (just ignore default libraries and headers, then point  to VC6 =
directory include and lib directory). Although I think we can agree that =
this is not a "good" solution. I do not know of another way.

 Addressing your point about omniORBpy; Unaware of the differences in =
VC6 and VC7 I compiled it with VC7. I have been using it for a while, =
and have not had any noticeable problems, probably because omniORB is =
also VC7, and I am not using anything that is passing between python and =
omni* libraries. I suppose in time I will find something that breaks it =
though.

The only proper scheme I can think of is to compile Python with VC7 (and =
that is what I am doing).

Kevin

>> -----Original Message-----
>> From: Sandro Tolaini [mailto:tolaini@libero.it]
>> Sent: Wednesday, March 27, 2002 8:05 AM
>> To: omniorb-list@uk.research.att.com
>> Subject: RE: [omniORB] omniORB with VC7
>>=20
>>=20
>> On Wed, 2002-03-27 at 02:43, Kevin Wooten wrote:
>>=20
>> > Microsoft has changed the C runtime library DLL in version=20
>> 7. The new DLL is named MSVCR70.DLL, as opposed to=20
>> MSVCRT.DLL in 6. Python comes compiled with VC6 and thus=20
>> links with MSVCRT.DLL. When running omniidl, the idl source=20
>> file is opened by Python code and this makes the FILE=20
>> pointer Python passes back to omniidl invalid, as it was=20
>> allocated in MSVCRT.DLL, and omniidl attempts to use it with=20
>> MSVCR70.DLL. The fix for this problem remains to compile=20
>> omniidl in VC6, or compile Python in VC7. Although, I have=20
>> not tried compiling Python in VC7 so I cannot attest to its validity.
>>=20
>> I think you are right (I already noticed the double msvcr70.dll and
>> msvcrt.dll import in the omniidl executable).
>>=20
>> FILE struct changes are always source of havoc, as=20
>> FreeBSD-CURRENT users
>> experienced some time ago.
>>=20
>> Can we work out a good solution? Having to compile python extensions
>> with the same compiler used to compile Python is a mess... I=20
>> think that
>> this breaks omniORBpy, also.
>>=20
>> Cheers,
>>   Sandro Tolaini
>>=20
>>=20
>>=20