Created an attachment (id=679) [details]
patch against i18n/source/ltconfig file

This patch has not been tested yet. 
For testing it needs proper build of icu4c module beforehand.

Created an attachment (id=680) [details]
patch against icu4c/pkgdata/pkg_data_src.gpt.in file

This is the patch which seem to work for me. I have not tested it together with
i18n patch yet.

Created an attachment (id=681) [details]
patch against icu4c/pkgdata/pkg_data_src.gpt.in file

This is a modified and simplified version of the patch against icu4c (patch
680). It was positively tested with icu4c and i18n (with patch 679).

Build of icu4c and i18n is a hack:
- set Globus flavor to vendorcc32 (on HP-UX/IA-64)
- modify gpt-3.2-autotools2004 to contain globus_core-4.28.tar.gz (or newer)
- build globus_core (make globus_core)
- inspect $GLOBUS_LOCATION/etc/globus_core/flavor_vendorcc32.gpt file
- if CXXFLAGS contains "-Ae" flag, remove it
- if LDFLAGS cotains "-Ae" flag, remove it
- continue build ('make globus_icu4c' or 'make globus_i18n')

Tech Coordinator,

We would like to commit this patch to CVS (globus_4_0_branch and HEAD). We would
do some simple testing after the commit, like testing on HPUX and one Linux
platform.

Please let us know if you have any concerns about the patch.

Thanks!

I don't think that I am technically the technology coordinator for i18n (I'm
not
sure that there is one, specifically--I think it is considered to be a subset
of
common).  I am, however, the person best versed in our i18n implementation, so
I'll comment.

The patch against icu4c/pkgdata/pkg_data_src.gpt.in looks fine.
The patch against i18n/source/ltconfig looks fine, but brings up the question
of
why the globus_i18n package has its own ltconfig file to begin with--this is
probably a mistake, and I would rather fix it right than patch a mistake.

Thus, I will look into why the globus_i18n package is different from all other
globus packages.  My suspicion is that there is no reason for globus_i18n to
have its own ltconfig, and that, once fixed, there shouldn't need to be any
special patches to the globus_i18n package for hp-ux (as globus_core is
supposed
to handle all of that for us).


My only concern is with the comments from Chris Wilk about editing the
$GLOBUS_LOCATION/etc/globus_core/flavor_vendorcc32.gpt file.  Is this something
that will be fixed by a patch to core?

globus_core has been fixed in both globus_4_0_branch and HEAD.

Looking at the globus_i18n package, I see that it does, in fact have a
ltconfig.

However, in a normal build, I do not believe it is ever used for anything.
The libtool-<flavor> from core is used.  In fact, the same ltmain.sh is
generated in the build process whether ltconfig is present or not

So what is the patch to ltconfig supposed to accomplish?

Patch against i18n/source/ltconfig file originates from attachment 595 [details] (bug
#3234). 
I am not sure if it is really needed. I only remember I used it during tests of
i18n as a standalone modules (not as a part of GT4).

pkg_data_src.gpt.in fix commited to globus_4_0_branch and head.

I'm not going to commit the ltconfig part until somebody reopens this bug, and
shows why it is needed.