Opened 6 years ago

Closed 5 years ago

#8498 closed bug (fixed)

gcc hardcoded in build scripts! (ignores the --with-gcc= flag in configure)

Reported by: carter Owned by:
Priority: high Milestone: 7.8.3
Component: Compiler Version: 7.7
Keywords: Cc: tibbe, simonmar
Operating System: MacOS X Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

NB: this may be a dupe of another issue, but reporting is separately for now

i'm on OS X 10.8 (mountain lion) with xcode 5, ghc comit 23fb7f3b7987d7b3fa445e54680a8a00a37e714d,

I've got a gcc-4.8 installed, though gcc in my path is actually clang (as is typical for xcode 5), so I configured as ./configure --with-gcc=gcc-4.8

and then I noticed as i'm building, some warnings that mean clang is being called rather than gcc!

heres a relevant snippet of the build transcript

cp" utils/hsc2hs/template-hsc.h inplace/lib/template-hsc.h
"/usr/bin/ghc" -hisuf hi -osuf  o -hcsuf hc -static  -H64m -O -fasm -package process -package containers -package-db libraries/bootstrapping.conf   -i -iutils/deriveConstants/. -iutils/deriveConstants/dist/build -iutils/deriveConstants/dist/build/autogen -Iutils/deriveConstants/dist/build -Iutils/deriveConstants/dist/build/autogen         -no-user-package-db -rtsopts      -odir utils/deriveConstants/dist/build -hidir utils/deriveConstants/dist/build -stubdir utils/deriveConstants/dist/build   -c utils/deriveConstants/./DeriveConstants.hs -o utils/deriveConstants/dist/build/DeriveConstants.o 
"inplace/bin/mkdirhier" utils/deriveConstants/dist/build/tmp//.
"inplace/bin/mkdirhier" rts/dist/build//.
gcc -E  -m64 -undef -traditional -P -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header  -Icompiler/stage1 -x c compiler/prelude/primops.txt.pp | grep -v '^#pragma GCC' > compiler/stage1/build/primops.txt
compiler/prelude/primops.txt.pp:35:55: warning: missing terminating ' character [-Winvalid-pp-token]
-- The default attribute values which apply if you don't specify
                                                      ^
compiler/prelude/primops.txt.pp:1310:19: warning: missing terminating ' character [-Winvalid-pp-token]
         difference doesn't fit in an {\tt Int\#}.}
                         ^
compiler/prelude/primops.txt.pp:1591:41: warning: missing terminating ' character [-Winvalid-pp-token]
-- not really the right type, but we don't know about pairs here.  The
                                        ^
compiler/prelude/primops.txt.pp:1620:15: warning: missing terminating ' character [-Winvalid-pp-token]
        -- but we don't want to tell the strictness
                     ^
compiler/prelude/primops.txt.pp:1634:30: warning: missing terminating ' character [-Winvalid-pp-token]
-- must be *precise* - we don't want the strictness analyser turning
                             ^
compiler/prelude/primops.txt.pp:1690:14: warning: missing terminating ' character [-Winvalid-pp-token]
-- NB: retry#'s strictness information specifies it to return bottom.
             ^
compiler/prelude/primops.txt.pp:1811:47: warning: missing terminating ' character [-Winvalid-pp-token]
    Otherwise, store value arg as {\tt MVar\#}'s new contents, and return with integer 1.}
                                              ^
compiler/prelude/primops.txt.pp:1906:21: warning: missing terminating ' character [-Winvalid-pp-token]
        {\tt RealWorld}; it's only used in the type system, to parameterise {\tt State\#}. }
                           ^
compiler/prelude/primops.txt.pp:2084:67: warning: missing terminating ' character [-Winvalid-pp-token]
   -- why return the value?  So that we can control sharing of seq'd
                                                                  ^
compiler/prelude/primops.txt.pp:2087:13: warning: missing terminating ' character [-Winvalid-pp-token]
   -- we don't want to inline x, so better to represent it as
            ^
compiler/prelude/primops.txt.pp:2108:48: warning: missing terminating ' character [-Winvalid-pp-token]
--   `the processor containing the expression v'; it is not evaluated
                                               ^
compiler/prelude/primops.txt.pp:2206:20: warning: missing terminating ' character [-Winvalid-pp-token]
        {These aren't nearly as wired in as Etc...}
                   ^
compiler/prelude/primops.txt.pp:2236:57: warning: missing terminating ' character [-Winvalid-pp-token]
          * It does not claim to be a {\it data} type, and that's important for
                                                               ^
compiler/prelude/primops.txt.pp:2240:4: warning: missing terminating ' character [-Winvalid-pp-token]
        It's also used to instantiate un-constrained type variables after type
          ^
compiler/prelude/primops.txt.pp:2278:86: warning: missing terminating ' character [-Winvalid-pp-token]
        used when you want to write a program that you know is well-typed, but where Haskell's
                                                                                            ^
compiler/prelude/primops.txt.pp:2301:28: warning: missing terminating ' character [-Winvalid-pp-token]
        have to do with GHC's internal representation details (for the congnoscenti, data values
                           ^
compiler/prelude/primops.txt.pp:2307:76: warning: missing terminating ' character [-Winvalid-pp-token]
-- NB. It is tempting to think that casting a value to a type that it doesn't have is safe
                                                                           ^
compiler/prelude/primops.txt.pp:2308:22: warning: missing terminating ' character [-Winvalid-pp-token]
-- as long as you don't "do anything" with the value in its cast form, such as seq on it.  This
                     ^
compiler/prelude/primops.txt.pp:2309:7: warning: missing terminating ' character [-Winvalid-pp-token]
-- isn't the case: the compiler can insert seqs itself, and if these happen at the wrong type,
      ^
compiler/prelude/primops.txt.pp:2344:17: warning: missing terminating ' character [-Winvalid-pp-token]
     the newtype's concrete type to the abstract type. But it also works in
                ^
compiler/prelude/primops.txt.pp:2367:67: warning: missing terminating ' character [-Winvalid-pp-token]
     {\tt instance Coercible b b' => Coercible (D a b c) (D a b' c')}
                                                                  ^
compiler/prelude/primops.txt.pp:2389:43: warning: missing terminating ' character [-Winvalid-pp-token]
     you need to set the role of {\tt Set}'s type parameter to Nominal.


notice the hard coded gcc call

gcc -E -m64 -undef -traditional -P -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Icompiler/stage1 -x c compiler/prelude/primops.txt.pp | grep -v '^#pragma GCC' > compiler/stage1/build/primops.txt

Change History (15)

comment:1 Changed 6 years ago by carter

heres another offending line

gcc -E  -m64 -undef -traditional -P -DTOP='"/Users/carter/Desktop/repoScratcher/ghc"' -DPAPI_INCLUDE_DIR="" -DPAPI_LIB_DIR="" -DFFI_INCLUDE_DIR= -DFFI_LIB_DIR= '-DFFI_LIB="Cffi"' -x c -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header rts/package.conf.in -o rts/dist/package.conf.inplace.raw

comment:2 Changed 6 years ago by hvr

My first guess would be that --with-gcc isn't passed to all sub-packages properly so that they fall-back to an autodetected gcc, as the actual use of gcc doesn't seem to be hardcoded in the build scripts.

comment:3 Changed 6 years ago by adamse

To compile GHC on commit 6d24076be9aff562cd449aa1d39b8eb14638bcd6 I had to specify a working compiler (I used a clang wrapper) in the settings file for my bootstrapping ghc.

Located at /Library/Frameworks/GHC.framework/Versions/Current/usr/lib/ghc-7.4.2/settings for the latest Haskell platform I believe.

comment:4 Changed 6 years ago by tibbe

Cc: tibbe added

comment:5 Changed 6 years ago by tibbe

Cc: simonmar added

Using make -d it seems like the RTS is indeed to blame:

 Must remake target `rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm'.
"rm" -f rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.tmp  
Putting child 0x7fc32f874ae0 (rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm) PID 46072 on the chain.
Live child 0x7fc32f874ae0 (rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm) PID 46072 
Reaping winning child 0x7fc32f874ae0 PID 46072 
gcc -E  -m64 -DPROFILING -DTHREADED_RTS -DDEBUG -Irts/dist/build  -m64 -fno-stack-protector  -Wall -Wextra -Wstrict-prototypes  -Wmissing-prototypes  -Wmissing-declarations -Winline -Waggregate-return -Wpointer-arith -Wmissing-noreturn -Wnested-externs -Wredundant-decls  -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -fno-strict-aliasing -fno-common -DDTRACE        -O2 -fomit-frame-pointer -DRtsWay=\"rts_v\" -Wno-strict-prototypes    -Wno-strict-prototypes  -MM -x c rts/Adjustor.c -MF rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit
Live child 0x7fc32f874ae0 (rts/dist/build/.depend-v-dyn-l-debug-thr-thr_debug-thr_l-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm) PID 46074 

Do we have anyone who understands the build system now when Ian isn't working at GHC HQ anymore? Simon M?

comment:6 in reply to:  description Changed 6 years ago by hvr

Replying to carter:

notice the hard coded gcc call

gcc -E -m64 -undef -traditional -P -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Icompiler/stage1 -x c compiler/prelude/primops.txt.pp | grep -v '^#pragma GCC' > compiler/stage1/build/primops.txt

fyi, this may be actually related to #8683 as the rule involved uses $CPP:

compiler/stage$1/build/Parser.y: compiler/parser/Parser.y.pp
        $$(CPP) $$(RAWCPP_FLAGS) -P $$(compiler_CPP_OPTS) -x c $$< | grep -v '^#pragma GCC' > $$@

comment:7 Changed 6 years ago by simonmar

I don't off-hand know why this is happening, but regressions in --with-gcc are not uncommon since we don't test it regularly.

Looks like there are at least two things wrong:

  • $(CPP) is mapped to gcc. It comes directly from configure, so that should be easy enough to find.
  • The command that is building a file from the RTS is invoking GHC, so I suspect somehow GHC itself has a gcc baked into it (or passed in from configure?).

comment:8 Changed 6 years ago by simonmar

I think I know why this is (came across it while looking at something else). We ask the bootstrapping GHC for the name of the C compiler it uses, and this becomes $(CC_STAGE0). This is then used for compiling anything in stage 0, that is, things that we need during the build. I'm not sure why it would be used when compiling the RTS though, that seems wrong.

Probably what we want to do is make --with-gcc set $(CC_STAGE0), overriding the value provided by the stage 0 GHC.

comment:9 Changed 5 years ago by simonmar

$CPP is set by configure's AC_PROG_CPP, so it is completely separate from --with-gcc. To set this, you need to set CPP when invoking configure, like this:

   $ CPP="/path/to/gcc -E" ./configure --with-gcc=/path/to/gcc

I have a patch for the CC_STAGE0 thing on the way.

comment:10 Changed 5 years ago by igloo

Why do we need to use the --with-gcc value for $(CC_STAGE0)? The idea is that you need to have a working bootstrapping compiler, and the inferred $(CC_STAGE0) is part of that. There's no particular reason that the --with-gcc value should work, though.

comment:11 Changed 5 years ago by simonmar

We might not be able to use the gcc from the stage 0 compiler (I can go into details about the particular setup that leads to this problem, but it's long and boring). The point is, if you want to override $(CC_STAGE0), there's currently no good way to do it. I think having --with-gcc set $(CC_STAGE0) is fairly sensible provided we're not cross-compiling. I'm open to other suggestions though.

comment:12 Changed 5 years ago by carter

so do we perhaps want to have "overrides" like '--with-FOO-StageN' flags?

comment:13 Changed 5 years ago by Simon Marlow <marlowsd@…>

In 6189c7674fc5c735db1a446d0b222369a3767369/ghc:

--with-gcc overrides CC_STAGE0 when not cross-compiling (#8498)

comment:14 Changed 5 years ago by simonmar

Status: newmerge

comment:15 Changed 5 years ago by thoughtpolice

Resolution: fixed
Status: mergeclosed
Note: See TracTickets for help on using tickets.