This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
| Other format: | [Raw text] | |
You really shouldn't. :)
I'll take that comment seriously for a moment.
Well, the executable size isn't THAT ridiculous if you use "strip" on them, and there are various on-the-fly-compression tools (like UPX) that you can use to make this disadvantage a non-factor (granted, they aren't quite as effective on Linux as on Win32 for reasons that are way off-topic).It sounds like you are trying to deploy a single executable. That's not really a good justification for shared libraries. But it's also not the common case. If you are deploying many, perhaps dozens, of gcj-compiled executables you surely don't want each to be many megabytes in size.
Dear God I hope not! That would be beyond silly. It's quite probable that libgcj will become pervasive on major Linux distributions, but a "libgcj.dll" will NEVER be pervasive on the Win32 platform. This would be GUARANTEEING the need for a DLL installation, creating needless deployment complications. I'm really not looking forward to having to build by own custom GCJ from source just to get work done.That will eventually change, and win32 users will likely have a libgcj.dll unless they configure with --disable-shared.
There really, really should be a FAQ for this.Amen brother! :)
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |