fatal error LNK1127: library is corrupt

[miked...@gmail.com]

Hi Folks,

Wondering if anyone has seen this type of issue before and can help me out. I'm trying to build V8 on Windows per the instructions here:

https://github.com/v8/v8/wiki/Building-from-Source

Environment:

Windows 10

Visual Studio 2017 Enterprise with the C/C++ Workflow Components installed (so, ATL, MFC, much, but not all of, the Windows 10 SDK)

Added additional Windows 10 SDK components as I discovered they were needed. For example, the debugger component seems to be required but that SDK component isn't laid down by Visual Studio's installer.

Got to step 7 which meant I had built with no errors and ran all the tests. I assume the run tests step runs tests with the binaries I actually built and that they ran on my machine and not somewhere else. So with all of that, I would think building my own app would be straightforward because everything I would need would be in my built output directory.

And therefore, I started a new C++ console application project in Visual Studio and copied the source for this hello-world program into the new project I created

https://chromium.googlesource.com/v8/v8/+/branch-heads/5.8/samples/hello-world.cc

Set VS include paths and lib paths to find things in my V8 directory. The program compiles with no errors but will not link. This is the error:

1>D:\Google\v8\out.gn\x64.release\obj\v8_libplatform.lib : fatal error LNK1127: library is corrupt

These are the only two lib files I have in the built output and these were both added to the linker's input in the settings property page in Visual Studio

D:\Google\v8\out.gn\x64.release\obj>dir *.lib

 Volume in drive D is New Volume

 Volume Serial Number is BAF3-FE69

 Directory of D:\Google\v8\out.gn\x64.release\obj

10/06/2018  07:50 PM            82,222 v8_libbase.lib

10/06/2018  07:50 PM            49,120 v8_libplatform.lib

Any ideas why the CL linker can't use the libs produced by my GN build? As I mentioned, the tests ran on my machine and I felt it was a safe assumption to assume those tests were also built (and linked) against these libraries. Maybe not?

Thanks

Mike

[Dan Pike]

Hi Mike,

I vaguely remember seeing the error that you get when i tried following the instructions. I'm not an expert, but here are the options that I am using at the moment:

tools\dev\v8gen.py gen -b ia32.debug "ia32.debug" --no-goma --
fatal_linker_warnings=false is_clang=false
treat_warnings_as_errors=false

I think that the key one for your particular problem may be the "is_clang=false" option. I'm not sure if you still need the others, because I can't get it to link mksnapshot.exe at the moment, either!

Hope it helps,

Dan

[miked...@gmail.com]

Thank you Dan. I'll try some of those settings you provided. Through various forms of hackery I was able to determine that if I build the DLL version of the library using is_component_build=true the lib files and a bunch of DLLs get generated and linking to those libs seem to work. So my POC is unblocked for now.

A little more information, those lib files I pointed to in my original post are not Windows COFF files. I don't know what they are but they aren't COFFS so thats why the CL linker won't load them. Interestingly, the build did produce OBJ files that were valid so I linked those all together into my own libs using Lib.exe and those I could use in my hello world project without errors. However those libs were missing most of the code needed to allow hello world to run. So I dug a little further and from what I can tell, the Windows x64 retail static library version of the build also does not include the core V8 code. So basically it is useless. The only remainng mystery is how that build that does not produce usable static libs seems to somehow be able to produce test files and even a helloworld of its own that do seem to run fine. But, since my POC is unblocked I'm going to press on. I've never been exposed to gn, ninja, mb etc until this weekend so I'm probalby not the best person to resolve these issues however if I get some time I'll try to learn more and see if I can submit some pull requests that improve the situation

Interesting that you are building ia32 architecture :). I haven't seen an IA32 machine for years!. 

[oga...@gmail.com]

The hardware is 64-bit but the EXE that my V8 code is running inside is still 32-bit. I haven’t seen any problems with running V8 in ia32 mode (yet). This system spends most of its time waiting for the user to type something, so performance is not a major issue and I haven’t needed to upgrade it.

 

That said, I’m also very new to V8 and still at the POC stage myself, so there may well be a 32-bit black hole lurking in the distance that causes me to upgrade the rest of it. That’s what makes this such a fun game to play. ;)

 

Dan

--
--
v8-dev mailing list
v8-...@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to a topic in the Google Groups "v8-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/v8-dev/Owki0O_JfE4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to v8-dev+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.