Re: Go (golang) packaging, part 2

[Florian Weimer <fw@deneb.enyo.de>]

* Steve Langasek:

> Actually, if you look closely, you'll find that the traditional Java
> .jar linking resolver precisely mirrors the behavior of the C linker
> on Solaris from the same era (allows you to link dynamically, but
> requires top-level objects to be linked at build time with all the
> recursive dependencies of the libraries it uses).

I don't think this is actually true.  The Class-Path manifest
attribute has been around since almost forever (1.2 probably).  It
serves the same purpose as the NEEDED attribute in ELF, and avoids the
need for dependencies to bubble up to the final link.

Most Java linking is done differently, probably because relatively few
people now about the Class-Path attribute.  Others use other module
systems not part of the JDK, of course.  But the Class-Path attribute
alone gets you very far.