Bug 106989 – Get WebKit projects compiling in VS2010 (32 bit)

• Component: Platform
• Status: RESOLVED FIXED

[Roger Fong]

This include WebKitLib (which I'll probably rename to just WebKit), WebKitExportGenerator, WebKitGUID and Interfaces (which should probably be renamed into something like WebKitInterfaces).

[Radar WebKit Bug Importer]

<rdar://problem/13022852>

[Roger Fong]

minus WebKitGUID.

This project does literally nothing. 
No build scripts, no files in it, no output.
Last time it was modified was years ago.

Not going to bother removing it from the 2005 solution since we won't be using it soon anyways.

[Brent Fulgham]

(In reply to comment #2)
> minus WebKitGUID.
> 
> This project does literally nothing. 

It creates the WebKitGUID.lib, which can be linked to client programs to provide the GUIDs you need to instantiate WebKit objects.

Are you sure it's not needed?  I thought several of the test programs (and my own projects) use this library so they don't have to embed a WebKit.tlb file.

> No build scripts, no files in it, no output.

It produces $(WebKitBuildDir)\$(Configuration)\lib\WebKitGuid.lib.

> Last time it was modified was years ago.

The project doesn't need to do much, just compile the WebKit_i.c file so we can get access to the GUID symbols.

[Roger Fong]

Yeah, didn't realize that WebKit_i.c was a derived source.

[Roger Fong]

Hmm I wonder if it makes sense to combine WebKitGUID and WebKitExportGenerator into a WebKitGenerated project though. That would be nice.

[Roger Fong]

(In reply to comment #5)
> Hmm I wonder if it makes sense to combine WebKitGUID and WebKitExportGenerator into a WebKitGenerated project though. That would be nice.

Just kidding, guess we can't. One outputs a lib and one outputs an exe

[Roger Fong]

Is there a reason why the export generator works by creating an executable that prints the exports file? Why can't the script just directly print the exports file. That way I can combine WebKitGUID with the exports project.

Also we won't be able to merge a JavaScriptCoreGenerated project with a JavaScriptCoreExportGenerator if we stick with the way things are.

[Roger Fong]

Oh, I get it, preprocessor definitions. The definitions are also set as Macros though, I wonder if we can just feed those into the script directly.

[Roger Fong]

You're right Roger, that does sound gross, messy and unnecessary and we should just have a separate exports generator project for Webkit and JSC.

[Roger Fong]

> It creates the WebKitGUID.lib, which can be linked to client programs to provide the GUIDs you need to instantiate WebKit objects.

Hey Brent, do you know how this hooks in with WebKit.

I'm having trouble importing the symbols defined in WebKit_i.c.

I thought that what I had to do was import the lib file into the WebKit project but it seems that this is not the case (also the 2005 solution doesn't do this).

Including WebKit_i.c directly of course works and everything compiles wonderfully, but I'd rather not do that. Is there something I'm supposed to do with the tlb?
Thanks

[Roger Fong]

Created attachment 186199 [details]
WebKit projects!

[Roger Fong]

Relies on some changes I'm making to the WebKitLibraries folder which I'll commit soon as well.

[Roger Fong]

It would appear that the WebKitExportGenerator does not work in release mode.
Oddly everything still compiles. I guess the effect isn't seen until a project that needs to import the symbols comes along.

When I run the WebKitExportGenerator.exe it just crashes saying some dll's are missing (in particular MSVCR80.dll, shouldn't be searching for that anyways...wrong version. This leads to the actual exports file being completely empty.

Side Note: the same thing also happens when I tried to use my JavaScriptExportGenerator except it complained that pthreadVC2.dll was missing (although it seems to be there). The build actually does fail there though because jsc tries to import the symbols.

[Roger Fong]

 
> Side Note: the same thing also happens when I tried to use my JavaScriptExportGenerator except it complained that pthreadVC2.dll was missing (although it seems to be there). The build actually does fail there though because jsc tries to import the symbols.

Ignore side note: Fixed it. Now we have the same problem with MSVCR80 in both export generators.

[Roger Fong]

After doing some research it looks like this problem will arise if you have dll's that are compiled with VS2005 which I undoubtedly have. (A lot of the dll's that come in the WebKitSupportLibrary). 

I believe if I want this to work I have to install VS2005 and I'll get all the dll's/lib's I need with it. However I'd rather not have any dependence on old stuff. Ideally, these libs are recompiled in VS2010. Maybe they already are somewhere?

This problem will prevent me from developing in release mode. Debug mode seems to be fine however, I'm not sure why, but it seems to automatically link against MSVCR100. In fact, the dependency walker shows that the debug executable has no dependency on pthreadsVC2.dll and the like at all. I probably don't understand something about how debug mode works.

[Brent Fulgham]

(In reply to comment #15)
> After doing some research it looks like this problem will arise if you have dll's that are compiled with VS2005 which I undoubtedly have. (A lot of the dll's that come in the WebKitSupportLibrary). 
> 
> I believe if I want this to work I have to install VS2005 and I'll get all the dll's/lib's I need with it. However I'd rather not have any dependence on old stuff. Ideally, these libs are recompiled in VS2010. Maybe they already are somewhere?
> 
> This problem will prevent me from developing in release mode. Debug mode seems to be fine however, I'm not sure why, but it seems to automatically link against MSVCR100. In fact, the dependency walker shows that the debug executable has no dependency on pthreadsVC2.dll and the like at all. I probably don't understand something about how debug mode works.

Is this a problem caused by linking against two different runtime libraries (the VS2005 and VS2010 versions?)

You can probably get around installing VS2005 by just downloading the "Visual Studio Redistributable Libraries" installer.  These come with VS2005, but I believe Microsoft provides a separate set of downloads for them as well.  These will make sure the proper stuff is available in your Windows partition.

[Brent Fulgham]

(In reply to comment #13)
> It would appear that the WebKitExportGenerator does not work in release mode.
> Oddly everything still compiles. I guess the effect isn't seen until a project that needs to import the symbols comes along.
> 
> When I run the WebKitExportGenerator.exe it just crashes saying some dll's are missing (in particular MSVCR80.dll, shouldn't be searching for that anyways...wrong version. This leads to the actual exports file being completely empty.
> 
> Side Note: the same thing also happens when I tried to use my JavaScriptExportGenerator except it complained that pthreadVC2.dll was missing (although it seems to be there). The build actually does fail there though because jsc tries to import the symbols.

This sounds like the manifest file for the export generator is referencing a DLL you don't have.  Maybe CoreFoundation or something was built with VS2005 version X, and you don't happen to have the runtime libraries for Version X on your system.  This is called DLL HELL.

[Roger Fong]

Created attachment 186679 [details]
WebKit Projects! v2

[Brent Fulgham]

Comment on attachment 186679 [details]
WebKit Projects! v2

View in context: https://bugs.webkit.org/attachment.cgi?id=186679&action=review

Looks good.  I propose we (you!) land it so we can use it as a base for finalizing things.  It *might* be nice to use 'svn copy' to create some of these files that are duplicates of the things in WebKit.vcproj, just so the SVN history will show where they came from.  You might check with Jon or somebody to see if that's important to them.

I don't think this patch will land automatically, since it is not prefixed by the WebKit/Source/WebKit path, so you'll need to land it manually.

> WebKit.vcxproj/Interfaces/FixMIDLHeaders.pl:1
> +#! /usr/bin/perl -w

If this is a duplicate of the one in WebKit.vcproj, you might want to use a 'svn cp' command so that we see the history of the file (as it is 'moved' from the VS2005 location to this new location).

> WebKit.vcxproj/WebKit/WebKitCommon.props:11
> +      <PreprocessorDefinitions Condition="'$(Platform)'=='x64'">WIN32</PreprocessorDefinitions>

Is this right?  Or are you just placeholding until you do a true 64-bit target?

[Roger Fong]

Committed: http://trac.webkit.org/changeset/141924

[Roger Fong]

> > WebKit.vcxproj/WebKit/WebKitCommon.props:11
> > +      <PreprocessorDefinitions Condition="'$(Platform)'=='x64'">WIN32</PreprocessorDefinitions>
> 
> Is this right?  Or are you just placeholding until you do a true 64-bit target?

That's a mistake. The correct version of those conditioned preprocessor definitions are now in common.props. I'll get rid of these ones.

[Roger Fong]

> You can probably get around installing VS2005 by just downloading the "Visual Studio Redistributable Libraries" installer.  These come with VS2005, but I believe Microsoft provides a separate set of downloads for them as well.  These will make sure the proper stuff is available in your Windows partition.

Yeah, I was just hoping to use use anything VS2005 related at all.
I'm hoping that some of the runtime libraries get compiled in VS2010 soon (but until then I'll try installing the Redistributable libraries).