Menu
▾
▴
mingw-dvlpr
|
From: Mohan E. <gnu...@th...> - 2003-11-21 08:09:16
|
Hi People, I thought I'd give you a heads-up on a thread on the gcc java mailing list: - http://gcc.gnu.org/ml/java/2003-11/threads.html#00160 - http://gcc.gnu.org/ml/java/2003-11/threads.html#00247 For the impatient, here are the salient posts from these: - http://gcc.gnu.org/ml/java/2003-11/msg00231.html - http://gcc.gnu.org/ml/java/2003-11/msg00250.html In a nutshell, I plan to submit a patch: http://www.thisiscool.com/temp/unicode.diff.tar.bz2 (this is a prior version, but is essentially the same) ...which would require MS' unicows.dll for any MinGW gcj-produced executable running on Win9X. unicows.dll would not be required for WinNT / 2K / XP. In addition, developers would need to add libunicows.a to mingw32/lib: http://libunicows.sourceforge.net By requiring this, I am able to refactor (almost) the entire Win32 libjava layer to use UNICODE natively. Since Java uses UNICODE, this was more aesthetically pleasing to me than doing UNICODE <-> ANSI, then ANSI <-> UNICODE via the Windows system calls on NT and above. This is a somewhat controversial decision because: - You can achieve the same result using WideCharToMultiByte / MultiByteToWideChar, thereby going the UNICODE <-> ANSI <-> UNICODE route, but supporting Win9X without unicows.dll - My patch is coded for the possibility of a non-UNICODE build, but I don't follow through on this and am lukewarm to the idea because it would be another build configuration to test and maintain. I am disqualifying myself from making the final decision about this and will instead ask another gcj person to review this. I am interested in your feedback concerning this, though. -- Mohan http://www.thisiscool.com/ http://www.animalsong.org/ |
|
From: Danny S. <dan...@cl...> - 2003-11-21 09:48:15
|
Hello Mohan > In a nutshell, I plan to submit a patch: > > http://www.thisiscool.com/temp/unicode.diff.tar.bz2 > (this is a prior version, but is essentially the same) > > ...which would require MS' unicows.dll for any MinGW gcj-produced > executable running on Win9X. unicows.dll would not be required > for WinNT / 2K / XP. In addition, developers would need to add > libunicows.a to mingw32/lib: > \ Are you wanting libunicows as a system lib (ie, built into specs somehow for java?) or as something that user has to specify? > By requiring this, I am able to refactor (almost) the entire Win32 > libjava layer to use UNICODE natively. Since Java uses UNICODE, > this was more aesthetically pleasing to me than doing UNICODE <-> ANSI, > then ANSI <-> UNICODE via the Windows system calls on NT and above. > > This is a somewhat controversial decision because: > > - You can achieve the same result using WideCharToMultiByte / MultiByteToWideChar, > thereby going the UNICODE <-> ANSI <-> UNICODE route, but supporting > Win9X without unicows.dll > > - My patch is coded for the possibility of a non-UNICODE build, > but I don't follow through on this and am lukewarm to the idea because > it would be another build configuration to test and maintain. libstdc++ locale class also suffers from lack of nls support (and hence no wchar ios) on windows. Is there some way we could share the locale support between c++ and java. I was thinking of of an nl_langinfo like wrapper for the windows nls api. Maybe this is overkill for libjava requiremnents but it would certainly help libstdc++. (Just thinkng out loud -- my early attempts at this used the UNICODE-ANSI-UNICODE path a lot, and was, uh, messy) > I am disqualifying myself from making the final decision about this > and will instead ask another gcj person to review this. I am interested > in your feedback concerning this, though. You've done a great job with this. Thanks for your efforts. Danny |
|
From: Mohan E. <gnu...@th...> - 2003-11-21 10:23:37
|
Hi Danny, >Are you wanting libunicows as a system lib (ie, built into specs >somehow for java?) or as something that user has to specify? As a system lib only for Java. I've already got this working. >libstdc++ locale class also suffers from lack of nls support (and hence >no wchar ios) on windows. Is there some way we could share the locale >support between c++ and java. I was thinking of of an nl_langinfo like >wrapper for the windows nls api. Maybe this is overkill for libjava >requiremnents but it would certainly help libstdc++. >(Just thinkng out loud -- my early attempts at this used the >UNICODE-ANSI-UNICODE path a lot, and was, uh, messy) The beauty of this is that I don't have to do anything at all. libgcj speaks UNICODE natively to the OS and I just sit back and watch. Other locale stuff seems to be handled in the gnu.java.locale.* classes, but I'm not too knowledgeable about this. >You've done a great job with this. Thanks for your efforts. Thanks. I'm not out of the woods yet with testing.... -- Mohan http://www.thisiscool.com/ http://www.animalsong.org/ |
|
From: Mohan E. <gnu...@th...> - 2003-11-21 11:27:35
|
Hi Danny, >>libstdc++ locale class also suffers from lack of nls support (and hence >>no wchar ios) on windows. Is there some way we could share the locale >>support between c++ and java. I was thinking of of an nl_langinfo like >>wrapper for the windows nls api. Maybe this is overkill for libjava >>requiremnents but it would certainly help libstdc++. >>(Just thinkng out loud -- my early attempts at this used the >>UNICODE-ANSI-UNICODE path a lot, and was, uh, messy) > >The beauty of this is that I don't have to do anything at all. libgcj >speaks UNICODE natively to the OS and I just sit back and watch. Other >locale stuff seems to be handled in the gnu.java.locale.* classes, but >I'm not too knowledgeable about this. I actually spoke too soon. There is character <-> byte conversion stuff occurring in the gnu.gcj.convert.* classes - support for this is incomplete under MinGW because we currently don't use libiconv. This is a somewhat different issue, though, than the one I'm addressing with the patch. -- Mohan http://www.thisiscool.com/ http://www.animalsong.org/ |
|
From: Earnie B. <ea...@us...> - 2003-11-22 00:13:30
|
Mohan Embar wrote: > > I actually spoke too soon. There is character <-> byte conversion > stuff occurring in the gnu.gcj.convert.* classes - support for this > is incomplete under MinGW because we currently don't use libiconv. > This is a somewhat different issue, though, than the one I'm addressing > with the patch. > License of library must be considered of course. I forget what libiconv has in the way of license and exception clauses it may have. The UNICOWS library is MIT. The default library used must be static and not a shared dll as well. I just don't want the complaints on the user list. Earnie -- http://www.mingw.org Powered by SourceForge <http://sourceforge.net/projects/mingw> |
|
From: Mohan E. <gnu...@th...> - 2003-11-22 01:17:17
|
Hi Earnie, >License of library must be considered of course. I forget what libiconv >has in the way of license and exception clauses it may have. The >UNICOWS library is MIT. The default library used must be static and not >a shared dll as well. I just don't want the complaints on the user list. The UNICOWS solution would consist of a free, open-source libunicows.a which is part of the system libraries and obtainable from here: http://libunicows.sf.net ...as well as a non-free Microsoft unicows.dll which would need to be downloaded from MS' site and redistributed (for Win9X only) according to these terms: * Distribution Terms. You may reproduce and distribute an unlimited number of copies of the Sample Code and/or Redistributable Code (collectively "Redistributable Components") as described above in object code form, provided that (a) you distribute the Redistributable Components only in conjunction with and as a part of your Application solely for use with a Microsoft Operating System Product; (b) your Application adds significant and primary functionality to the Redistributable Components; (c) you distribute your Application containing the Redistributable Components pursuant to an End-User License Agreement (which may be "break-the-seal", "click-wrap" or signed), with terms no less protective than those contained herein; (d) you do not permit further redistribution of the Redistributable Components by your end-user customers; (e) you do not use Microsoft's name, logo, or trademarks to market your Application; (f) you include a valid copyright notice on your Application; and (g) you agree to indemnify, hold harmless, and defend Microsoft from and against any claims or lawsuits, including attorneys' fees, that arise or result from the use or distribution of your Application. Contact Microsoft for the applicable licensing terms for all other uses and/or distribution of the Redistributable Components. These licensing terms provoked the dissatisfaction one poster: http://gcc.gnu.org/ml/java/2003-11/msg00256.html ...but I think it would make the libjava layer cleaner. Does this answer your question? -- Mohan http://www.thisiscool.com/ http://www.animalsong.org/ |
|
From: Earnie B. <ea...@us...> - 2003-11-22 13:19:21
|
Mohan Embar wrote: > > Does this answer your question? > No. My headache is about the end result, i.e. my program. If it is forced to be GPL or any other license not of my own choosing then that is the problem. Headache number two is the outcry of the user base about needing to disbribute shared libraries that the build process forced them to use. Therefore, the use of static and not dynamic for standard libraries is a must as much as possible. I would love to see a --dynstdlib switch that would use a dynamic libstdc++ or any other dynamic standard library. Earnie -- http://www.mingw.org Powered by SourceForge <http://sourceforge.net/projects/mingw> |
|
From: Mohan E. <gnu...@th...> - 2003-11-22 15:04:49
|
Hi Earnie, >No. My headache is about the end result, i.e. my program. If it is >forced to be GPL or any other license not of my own choosing then that >is the problem. So are you against the UNICOWS solution in that it seems to require the end user to adopt some sort of license for Win9X gcj-compiled executables? If so, what alternative is the most palatable to you (for libjava)?: - pure ANSI without accented characters (which is what users are unhappy about now) - the UNICODE <-> ANSI <-> UNICODE which is inefficient for NT and greater - a configure-time switch allowing to choose among, say, ansi, unicows and unicode (i.e. NT targets with no Win9X support) The third option would be the most flexible, but it would entail a greater number of compiler builds to maintain. >Headache number two is the outcry of the user base about needing to >disbribute shared libraries that the build process forced them to use. >Therefore, the use of static and not dynamic for standard libraries is a >must as much as possible. I would love to see a --dynstdlib switch that >would use a dynamic libstdc++ or any other dynamic standard library. So are you against a libiconv.dll? As for --dynstdlib, the way that Linux does it is via --enable-shared, but then the entire compiler is built that way, as far as I understand. This would again require two builds of the compiler to maintain.... -- Mohan http://www.thisiscool.com/ http://www.animalsong.org/ |
|
From: Steve D. P. <mai...@st...> - 2003-11-22 18:34:40
|
Mohan wasn't exactly talking to me, and I haven't exactly been
actively participating on this list in some time, but I thought I would
speak up with my opinion in this case... as GCJ has come to encompass
99% of my MinGW useage.
> So are you against the UNICOWS solution in that it seems to require
> the end user to adopt some sort of license for Win9X gcj-compiled
> executables?
Yes, I would be 100%-passionately-near-violently opposed to it. I
still skim through the dev list on a regular basis, and some of the
things I've been hearing lately have alarmed me. If I've heard
correctly, I've heard at least one developer advocate for the GPL and
voice his welcome to the notion of introducing dependencies and
licensing restrictions. I've even seen a mention or two from someone
else (hopefully joking, I never know with Paul) about a POSIX layer down
the road. What the hell is going on?!?
MinGW has, and has always had, one and only one primary reason for
existence. That reason has been freedom from the licensing restritions
of Cygwin, period. Sure, "bloat" is a concern for many... but NOBODY
would have spent the past several years banging their heads against
their desks, trying to force code and makefiles designed for Cygwin to
work with MinGW, if they main concern was just to avoid having too much
of their hard drive taken up. Hell, most of my C++ education came from
trying to hack designed-for-Cygwin code to be compiled by MinGW... and I
did it all out of stubborn refusal to allow any compiler to dictate to
me the licensing terms of my end-products.
I like various open-source licenses, particularly the GPL. In fact,
every single line of code that I've ever publically release has been
licensed with the GPL. However, my original works have always been
licensed as such because of my choice, never by force. If the MinGW
team suddenly decides to deviate from this CORE FOUNDING PHILOSOPHY
after all this time, then what on earth will be the point of MinGW
anymore? I could just go back to Cygwin, which always has and always
will be a step ahead in development anyway.
The notion of introducing licensing restrictions into the MinGW
project is simply insane, and flies in the face of the past several
years of hard-earned reputation and goodwill. I beg of you to put this
discussion to bed and never repeat it again.
> If so, what alternative is the most palatable to you (for libjava)?:
>
> - pure ANSI without accented characters (which is what users are
> unhappy about now)
>- the UNICODE <-> ANSI <-> UNICODE which is inefficient for NT and
> greater
>- a configure-time switch allowing to choose among, say, ansi, unicows
> and unicode (i.e. NT targets with no Win9X support)
My first pick, at least until Win98/ME fade off to the sunset of
Win95 useage level, would be the second option. I know this may be a
contraversial thing to say, but lets be honest here... if the
"absolute-fastest-and-most-effecient-performance-humanly-possible" was
what we were after, we wouldn't be developing on the Win32 platform to
begin with. Everything about this platform is a trade-off between
performance and backwards-compatibility, with backwards-compatibility
almost always winning.
I would be just as happy, though, with the third option. I really
don't see what the huge overhead would be, just a simple flag passed
into the configure script or makefile when building the compiler from
source. It doesn't sound like a maintanence nightmare, and it's not as
if SourceForge is charging us for the extra download hosting space.
Hell, call the NT-target-only build "Enterprise MinGW" and get cutesy
with it if you want.
Just whatever you do, keep licensing restrictions out of it. I
simply cannot believe that this current movement is entirely driven by
userbase demand, rather than developers' personal agendas. There is no
way that the general MinGW community would rate
optimal-Unicode-performance as being a high enough priority to abandon
MinGW's core principal of licensing freedom.
Steve Perkins
|
|
From: Danny S. <dan...@cl...> - 2003-11-22 00:27:21
|
> Hi Danny, > > >>libstdc++ locale class also suffers from lack of nls support (and hence > >>no wchar ios) on windows. Is there some way we could share the locale > >>support between c++ and java. I was thinking of of an nl_langinfo like > >>wrapper for the windows nls api. Maybe this is overkill for libjava > >>requiremnents but it would certainly help libstdc++. > >>(Just thinkng out loud -- my early attempts at this used the > >>UNICODE-ANSI-UNICODE path a lot, and was, uh, messy) > > > >The beauty of this is that I don't have to do anything at all. libgcj > >speaks UNICODE natively to the OS and I just sit back and watch. Other > >locale stuff seems to be handled in the gnu.java.locale.* classes, but > >I'm not too knowledgeable about this. > > I actually spoke too soon. There is character <-> byte conversion > stuff occurring in the gnu.gcj.convert.* classes - support for this > is incomplete under MinGW because we currently don't use libiconv. > This is a somewhat different issue, though, than the one I'm addressing > with the patch. Sidetrack (philosophically) for a moment: Do you think that libiconv will, eventually, be part of the solution for libjava. I really would like to i18n-ize the gcc/binutils diagnostic messages, and for this libiconv/gerttext is needed. Both packages build out-of-box for mingw and there are even 'canonical' windows binaries distributed by the package mainatainers. Having these libs available (as part of mingw package) for linking into userland apps , however, means a serious education effor on GPL responsibilities But as you say, the unicows/Java issue is separate from this, and if you agree, I would support putting into gcc-3.4 mingw binaries, even if you have to wait for next release cycle to get into FSF sources Danny > > -- Mohan > http://www.thisiscool.com/ > http://www.animalsong.org/ > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > MinGW-dvlpr mailing list > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr |
|
From: Mohan E. <gnu...@th...> - 2003-11-22 01:28:28
|
Hi Danny, >Sidetrack (philosophically) for a moment: > >Do you think that libiconv will, eventually, be part of the solution for >libjava. I really would like to i18n-ize the gcc/binutils diagnostic >messages, and for this libiconv/gerttext is needed. Both packages >build out-of-box for mingw and there are even 'canonical' windows >binaries distributed by the package mainatainers. > >Having these libs available (as part of mingw package) for linking into >userland apps , however, means a serious education effor on GPL >responsibilities The presence of libiconv would enable NLS for libjava (I'd have to figure out how to do this) and I definitely think it would make the offering more attractive. However, like you mentioned in previous posts, there is an education issue. I'm not sure, but I think libjava only needs libiconv if the configure-time --enable-nls switch is specified, so maybe this would satisfy everyone. >But as you say, the unicows/Java issue is separate from this, and if you >agree, I would support putting into gcc-3.4 mingw binaries, even if you >have to wait for next release cycle to get into FSF sources I still think having all of libjava in native UNICODE would be cleaner. I've coded my patch so it would be pretty easy to add an extra libjava configure option to use the A functions and possibly do the UNICODE <-> ANSI <-> UNICODE thing with minimal extra code, thereby eliminating the need for UNICOWS if this switch were specified. However, I argued against this on the Java list because it would be an extra configuration to test and maintain when we could let MS do the work, albeit with the extra hassle for Win9X users to find unicows.dll on MS' website and adhere to their license. What do you think? -- Mohan http://www.thisiscool.com/ http://www.animalsong.org/ |
|
From: Danny S. <dan...@cl...> - 2003-11-22 04:00:22
|
> > I'm not sure, but I think libjava only needs libiconv if the configure-time > --enable-nls switch is specified, so maybe this would satisfy everyone. > Maybe its changed now, but it used to depend on libiconv if configure found libiconv header and librarry. I actually had to move my libiconv out of my lib search path while configuring to avoid the dependency. Danny |
|
From: Mohan E. <gnu...@th...> - 2003-11-22 09:25:28
|
Hi Danny, >Maybe its changed now, but it used to depend on libiconv if configure >found libiconv header and librarry. I actually had to move my libiconv >out of my lib search path while configuring to avoid the dependency. I looked into this more and it hasn't changed. --enable-nls merely controls whether compiler diagnostics can be output in another language. libjava convfigure uses AM_ICONV, which detects libiconv via compile and link tests. -- Mohan http://www.thisiscool.com/ http://www.animalsong.org/ |
Thanks for helping keep SourceForge clean.
X