Library size when built with mingw

[Caleb Champlin]

After more effort than I would have anticipated I finally got a new version of v8 (5.0) to build on mingw. I noticed however that v8lib_base.a is huge! Rougly 310MB.

drwxr-xr-x    1 x x  4096            Apr  7 16:39 .

drwxr-xr-x    1 x x  0                 Apr  7 14:36 ..

-rw-r--r--       1 x x  322118626   Apr  7 16:19 libv8_base.a

-rw-r--r--       1 x x  252536        Apr  7 16:22 libv8_libbase.a

-rw-r--r--       1 x x  690768        Apr  7 16:22 libv8_libplatform.a

-rw-r--r--       1 x x  1033412      Apr  7 16:22 libv8_snapshot.a

Here's how I built:

GYPFLAGS="-Dv8_use_external_startup_data=0" CFLAGS=" -msse -msse2 -msse3" CXXFLAGS=" -std=c++11 -msse -msse2 -msse3"  CFLAGS_host=" -msse -msse2 -msse3" CXXFLAGS_host=" -std=c++11 -msse -msse2 -msse3" make i18nsupport=off x64.release

I built as release, and I'm basically wondering if it's normal for the file to be this large. I was able to successfully link a Go application against and everything with V8 seemed to work fine. 

Thanks.

[Jochen Eisinger]

That's indeed quite large. I'd expect more like 11MB. You could use ar to inspect the contents of the file.

--
--
v8-users mailing list
v8-u...@googlegroups.com
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to the Google Groups "v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Zac Hansen]

I'm trying to do this right now and having a helluva time trying to figure this out.

Can you post the steps you took to get this far?   I ended up with very large .a files on OS X (much larger than what you're seeing), but the linked binaries files were only ~35-40MB.  

[Zac Hansen]

On OS X I see that file get as big as ~800-900MB.   The linked binaries are only around 35-40MB, for a programthat would otherwise be quite small.

[Brendan Bates]

Hey Zac,

I'm also trying to build on MinGW right now.  I have successfully built on MSVC2015 but would much prefer MinGW (as all of our other products run under MinGW in Windows).  I  have had no luck thus far, have you been able to successfully build yet?  I personally haven't got very far...

[Zac Hansen]

Unfortunately no.   I gave up and went with the vs build.  I was happy to be able to make it build with the actual 2015 tool chain so that was nice.   It defaults to the 2013 toolchain.  

--

--
v8-users mailing list
v8-u...@googlegroups.com
http://groups.google.com/group/v8-users
---

You received this message because you are subscribed to a topic in the Google Groups "v8-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/v8-users/fQM0NVT6mJ8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to v8-users+u...@googlegroups.com.

[Brendan Bates]

Bummer, I figured so.  It seems as if MinGW support has been mostly abandoned at this point (not sure if it was ever really there to begin with).  Of course the IDE we use (JetBrains CLion) doesn't allow building with the MS toolchain.  If I ever do get around to toying with v8 and MinGW again I'll be sure to post here.

To unsubscribe from this group and all its topics, send an email to v8-users+unsubscribe@googlegroups.com.

[Caleb Champlin]

I've put together a quick guide and patches for getting v8 building for MinGW, available here: https://github.com/cchamplin/v8-mingw-guide. If you want to test it and let me know that would be great. If everything seems functional with the code changes I'll work on clean up and getting them pushed upstream.

Thanks

[Zac Hansen]

> (not sure if it was ever really there to begin with). 

It's officially not supported, but they will take patches

> IDE we use (JetBrains CLion) doesn't allow building with the MS toolchain.

It uses cmake though, so you can always tell cmake to generate a build config for VS.

> I've put together a quick guide and patches for getting v8 building for MinGW

Very cool.  I'm not sure I'll have a chance to play with it any time soon, though, as I'm in the middle of some work that doesn't involve v8 right now.

Thanks for putting the effort into it and I hope the main branch starts working with MinGW (again?) soon!

--Zac

Thanks

To unsubscribe from this group and all its topics, send an email to v8-users+u...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

--
v8-users mailing list
v8-u...@googlegroups.com
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to a topic in the Google Groups "v8-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/v8-users/fQM0NVT6mJ8/unsubscribe.

To unsubscribe from this group and all its topics, send an email to v8-users+u...@googlegroups.com.

[Brendan Bates]

I'm attempting using your fixes.  I've made some progress, had to change one thing so far.  The bundled Python is now moved out of the v8 folder and into the depot_tools folder.  I had to apply the "forking.py" patch in there.  All other patches seem to work.

I've hit one roadbloack, however.  When running the final make command to trigger the build, it regenerates the "Makefile.ia32.debug" makefile before it attempts a build.  As a result, all of the patches in that file are lost and the build fails:

    make[1]: *** No rule to make target `../test\intl\intl.gyp`, needed by `Makefile.ia32.debug`.  Stop.

I'm trying to figure out what causes the makefile to regenerate, however I'm not too familiar with Gyp so I may not put too much time into this today.  I will post again if I can get further than this.  Thanks a ton for putting that up on Github - hopefully I can get somewhere with this!

[Brendan Bates]

Update - Holy Guacamole, I've gotten v8 to build with MinGW!

Never thought I'd see this day come again.  I actually went a slightly different route with it - here are the things I changed:

1. Apply the forking.py fix to depot_tools instead of v8.
2. REMOVE lines 73 and 78 in the mingw-generate-makefiles.sh.  It now shouldn't delete existing makefiles or call into the make routine.
3. In the top-level Makefile, add the following after line 447:

./tools/mingw-generate-makefiles.sh

Now, you should be able to call the make command.  It will use Gyp to produce the proper makefiles, run the makefile patching script, then run the build.  I may be able to condense all of this (including the git patching) into a single bash file.  If I do this, I'll fork your repo and give it a try.