From: Danny S. <dan...@cl...> - 2003-08-01 10:58:57
|
Hi, FSF GCC-3.3.1 is still in holding pattern whilst SCO politics are settled Otherwise gcc-3.3.1 is ready to go for mingw. Still wondering about what to do with libiconv and Java. I, libiconv vs no libiconv 1) Build Java without libiconv support. What are consequences? (Mohan,Ranjit) vs. 2) Build Java with libiconv support. A): request users get the libiconv from SF, built for mingw (Earnie package). B): redirect users to libiconv 1.9.1 'woe32' binaries released by Bruno H. These are built with/for MSVC and also work with mingw C) Update mingw libiconv binaries (GCC-built) to 1.9.1. (1.9.1 iconv builds out-of-box for mingw, IIRC, so no pain here). II. libiconv.dll vs static libiconv 1) Libiconv is data-heavy lib, about 900kb in size. Using static lib will bloat java compiler and libs and any .exes that need iconv. Build java binaries assuming libiconv.dll. vs. 2) Using dll means that libgcj is also dependent on libconv.dll, and that means licencing issues for gcj-built binaries. Build java binaries assuming static libiconv.a My gut says "use latest libiconv.dll" because 1) iconv is a fairly basic prereq if we intend to i18n-ize mingw within GCC framework. IMO, libiconv should be part of omnibus mingw package. 2) I like the GPL and would rather educate users on benefits rather than continually trying to avoid the issue. I think we should be putting GPL statements in resource (.rc) files in all executables like 'woe32' gettext/iconv does. 3) This only affect Java now, and, hey, Java developers are crazy anyway (real programmer use Algol). My 2 quid Danny |
From: Earnie B. <ear...@ya...> - 2003-08-01 11:43:21
|
Danny Smith wrote: > Hi, > > FSF GCC-3.3.1 is still in holding pattern whilst SCO politics are > settled > Otherwise gcc-3.3.1 is ready to go for mingw. > > Still wondering about what to do with libiconv and Java. > > I, libiconv vs no libiconv > 1) Build Java without libiconv support. What are consequences? > (Mohan,Ranjit) > > vs. > > 2) Build Java with libiconv support. > A): request users get the libiconv from SF, built for mingw > (Earnie package). > B): redirect users to libiconv 1.9.1 'woe32' binaries released by > Bruno H. > These are built with/for MSVC and also work with mingw > C) Update mingw libiconv binaries (GCC-built) to 1.9.1. > (1.9.1 iconv builds out-of-box for mingw, IIRC, so no pain > here). > I like option C. > II. libiconv.dll vs static libiconv > 1) Libiconv is data-heavy lib, about 900kb in size. Using static lib > will bloat java compiler and libs and any .exes that need iconv. > Build java binaries assuming libiconv.dll. > > vs. > > 2) Using dll means that libgcj is also dependent on libconv.dll, and > that > means licencing issues for gcj-built binaries. Build java binaries > assuming > static libiconv.a > What issues? Libiconv is LGPL. > > My gut says "use latest libiconv.dll" because > 1) iconv is a fairly basic prereq if we intend to i18n-ize mingw within > GCC framework. IMO, libiconv should be part of omnibus mingw package. Perhaps an emulation wrapper library that uses the ``woe32'' internationalization API would be in order? > 2) I like the GPL and would rather educate users on benefits rather than > continually > trying to avoid the issue. I think we should be putting GPL > statements in resource > (.rc) files in all executables like 'woe32' gettext/iconv does. There are just as many reasons not to like it (I'm not trying to start an argument, just trying to state a fact). Perhaps a new project would be best suited for that desire. After all, MinGW exists because of the need to eliminate the GPL from the output. > 3) This only affect Java now, and, hey, Java developers are crazy anyway > (real programmer use Algol). > No, it affects everything. Documentation, licensing statements, java objects linked with C objects, etc. But wait, libiconv is LGPL, so proprietary software can be created. > My 2 quid > My quid are already spent. ;) Earnie. |
From: Danny S. <dan...@cl...> - 2003-08-01 12:27:50
|
----- Original Message ----- From: "Earnie Boyd" <ear...@ya...>> > What issues? Libiconv is LGPL. > If user app depend on LPGL'd libiconv.dll. this may mean redistribition of the .dll with the app. In my understading, redistribution of the libiconv library requires provision of libiconv source. With static linkage, this is not necessary. Danny |
From: Earnie B. <ear...@ya...> - 2003-08-01 12:45:14
|
Danny Smith wrote: > ----- Original Message ----- > From: "Earnie Boyd" <ear...@ya...>> > >>What issues? Libiconv is LGPL. >> > > If user app depend on LPGL'd libiconv.dll. this may mean redistribition > of the .dll with the app. In my understading, redistribution of the > libiconv library requires provision of libiconv source. With static > linkage, this is not necessary. > Oh, yes, that issue. And if we use libiconv.dll shouldn't we also use libstdc++.dll? Yes, I remember the complaints on the list. However, we receive complaints due to the size of the .exe with the static link now. What we could do is create a distributable runtime bundle that packages the dll and the source for the dll. If you distribute the unmodified dll, simply distribute the runtime bundle. Earnie. |
From: Mohan E. <gnu...@th...> - 2003-08-01 14:00:50
|
Hi Danny, > 1) Build Java without libiconv support. What are consequences? >(Mohan,Ranjit) To my knowledge, all current MinGW gcj builds are done without libiconv support and people seem to accept this. Even if libiconv support were turned on, things would still be broken. For example, all of the native code uses the A functions instead of the W ones and so (for example) a NullPointerException is thrown anytime someone does a directory listing containing a file with accented characters. Here are a couple of threads on this: - http://gcc.gnu.org/ml/java-patches/2003-q2/msg00343.html - http://gcc.gnu.org/ml/java/2003-07/msg00373.html ("I have plans to post a patch that will make...") -- Mohan http://www.thisiscool.com/ http://www.animalsong.org/ |
From: Earnie B. <ear...@ya...> - 2003-08-01 14:10:42
|
Mohan Embar wrote: > Hi Danny, > > >> 1) Build Java without libiconv support. What are consequences? >>(Mohan,Ranjit) > > > To my knowledge, all current MinGW gcj builds are done without > libiconv support and people seem to accept this. Even if libiconv > support were turned on, things would still be broken. For example, > all of the native code uses the A functions instead of the W ones > and so (for example) a NullPointerException is thrown anytime > someone does a directory listing containing a file with accented > characters. > So, gcj needs also to have UNICODE defined while being built? Earnie. |
From: Mohan E. <gnu...@th...> - 2003-08-03 02:49:16
|
Hi Earnie, >So, gcj needs also to have UNICODE defined while being built? No. All unicode-related stuff seems to be done in the library code, not at the OS level. And like I said, this is broken in some places, like when interfacing the Win32 A file functions. -- Mohan http://www.thisiscool.com/ http://www.animalsong.org/ |
From: Paul G. <pga...@at...> - 2003-08-02 02:47:52
|
On 1 Aug 2003 at 10:10, Earnie Boyd wrote: > Mohan Embar wrote: > > Hi Danny, > > > > > >> 1) Build Java without libiconv support. What are consequences? > >>(Mohan,Ranjit) > > > > > > To my knowledge, all current MinGW gcj builds are done without > > libiconv support and people seem to accept this. Even if libiconv > > support were turned on, things would still be broken. For example, > > all of the native code uses the A functions instead of the W ones > > and so (for example) a NullPointerException is thrown anytime > > someone does a directory listing containing a file with accented > > characters. > > > > So, gcj needs also to have UNICODE defined while being built? I have a gut feeling that it does not require UNICODE to be defined. Paul G. |