Go 1.3 Linker Overhaul • Hacker News Board

Re: Go 1.3 Linker Overhaul

#31

Post by cpeterso » Thu, Nov 28, 2013, 7:43 PM UTC

singular wrote: post #26

cpeterso wrote: post #25

Earlier quoted context omitted.

Firefox build times are much faster than that. My MacBook Pro can build Firefox in 12 minutes, but other people can build everything in less than 8 minutes ! :) https://groups.google.com/d/msg/mozilla.dev.platform/HdXdNdf...

Wow. I'm really impressed with that. I'm looking at >1hr on a mid-2012 Macbook Pro Retina for Chromium.

Mozilla is always looking for new contributors. Think how much more productive you could be with such fast Firefox builds! ;)

* Videos on how to download, build, and debug Firefox code: http://www.codefirefox.com/

* Good first bugs: http://www.joshmatthews.net/bugsahoy/?cpp=1&unowned=1

Re: Go 1.3 Linker Overhaul

#32

Post by LukeShu » Thu, Nov 28, 2013, 8:38 PM UTC

acqq wrote: post #17

jlouis wrote: post #14

Earlier quoted context omitted.

Go links static executables only.

Thanks. In my top post when I asked about intra-modules optimizations I've naturally meant "compiler produced pre-linking object" modules, but after the discussion I've recognized that I totally missed that "already compiled objects loaded for execution" (i.e. .so or .dlls) are also an important feature for a language that intends to support seriously big projects. Are there any plans for making ".so" modules in nati…

> Are there any plans for making ".so" modules in native Go?

Not from the main team, no. They support compiling `.a` library files that can be statically linked, but the authors of Go generally consider dynamic linking to be harmful.[0]

However, because Android development requires `.so` files, the goandroid project[1] contains patches to make go support shared libraries.

[0]: http://harmful.cat-v.org/software/dynamic-linking/ [1]: https://github.com/eliasnaur/goandroid

Re: Go 1.3 Linker Overhaul

#33

Post by noselasd » Fri, Nov 29, 2013, 4:27 PM UTC

acqq wrote: post #4

Interestingly, they want to do the opposite of what Microsoft did with their C++ compiler and linker. To enable "whole program optimizations" Microsoft's compiler writers added the intermediate code analysis, optimizations and code generation to the linker, allowing to, for example, if it is beneficial, inline function invocations for small functions that aren't declared as inline and that come from the different mod…

> Did Go ever use intra-modules optimizations in their linker?

gcgo can do inlining across module boundaries.