some issues with BuildSystem and LANG

[Satish Balay]

On Wed, 29 Apr 2009, Lisandro Dalcin wrote:

> Sorry, I have very little knowledge about locales, but...
> 
> 1) The only thing that probably work in all cases is LANG=C

>From what I know - the variable/values are: "LANG=en_US, LC=C, LC_ALL=C"
> 
> 2) I'm not sure if a os.setenv will make child processes to inherit
> the LANG setting in all the cases.

My original code change was incorrect. Pushing the correct change now.
[Matt - is there a better place in BuildSystem where this should go?]

I can see gcc messages changing language in my configure.log. You can
verify if it fixes the original issue.

Satish


> 
> On Wed, Apr 29, 2009 at 2:58 PM, Satish Balay <balay at mcs.anl.gov> wrote:
> > I guess somewhere in configure we should do:
> >
> > os.setenv('LANG','en_US')
> > or use 'en_US.utf8'
> >
> > The issues I don't know how to adress are:
> >
> > - will this break some OS  where this is unknown..
> > - Do we have to use the same LANG in makefiles - during buildtime?
> >
> > I guss - I can do the following to petsc-dev - and see if someone
> > complains..
> >
> > diff -r f7644879c9e5 config/configure.py
> > --- a/config/configure.py       Tue Apr 28 16:06:47 2009 -0500
> > +++ b/config/configure.py       Wed Apr 29 12:56:45 2009 -0500
> > @@ -286,5 +286,6 @@
> >   move_configure_log(framework)
> >
> >  if __name__ == '__main__':
> > +  os.setenv('LANG','en_US.utf8')
> >   petsc_configure([])
> >
> >
> > Satish
> >
> >
> > On Wed, 29 Apr 2009, Barry Smith wrote:
> >
> >>
> >>   I asked this before and never got a good answer.
> >>
> >>    How come config/configure.py doesn't somehow turn on the LANG to english
> >> itself!!!!!
> >> When config/configure.py runs things it runs them in new subshells, there
> >> should be some
> >> way to make those new subshells have the LANG english.
> >>
> >>    It is not reasonable that we'll handle messages in all languages!
> >>
> >>   Barry
> >>
> >> On Apr 29, 2009, at 10:31 AM, Matthew Knepley wrote:
> >>
> >> > On Wed, Apr 29, 2009 at 10:19 AM, Lisandro Dalcin <dalcinl at gmail.com> wrote:
> >> > Today I had a hard time helping a student trying to build PETSc on a
> >> > Ubuntu box he has at home... For some unknow reason, the configure
> >> > step let pass '-PIC' as a valid GCC flag... The relevant parts of the
> >> > configure log are shown below... (the <...> represent uninteresting
> >> > output)
> >> >
> >> > TEST checkPIC from
> >> > config.setCompilers(/home/nisi/petsc-3.0.0-p5/config/BuildSystem/config/setCompilers.py:807)
> >> > TESTING: checkPIC from
> >> > config.setCompilers(config/BuildSystem/config/setCompilers.py:807)
> >> > Determine the PIC option for each compiler
> >> >      - There needs to be a test that checks that the functionality
> >> > is actually working
> >> >       Pushing language C
> >> >     Trying C compiler flag -PIC
> >> > <.....>
> >> > sh: gcc  -o conftest  -PIC    conftest.o
> >> > Executing: gcc  -o conftest  -PIC    conftest.o
> >> > sh:
> >> > Possible ERROR while running linker: gcc: no se reconoce la opción '-PIC'
> >> > output: error message = {gcc: no se reconoce la opción '-PIC'
> >> > }
> >> > <.....>
> >> >       Valid C linker flag -PIC
> >> >     Adding C compiler flag -PIC
> >> > sh: gcc -c -o conftest.o  -PIC   conftest.c
> >> > Executing: gcc -c -o conftest.o  -PIC   conftest.c
> >> > sh:
> >> > Possible ERROR while running compiler: error message = {gcc: no se
> >> > reconoce la opción '-PIC'
> >> > }
> >> > <.....>
> >> > Added C compiler flag -PIC
> >> >
> >> > What's going on?? My guess was that BuildSystem is not prepared for
> >> > Spanish words :-)
> >> >
> >> > What a good guess this is exactly right. I will patch BuildSystem-dev now.
> >> >
> >> >
> >> > I asked the guy to start the whole process again, but this time begin doing:
> >> >
> >> > $ export LANG=en_US.UTF-8
> >> >
> >> > and now things worked out of the box...
> >> >
> >> > Is this  issue documented somewhere? There is anything we can do to
> >> > improve this? What is the minimal Python version BuildSystem should
> >> > require? Scanning stdout/stderr for guessing failures is really
> >> > fragile...
> >> >
> >> > You would think, but its not nearly as fragile as trusting a stupid
> >> > compiler. Compiler
> >> > people are the most stubborn jackasses in computing. They refuse to consider
> >> > anything
> >> > but
> >> >
> >> >  1) command line input
> >> >
> >> >  2) screen message output
> >> >
> >> > Why bother with APIs when you can have text? No compiler that I know of
> >> > produces
> >> > error codes for warnings, including gcc, so we have no way other than
> >> > scanning the
> >> > output to determine what options are valid (certainly not an interface call
> >> > for this).
> >> > After working on this stuff for a few years, I really really hate people who
> >> > build compilers.
> >> > Some more than others, but all of them are bad.
> >> >
> >> > Thanks for letting me have my rant time this morning,
> >> >
> >> >   Matt
> >> >
> >> >
> >> > --
> >> > Lisandro Dalcín
> >> > ---------------
> >> > Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
> >> > Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
> >> > Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
> >> > PTLC - Güemes 3450, (3000) Santa Fe, Argentina
> >> > Tel/Fax: +54-(0)342-451.1594
> >> >
> >> >
> >> >
> >> > --
> >> > What most experimenters take for granted before they begin their experiments
> >> > is infinitely more interesting than any results to which their experiments
> >> > lead.
> >> > -- Norbert Wiener
> >>
> >
> 
> 
> 
>