From: Danny S. <dan...@cl...> - 2003-06-27 03:09:53
|
Hi, Mohan and Ranjit Getting back to 3.3 and (3.4 for that matter) issues. how do you guys want to handle libiconv.a dependency with libgcj.a? My builds and tests of java have been with out-ot-box builds of libiconv-1.9.1( with configure --disable-shared and the static libiconv.a installed in usual <prefix>/lib place. ) AFAICT presence of libiconv only affects jc1.exe and libgcj (the latter through libjava/gnu/gcj/convert/natIconv.c) Should distributed binaries of jc1.exe and libgcj.a depend on distributed dll build of libiconv or static library? If we depend on libiconv-2.dll, then we impose responsibilty on users to distribute sources of libiconv with any binary that requires redistribution of libiconv-2.dl with the binary. If we depend on static libiconv.a then we haven't imposed any real licensing restrictions on user-redistribution of binaries, as per libiconv LGPL in COPYING.LIB. But, at the expense of significnat increase in executable size. Maybe I'm getting too hung up on licensing. I 'feel' we should depend on the dll, but I don't trust the average mingw user to appreciate and honour the value of GPL. Or should we just build jc1 and libgcj with libiconv out-of-sight for now so that we don't have to worry about the issue? But we do get bug reports about java exceptions from natIconv.cc GCC 3.3.1 is due for official release about mid July. Danny |
From: Mohan E. <gnu...@th...> - 2003-06-27 06:02:35
|
Hi Danny, Ranjit is more knowledgeable about this than I am, so I defer this analysis to him. >Should distributed binaries of jc1.exe and libgcj.a depend on >distributed dll build of libiconv or static library? >Maybe I'm getting too hung up on licensing. I 'feel' we should depend >on the dll, but I don't trust the average mingw user to appreciate and >honour the value of GPL. I don't think you're getting hung up on this. I think it's nice to live by the letter of the law in these cases and I am on the same page as you are philosophically. >Or should we just build jc1 and libgcj with libiconv out-of-sight for >now so that we don't have to worry about the issue? But we do get bug >reports about java exceptions from natIconv.cc Both Ranjit's and my builds have been with --disable-nls and as far as I know, true NLS support is broken in many places in libjava because ANSI OS system calls are used instead of their Unicode equivalents. So getting true NLS support to work in libjava would require more work than just turning on libiconv. So I don't see a problem with not building with libiconv for now. Again, however, I may be misstating things; Ranjit knows much more about this. -- Mohan |
From: Earnie B. <ear...@ya...> - 2003-06-27 11:35:11
|
Danny Smith wrote: > Hi, Mohan and Ranjit > Getting back to 3.3 and (3.4 for that matter) issues. how do you guys > want to handle libiconv.a dependency with libgcj.a? > > My builds and tests of java have been with out-ot-box builds of > libiconv-1.9.1( with configure --disable-shared and the static > libiconv.a installed in usual <prefix>/lib place. ) AFAICT presence of > libiconv only affects jc1.exe and libgcj (the latter through > libjava/gnu/gcj/convert/natIconv.c) > > Should distributed binaries of jc1.exe and libgcj.a depend on > distributed dll build of libiconv or static library? > > If we depend on libiconv-2.dll, then we impose responsibilty on users to > distribute sources of libiconv with any binary that requires > redistribution of libiconv-2.dl with the binary. If we depend on static > libiconv.a then we haven't imposed any real licensing restrictions on > user-redistribution of binaries, as per libiconv LGPL in COPYING.LIB. > But, at the expense of significnat increase in executable size. > But would simply building a program cause libiconv-2.dll dependency? Wouldn't I require needing to use the library? Perhaps a dll for for GCC tools and friends but only static library is distributed so that the import library isn't used? > Maybe I'm getting too hung up on licensing. I 'feel' we should depend > on the dll, but I don't trust the average mingw user to appreciate and > honour the value of GPL. > Licensing is always a hang up. :) Yes, you should be concerned. We already present the same problem or worse problem with profiling. > Or should we just build jc1 and libgcj with libiconv out-of-sight for > now so that we don't have to worry about the issue? But we do get bug > reports about java exceptions from natIconv.cc > Maybe. > GCC 3.3.1 is due for official release about mid July. > Great. Earnie. |
From: Danny S. <dan...@cl...> - 2003-06-27 21:01:23
|
----- Original Message ----- From: "Earnie Boyd" <ear...@ya...> To: <min...@li...> Sent: Friday, 27 June 2003 12:16 Subject: Re: [MinGW-dvlpr] [java] libgcj and dependency on libiconv > Danny Smith wrote: > > Hi, Mohan and Ranjit > > Getting back to 3.3 and (3.4 for that matter) issues. how do you guys > > want to handle libiconv.a dependency with libgcj.a? > > > > My builds and tests of java have been with out-ot-box builds of > > libiconv-1.9.1( with configure --disable-shared and the static > > libiconv.a installed in usual <prefix>/lib place. ) AFAICT presence of > > libiconv only affects jc1.exe and libgcj (the latter through > > libjava/gnu/gcj/convert/natIconv.c) > > > > Should distributed binaries of jc1.exe and libgcj.a depend on > > distributed dll build of libiconv or static library? > > > > If we depend on libiconv-2.dll, then we impose responsibilty on users to > > distribute sources of libiconv with any binary that requires > > redistribution of libiconv-2.dl with the binary. If we depend on static > > libiconv.a then we haven't imposed any real licensing restrictions on > > user-redistribution of binaries, as per libiconv LGPL in COPYING.LIB. > > But, at the expense of significnat increase in executable size. > > > > But would simply building a program cause libiconv-2.dll dependency? > Wouldn't I require needing to use the library? Dependency would only result (now) for a program that used package gnu.gcj.convert for character set conversions Perhaps a dll for for > GCC tools and friends but only static library is distributed so that the > import library isn't used? > jc1.exe uses the iconv functions if found. No other tools yet (unless we want to start supporting NLS in gcc messages.) So a static lib isn't a problem now for gcc tools. > > Maybe I'm getting too hung up on licensing. I 'feel' we should depend > > on the dll, but I don't trust the average mingw user to appreciate and > > honour the value of GPL. > > > > Licensing is always a hang up. :) Yes, you should be concerned. We > already present the same problem or worse problem with profiling. Hmm, I never thought about people wanting to distribute profiling-enabled binaries > > > Or should we just build jc1 and libgcj with libiconv out-of-sight for > > now so that we don't have to worry about the issue? But we do get bug > > reports about java exceptions from natIconv.cc > > > > Maybe. > > > GCC 3.3.1 is due for official release about mid July. > > > > Great. > > Earnie. > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: INetU > Attention Web Developers & Consultants: Become An INetU Hosting Partner. > Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! > INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php > _______________________________________________ > MinGW-dvlpr mailing list > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr |