Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 556216 - app-text/pandoc ebuild (and other haskell ebuilds) doesn't respect CC and CXX
Summary: app-text/pandoc ebuild (and other haskell ebuilds) doesn't respect CC and CXX
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: AMD64 Linux
: Normal normal with 1 vote (vote)
Assignee: Gentoo's Haskell Language team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-07-29 12:07 UTC by Jan Chren (rindeal)
Modified: 2016-05-07 13:14 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Chren (rindeal) 2015-07-29 12:07:05 UTC
Hi,

I've upgraded my compiler to GCC 5.2 and pandoc failed to compile. I tried to downgrade to GCC 4.9 via package.env and found out that even though temp/environment shows correct values in CC and CXX temp/build.log still shows GCC 5.2. I tried to dig into the compilation process and discovered that work/setup accepts --with-gcc argument. After setting this argument to gcc-4.9.3 pandoc really compiled with gcc-4.9.3

Reproducible: Always



Expected Results:  
 

app-text/pandoc-1.12.1-r1
Comment 1 Sergei Trofimovich gentoo-dev 2015-08-01 22:17:00 UTC
Yes, ghc currently uses gcc from  'ghc --info' (usually ${CTARGET}-gcc).
It should be possible to set nonstandard gcc by --with-gcc= flag.

I'll try to experiment with it in ::haskell overlay first.
Comment 2 Steve Arnold gentoo-dev 2015-10-08 21:33:02 UTC
This looks like the right symptom, current "effect" is broken pandoc deps.  I only had a few Haskell packages installed, "emerge pandoc" wants to install 100+ Haskell deps and upgrade everything.  About halfway through it fails and I get the "please run haskell-updater" error.  Running haskell-upater fails some time later with the same error message (ie, please run haskell-updater).

Right now it is stuck on dev-haskell/network in the above error loop; since it doesn't respect CC/CFLAGS on the cli, I had to modify some environment stuff to get this far:

# cat /etc/portage/env/cabal-extra.conf 
CABAL_EXTRA_CONFIGURE_FLAGS="--with-cc=x86_64-pc-linux-gnu-gcc"

but it just fails later running haskell-updater:

 ...
 * ghc-pkg check: 'checking for other broken packages:'
 * Detected outdated packages: dev-haskell/convertible:0 dev-haskell/hdbc:2
 * ERROR: dev-haskell/network-2.6.2.1::gentoo failed (configure phase):
 *   //==-- Please, run 'haskell-updater' to fix outdated packages --==//

and fails the same way on convertible and hdbc:

# haskell-updater -u --no-deep
Running haskell-updater-1.2.9 using GHC 7.10.2
  * Executable: /usr/bin/ghc
  * Library directory: /usr/lib64/ghc-7.10.2
  * Package manager (PM): portage

Searching for packages installed with a different version of GHC.

Found the following old packages:
  * dev-haskell/convertible:0
  * dev-haskell/hdbc:2

emerge --oneshot --keep-going --complete-graph --quiet dev-haskell/convertible:0 dev-haskell/hdbc:2

 * IMPORTANT: 2 news items need reading for repository 'gentoo'.
 * Use eselect news read to view new items.

>>> Verifying ebuild manifests
>>> Emerging (1 of 2) dev-haskell/convertible-1.1.0.0-r1::gentoo
>>> Failed to emerge dev-haskell/convertible-1.1.0.0-r1, Log file:
>>>  '/var/log/portage/dev-haskell:convertible-1.1.0.0-r1:20151008-212835.log'
*** Resuming merge...
 * emerge --keep-going: dev-haskell/hdbc-2.4.0.1 dropped because it requires
 * >=dev-haskell/convertible-1.1.0.0:=, >=dev-haskell/convertible-1.1.0.0:=

 * Error messages for package dev-haskell/convertible-1.1.0.0-r1:

What's the workaround for this?  Do I need a live chicken?
Comment 3 Steve Arnold gentoo-dev 2015-10-09 02:27:17 UTC
Answer:

1) remove old stuff manually, haskell-network fails

2) configure this:

in /etc/portage/package.env/x86_64-pc-linux-gnu:

dev-lang/ghc cabal-extra.conf plain-flags.conf
dev-haskell/network plain-flags.conf

and in /etc/portage/env/{cabal-extra.conf,plain-flags.conf}

cabal-extra.conf:

CABAL_EXTRA_CONFIGURE_FLAGS="--with-compiler=/usr/bin/x86_64-pc-linux-gnu-gcc"

plain-flags.conf:

CC="x86_64-pc-linux-gnu-gcc"
CXX="x86_64-pc-linux-gnu-g++"
LD="x86_64-pc-linux-gnu-ld"
CFLAGS="-march=athlon64 -mtune=amdfam10 -O2 -pipe"
CXXFLAGS="${CFLAGS}"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"

3) rebuild ghc, then restart emerge pandoc and haskell-network builds (and it even keeps going...)
Comment 4 Sergei Trofimovich gentoo-dev 2015-10-09 08:36:13 UTC
I agree haskell stuff does not respect CC/CXX but it should not make packages fail.

Do you have build.log with a package failure at hand?

> CABAL_EXTRA_CONFIGURE_FLAGS="--with-compiler=/usr/bin/x86_64-pc-linux-gnu-gcc"

--with-compiler requires haskell compiler, you likley need a --with-gcc=.
Comment 5 Sergey 'L29Ah' Alirzaev 2016-05-03 15:35:49 UTC
It makes packages fail when gcc doesn't support the CFLAGS a user provides.
Comment 6 Sergei Trofimovich gentoo-dev 2016-05-05 22:08:10 UTC
Finally tried to reproduce it today.
The first prerequisite for build failure is
presence of .c or .c++ files in haskell package.

One of them is dev-haskell/re2 (overlay only),
but there should be C-based packages as well, like network.

My reproducer is:
$ CC=clang CFLAGS=-fheinous-gnu-extensions HCFLAGS="-O0" emerge -1 dev-haskell/re2

Dependency vector -any: using vector-0.11.0.0
x86_64-pc-linux-gnu-gcc: error: unrecognized command line option ‘-fheinous-gnu-extensions’

That sounds about right.

There is at  least 2 places where compilers can be tweaked:
- Cabal's --with-gcc= option (cabal's side .hsc -> .hs preprocessor)
- GHC's owh overrides -pgmc/l/a

Using comething like that in make.conf should workaround it:

    HCFLAGS="-pgmc${CC} -pgma${CC} -pgml${CC}"

I'll try to plumb the same via haskell-cabal.eclass.
Comment 7 Sergei Trofimovich gentoo-dev 2016-05-07 13:14:40 UTC
> Using comething like that in make.conf should workaround it:
> 
>     HCFLAGS="-pgmc${CC} -pgma${CC} -pgml${CC}"
> 
> I'll try to plumb the same via haskell-cabal.eclass.

This change tried to apply it but GHC is not designed to use these options
that way. It breaks all the default compiler flags recorded at ghc build
time.

diff --git a/eclass/ghc-package.eclass b/eclass/ghc-package.eclass
index 5466c0b..9824d13 100644
--- a/eclass/ghc-package.eclass
+++ b/eclass/ghc-package.eclass
@@ -14 +14 @@
-inherit versionator
+inherit toolchain-funcs versionator
@@ -29,0 +30,14 @@ ghc-getghcpkg() {
+# @FUNCTION: ghc-tcflags
+# @DESCRIPTION:
+# Function returns tool-chain-specific flags.
+# Currently only C compiler override for ghc.
+ghc-tcflags() {
+       local cc=$(tc-getCC)
+       local tcflags=(
+               -pgmc"${cc}" # C compiler
+               -pgma"${cc}" # assembler (via compiler)
+               -pgml"${cc}" # linker (via compiler)
+       )
+       echo "${tcflags[@]}"
+}
+
diff --git a/eclass/haskell-cabal.eclass b/eclass/haskell-cabal.eclass
index 4d338d1..392623d 100644
--- a/eclass/haskell-cabal.eclass
+++ b/eclass/haskell-cabal.eclass
@@ -221 +221 @@ cabal-bootstrap() {
-                       ${HCFLAGS} \
+                       $(ghc-tcflags) ${HCFLAGS} \
@@ -374 +374 @@ cabal-configure() {
-       for option in ${HCFLAGS}
+       for option in $(ghc-tcflags) ${HCFLAGS}


The changes in re2 before- and after- build.log:

-x86_64-pc-linux-gnu-gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -Idist/build/autogen -Idist/build -Ithird-party/re2-20140304/ -fPIC -U__PIC__ -D__PIC__ -xassembler -c /tmp/portage/dev-haskell/re2-0.1/temp/ghc22376_0/ghc_1.s -o dist/build/cbits/haskell-re2.o
+x86_64-pc-linux-gnu-gcc -Idist/build/autogen -Idist/build -Ithird-party/re2-20140304/ -fPIC -U__PIC__ -D__PIC__ -x assembler -c /tmp/portage/dev-haskell/re2-0.1/temp/ghc1760_0/ghc_1.s -o dist/build/cbits/haskell-re2.o

here we've lost 2 default flags:
-fno-stack-protector -DTABLES_NEXT_TO_CODE