Opened 3 years ago

Closed 2 years ago

Last modified 4 months ago

#8825 closed bug (fixed)

ghc can't determine gcc version on ru_RU locale

Reported by: slyfox Owned by:
Priority: normal Milestone: 7.8.4
Component: Compiler Version: 7.8.1-rc1
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s): D185
Wiki Page:

Description

Current ghc spits warnings time to time:

<no location info>:
    Warning: Couldn't figure out linker information!
             Make sure you're using GNU gcc, or clang

It's because my default locale is LANG=ru_RU.UTF-8 [1]

...
gcc версия 4.8.2 (Gentoo 4.8.2-r1 p1.4-ssptest, pie-0.5.9-ssptest)

versus LANG=C

...
gcc version 4.8.2 (Gentoo 4.8.2-r1 p1.4-ssptest, pie-0.5.9-ssptest)

[1]:

$ gcc -v
Используются внутренние спецификации.
COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.2/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.8.2/lto-wrapper
Целевая архитектура: x86_64-pc-linux-gnu
Параметры конфигурации: /subvolumes/var_tmp/portage/sys-devel/gcc-4.8.2-r1/work/gcc-4.8.2/configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.2 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.2 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.2/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.2/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/include/g++-v4 --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.8.2/python --enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.8.2-r1 p1.4-ssptest, pie-0.5.9-ssptest' --enable-libstdcxx-time --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64 --disable-altivec --disable-fixed-point --enable-targets=all --disable-libgcj --enable-libgomp --disable-libmudflap --disable-libssp --enable-lto --without-cloog
Модель многопоточности: posix
gcc версия 4.8.2 (Gentoo 4.8.2-r1 p1.4-ssptest, pie-0.5.9-ssptest)

[2]: While LANG=C output:

$ LANG=C gcc -v
Using built-in specs.
COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.2/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.8.2/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /subvolumes/var_tmp/portage/sys-devel/gcc-4.8.2-r1/work/gcc-4.8.2/configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.2 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.2 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.2/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.2/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/include/g++-v4 --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.8.2/python --enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.8.2-r1 p1.4-ssptest, pie-0.5.9-ssptest' --enable-libstdcxx-time --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64 --disable-altivec --disable-fixed-point --enable-targets=all --disable-libgcj --enable-libgomp --disable-libmudflap --disable-libssp --enable-lto --without-cloog
Thread model: posix
gcc version 4.8.2 (Gentoo 4.8.2-r1 p1.4-ssptest, pie-0.5.9-ssptest)

Change History (13)

comment:1 follow-up: Changed 3 years ago by juhpetersen

So LANG=C ghc ... or LANG=en_US.utf8 ghc ... do not give the warning? (possibility s/ghc/cabal/ etc)

I suspect it would be better to give an explicit example of how to reproduce the warning. What version of binutils (for GNU ld) do you have installed?

I don't think I have seen this on Fedora anyway, so it sounds like it could be a Gentoo specific issue perhaps.

comment:2 in reply to: ↑ 1 Changed 3 years ago by slyfox

Replying to juhpetersen:

So LANG=C ghc ... or LANG=en_US.utf8 ghc ... do not give the warning?

Yes, LANG=C "fixes" it.

I suspect it would be better to give an explicit example of how to reproduce the warning. What version of binutils (for GNU ld) do you have installed?

ghc's warning explicitely says about 'gcc' / 'clang'. I don't think it matters, but it's binutils-2.24.

Once I'll manage to filter out which exactly file triggers it from 9 parallel building threads I'll post a minimal example. I thought error message is obvious enough, but whatever:

compiler/main/SysTools.lhs

-- See Note [Run-time linker info].
getCompilerInfo' :: DynFlags -> IO CompilerInfo
getCompilerInfo' dflags = do
  let (pgm,_) = pgm_c dflags
      -- Try to grab the info from the process output.
      parseCompilerInfo _stdo stde _exitc
        -- Regular GCC
        | any ("gcc version" `isPrefixOf`) stde =
          return GCC
        -- Regular clang
        | any ("clang version" `isPrefixOf`) stde =
          return Clang
        ...

  -- Process the executable call
  info <- catchIO (do
                (exitc, stdo, stde) <- readProcessWithExitCode pgm ["-v"] ""
                -- Split the output by lines to make certain kinds
                -- of processing easier.
                parseCompilerInfo (lines stdo) (lines stde) exitc
            )
            (\err -> do
                debugTraceMsg dflags 2
                    (text "Error (figuring out compiler information):" <+>
                     text (show err))
                errorMsg dflags $ hang (text "Warning:") 9 $
                  text "Couldn't figure out linker information!" $$
                  text "Make sure you're using GNU gcc, or clang"
                return UnknownCC)
  return info

I don't think I have seen this on Fedora anyway, so it sounds like it could be a Gentoo specific issue perhaps.

Gentoo does not do translation to russian on it's own. What locale do you use on Fedora? Do you have non-english locale installed for gcc?

That should be easy to check:

LANG=ru_RU.UTF-8 gcc -v 2>&1 | tail -n1

comment:3 Changed 3 years ago by slyfox

And the example extracted from base package:

-- cat A.hs 
{-# LANGUAGE CApiFFI #-}
module A where

import Foreign.C

foreign import capi  unsafe "stdio.h value SEEK_END" sEEK_END :: CInt
$ ghc --make A.hs -fforce-recomp
[1 of 1] Compiling A                ( A.hs, A.o )

<no location info>:
    Warning: Couldn't figure out linker information!
             Make sure you're using GNU gcc, or clang
$ LANG=C ghc --make A.hs -fforce-recomp
[1 of 1] Compiling A                ( A.hs, A.o )

comment:4 Changed 2 years ago by slyfox

For current gcc-git things are quite scary:

~/dev/git/gcc/gcc/po:git grep -A1 'gcc version %s %s' | grep 'po-' | grep -v 'gcc version'
be.po-msgstr "версія gcc %s\n"
da.po-msgstr "GCC version %s\n"
de.po-msgstr "gcc-Version %s %s\n"
el.po-msgstr "έκδοση gcc %s\n"
es.po-msgstr "gcc versión %s %s\n"
fi.po-msgstr "gcc-versio %s %s\n"
fr.po-msgstr "version gcc %s\n"
hr.po-msgstr "gcc inačica %s %s\n"
id.po-msgstr "versi gcc %s %s\n"
ja.po-msgstr "gcc バージョン %s %s\n"
nl.po-msgstr "gcc versie %s %s\n"
ru.po-msgstr "gcc версия %s %s\n"
sr.po-msgstr "gcc верзија %s\n"
sv.po-
tr.po-msgstr "gcc %s sürümü\n"
vi.po-msgstr "gcc phiên bản %s %s\n"
zh_CN.po-msgstr "gcc 版本 %s %s\n"
zh_TW.po-msgstr "gcc 版本 %s %s\n"

comment:5 Changed 2 years ago by maeder

under solaris I had to "LC_ALL=C" in order to get rid of this stupid version check. It should be fixed in compiler/main/SysTools.lhs. Maybe calling "gcc --version" or "gcc -dumpversion" makes it easier. Otherwise "LC_ALL=C gcc -v" should be called.

comment:6 Changed 2 years ago by slyfox

  • Differential Rev(s) set to D185

I propose the following workaround:

https://phabricator.haskell.org/D185

comment:7 Changed 2 years ago by maeder

LANGUAGE=en works for me, too.

comment:8 Changed 2 years ago by Sergei Trofimovich <slyfox@…>

In 4d4d07704ee78221607a18b8118294b0aea1bac4/ghc:

systools: fix gcc version detecton on non-english locale

Summary:
ghc runs 'gcc -v' to check if we run under vanilla gcc
or disaguised clang by checking for string

    "gcc version <something>"

But this check does not always work as gcc has that string
localized via gettext mechanism:

    (some gcc's locale strings)
    be.po-msgstr "версія gcc %s\n"
    da.po-msgstr "GCC version %s\n"
    de.po-msgstr "gcc-Version %s %s\n"
    el.po-msgstr "έκδοση gcc %s\n"
    ...

To ping gcc to English locale we now override environment
variable with 'LANGUAGE=en' value.

Fixes Issue #8825

Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

Test Plan: validate

Reviewers: austin

Reviewed By: austin

Subscribers: simonmar, ezyang, carter

Differential Revision: https://phabricator.haskell.org/D185

GHC Trac Issues: #8825

comment:9 Changed 2 years ago by slyfox

  • Status changed from new to merge

comment:10 Changed 2 years ago by thoughtpolice

  • Milestone set to 7.8.4
  • Resolution set to fixed
  • Status changed from merge to closed

Merged to 7.8.4.

comment:11 Changed 2 years ago by refold

@dcoutts thinks that we should use LANGUAGE=C instead of en because there's no guarantee that the en locale is available.

comment:12 Changed 2 years ago by slyfox

On my system if I pass

LANGUAGE=something-incorrect

it fallbacks to 'en' messages anyways.

Looks like it's explicitely documented behaviour:

https://www.gnu.org/software/gettext/manual/html_node/The-LANGUAGE-variable.html

But I dont have strong preference over 'C'.

comment:13 Changed 4 months ago by Thomas Miedema <thomasmiedema@…>

In 753c5b24/ghc:

Simplify readProcessEnvWithExitCode + set LANGUAGE=C

`readProcessEnvWithExitCode` was added in
4d4d07704ee78221607a18b8118294b0aea1bac4, to start an external process
after making some modifications to the environment.

Since then, the `process` library has exposed
`readCreateProcessWithExitCode`, which allows for the refactoring we do
here.

Also change "en" to "C", as suggested in ticket:8825#comment:11.

Reviewed by: trofi

Differential Revision: https://phabricator.haskell.org/D2332

GHC Trac Issues: #8825
Note: See TracTickets for help on using tickets.