Re: KAI C++ Linux patch

[George R. <gr...@us...>]

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/