Re: KAI C++ Linux patch

[Will M. <bir...@ya...>]

Ok, I see your point about what the intended usage for
ICU is. It seems that you envision that each
application that uses ICU will be very tightly bound
to it, and that the value of dynamic linking should
only be considered within the scope of the
application. That's reasonable and I'll happily use
ICU in that way and just statically link to it.
However, if that's all true, then there really is no
value in bundling ICU with a Linux distribution, since
it potentially could only serve such a tiny fragment
of users, namely those users that have been left
flapping in the wind by their application vendors with
regard to ICU configuration and compiler choice.

Anyway, I spoke too soon about configure choking. I
had to manually set the host type to
"i686-pc-linux-gnu" and it generated make files for
me. Here are the only problems that remain after that
configure run:

1) The mh-linux file is included and it contains
gcc-specific flags and settings. We should make
configure include mh-kcc instead.
2) The CFLAGS and CXXFLAGS variables in all the make
files are wrong. They should be set to the values that
I used in my original mh-kcc file.

Thanks very much for working with me to get KCC
working with the ICU build system!

Will Mason

--- George Rhoten <gr...@us...> wrote:
> ICU is meant to be built with various compilers.  
> For instance, xlC, g++ 
> and Visual Age C++ on AIX, or Sun WorkShop Pro CC
> and g++ on Solaris, or 
> CC and aCC on HP/UX.  Since ICU can be configured
> differently from other 
> people, you are never guaranteed that it's built the
> same.  A person could 
> disable threads in ICU in order to make their
> application run faster , and 
> that would be bad for almost everyone else.  These
> are a few shared 
> library problems that many people complain about on
> almost every platform.
> 
> Shared libraries are useful for those people that
> have many homogenous 
> programs using ICU at once, like many copies of the
> XML4C parser running 
> at once.  For stability in your code, you should
> statically link to ICU or 
> put a copy of the ICU shared libraries into your
> program directory and use 
> those.  Maybe someone else on the list has a
> different opinion.
> 
> Could you show me where configure is failing when
> you are using the KAI 
> compiler?  Does removing config.cache help?
> 
> George Rhoten
> IBM Globalization Center of Competency/ICU 
> Cupertino, CA, USA
> 
> To:     George Rhoten/Cupertino/IBM@IBMUS
> cc: 
> Subject:        Re: KAI C++ Linux patch
> 
> 
> 
> George,
> 
> > * ICU never appends the compiler name to a library
> > name.  This is due to
> > several portability concerns.  This change will
> not
> > go into ICU.
> 
> This makes deployment more difficult and it seems to
> be at odds with what appears to be your desire to
> have
> ICU bundled with Linux distributions. In an ideal
> world all Linux distributions would come with ICU.
> That means that when I ship an app built with KCC
> I've
> got to pre-empt the loading of the ICU libraries
> with
> the ones that I will be forced to bundle because
> they'll all have the same name even though they're
> not
> compatible. Effectively I can *never* trust that a
> pre-installed set of ICU libraries will be usable.
> Therefore, I ALWAYS have to ship and load my own.
> Therefore, there is literally no value in
> dynamically
> linking them at all; I should simply always
> statically
> link ICU and be done with the headache. Therefore,
> there is no point in the ICU build process creating
> shared objects, because they are demonstrably not
> shareable. Do you agree?
> 
> > * The Makefiles are automatically generated from
> the
> > various Makefile.in
> > and mh-* files when you use configure.  So I found
> > it extrememly difficult
> > to find the real changes.  Could you give me a
> patch
> > with changes to just
> > Makefile.in and mh-* files?
> 
> I've reviewed my changes and you can leave all of
> the
> Makefile.in files alone. They are all fine. All you
> have to do is coax the CFLAGS and CXXFLAGS values
> that
> are presently in the mh-kcc file into the Makefile
> files when they are generated. Then you can remove
> them (and the CC and CXX definitions) from mh-kcc.
> At
> that point as long as you include mh-kcc instead of
> mh-linux you should be fine.
> 
> I can't really test it because configure chokes when
> I
> set CC and CXX to KCC. So I have no way of causing
> good make files to be generated because I don't know
> what to do to convince configure that KCC is really
> Ok.
> 
> > * I'm intersted in what failed when you increased
> > the optimization level.
> > Maybe you could tell me?
> 
> Sure. The symptom that I observed was massive
> failure
> of your unit tests. I can look further to try and
> learn what exactly is going on. I've found in my
> experience with KCC in the past that when I get a
> failure after turning on optimizations, it's almost
> always a bug in my code. I'm not familiar enough
> with
> the ICU code to be able to really pin down the
> failures. I will experiment some more and let you
> know
> if I come up with anything.
> 
> Please let me know if you need more information,
> Will Mason
> 
> 
> =====
> "Academic debates are heated because there is so
> little at stake." 
> --Anonymous
> 
> __________________________________________________
> Terrorist Attacks on U.S. - How can you help?
> Donate cash, emergency relief information
>
http://dailynews.yahoo.com/fc/US/Emergency_Information/
> 
> 


=====
"Academic debates are heated because there is so little at stake." --Anonymous

__________________________________________________
Terrorist Attacks on U.S. - How can you help?
Donate cash, emergency relief information
http://dailynews.yahoo.com/fc/US/Emergency_Information/