#540 LDFLAGS not used by generated ghc

Compiler (190)


I specified LDFLAGS=-Wl,-bbigtoc which is needed to
link programs of any size on AIX, including ghc.

The stage1/ghc-inplace compiler, however, is not
passing this along to gcc.

I can manually run the commands that make is running,
add -optl -Wl,-bbigtoc and get the correct result, but
GHC should do this itself.

This is GHC 6.4.1.


  • John Goerzen

    John Goerzen - 2005-11-23

    Logged In: YES

    The final (stage2) compiler also does not honor these flags

  • Simon Marlow

    Simon Marlow - 2005-11-28
    • status: open --> closed-wont-fix
  • Simon Marlow

    Simon Marlow - 2005-11-28

    Logged In: YES

    Where do you want LDFLAGS to be used? Just when building
    GHC, or do you want them to be added for every link in the
    tree? And when the GHC you're building does any linking itself?

    We don't tend to use LDFLAGS/CFLAGS because they're a bit
    global, it's not usually what you want. Instead, you should
    modify build.mk, something like this:

    GhcStage1HcOpts += -optl-Wl,-bbigtoc

    and if you want GHC to always add this option for you, then
    the best place to put it is the ld-options field of the rts
    package (see ghc/rts/package.conf.in). (also there's
    machdepCCOptions in ghc/compiler/main/DynFlags, but that
    applies to all C compilations and it's wired into the
    compiler, so that's perhaps not as suitable).

  • John Goerzen

    John Goerzen - 2005-11-28

    Logged In: YES

    All of the above, really. I want LDFLAGS to be used when
    building ghc, any other tools in the tree, and when GHC does
    linking itself.

    I'll take a look at the config options you mentioned. Did I
    miss them in the docs somewhere? If not, could this bug be
    considered a request to document this?

  • Simon Marlow

    Simon Marlow - 2005-11-28

    Logged In: YES

    It sounds like this is just something we need to add to the
    source tree for AIX. If you want -Wl,-bbigtoc always added
    to the link line, then adding it to ghc/rts/package.conf.in
    is the right thing (add it, test it, send us a patch and
    we'll commit).

    This isn't really end-user stuff so there isn't
    documentation as such. package.conf.in is an
    InstalledPackageInfo though, which is documented in


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks