Long-winded discussion of static builds (was Are non-SJLJ exceptions busted on linux/x86?)

["Scott Gilbertson" <scottg at mantatest dot com>]

If I'm dead-set in the pro-static-builds camp (as I am), and you're dead-set
in the anti-static-builds camp (as you seem to be), we aren't going to get
anywhere with this line of discussion.  I'll respond to a few specifics,
though, just because I'm in that kind of mood at the moment and you never
know, it might help somebody somehow.  Besides, I see that enough (two)
others have joined in while I was busy typing this reply that it's a party
now.

> But if you go look through bug reports there are already one or two which
> says this will never be supported.

You don't see me agreeing with them, though.  Seems to be just a few people
saying that.  Also note that I'm not saying static builds should be easy,
only that they should be possible.  And I'm not talking about certain
library features not working in a static build, in which case application
developers could probably work around the specific problems.  I'm only
saying that the language itself, as compiled by gcj, should support static
builds.  So, for example, try/catch ought to work in a static build, and a
simple "hello world" application should run.  So far, so good, on that
front, as long as I use --enable-sjlj-exceptions.  With previous versions, I
didn't need to do that.

> Usually for small embedded systems yes.  But if you are using GCJ and X11,
> I am going to assume you are not building one of those.

Small is relative.   Relative to the flash memory in the system it goes in,
my binary is small but gcj's libraries are huge.  It's also a deployment
issue though, allowing a single file to be uploaded to the box rather than
making sure a whole lot of stuff matches and having to clean up disused
libraries.  It basically means that I only need an installer, not an
uninstaller, for each new release.  I realize those things can be done with
a package of libraries (delete the whole directory to uninstall, for
example), but it's easier with a single executable.

> If you take
> a look at the file sizes you will notice that you are duplicating a lot
> of symbols and maybe you should rethink using shared libraries.

Hmmm.... libgcj.so.6.0.0 all by its self is 63 megs, and my entire static
binary (as with many embedded systems, there's only one binary) is less than
10 megs.  So I don't agree with that one.  By static linking, you leave out
a whole lot of classes, so in a typical app the static build is a whole lot
smaller than the dynamic one plus the libraries.  As compilers become more
mature, they get better, not worse, at optimizing unused stuff out of static
builds, so using that capability ought to be even better as time goes on.

> > D) Because one of the main reasons I selected GCJ was for that
capability
> For static linking?  HUH?  Why not use C, I don't see the issue.

Because C's not Java -- we re-use code around here.  Static linking was by
no means the only reason for choosing gcj, but without it I probably would
have gone with something else, maybe even a different language (C++, I
guess).

> >   (Quote:  "We view Java as simply another programming language and
> > implement it the way we implement other compiled languages.")
> It does not talk about static linking at all.

Then you and I are reading the quote differently.  Such is life.

> Also I mentioned above even
> glibc is making the depencies on dynamic linking.

Sure, but I'm a selfish guy.  My applications don't seem to be using any of
those features of glibc, and that's good enough for me.  The specific
features are apparently not core language features, or my programs wouldn't
have been working all this time.

> Actually they never worked really.  Go look back in the archives and you
will

Not true.  My app works fine.  Static build, using "gcj (GCC) 4.0.2 20050707
(prerelease)"