Name clash errors during stage 2 compile of Foreign.Marshal.Alloc
bgamari.foss at gmail.com
Mon Oct 17 18:50:53 CEST 2011
On Mon, 17 Oct 2011 10:24:29 -0500, Gabriel Dos Reis <gdr at integrable-solutions.net> wrote:
> On Mon, Oct 17, 2011 at 9:52 AM, Ben Gamari <bgamari.foss at gmail.com> wrote:
> > On Mon, 17 Oct 2011 08:55:42 +0100, Simon Marlow <marlowsd at gmail.com> wrote:
> >> I think if we just add those functions to the table unconditionally, it
> >> may break the C backend on certain other platforms or perhaps other
> >> versions of gcc. I agree it should work out of the box, but we did not
> >> need this change in the past, so why is it necessary now?
> >> We need to identify exactly where this change is necessary. Perhaps it
> >> is a recent change in gcc? If so, we need to know which version.
> > Fair enough. A little bit of Googling confirmed that GCC does tree
> > malloc, et al. as builtins. It seems the correct approach here might
> > be to instead pass the -fno-builtin option to gcc.
> plain -fno-builtin will instruct GCC from doing any kind of optimizations
> on -any- standard C function calls -- not just malloc(). Is that what you want?
It's unclear. The problem is merely a name conflict so I agree that this
does seem like overkill. Does the C backend rely on the compiler's
builtins at all?
> > This hides, e.g.,
> > malloc() while keeping the function available as __builtin_malloc(). I
> > still don't know what version of GCC turned malloc() into a builtin, but
> > the -fno-builtin option has been around since before gcc 4.0.4 (didn't
> > check earlier versions) so it should be safe. If we want a more minimal
> > change, we can just pass "-fno-builtin-free -fno-builtin-realloc
> > -fno-builtin-malloc" to only exclude these functions.
> If you are only worried about malloc() and free(), I would suggest the more
> specific options: -fno-builtin-free -fno-builtin-realloc -fno-builtin-free.
The issue was caused by these in particular so this ould probably be a
> Builtin support for malloc(), calloc() was introduced in GCC-3.4
> (If my memory serves me correctly.) It had been in GCC development
> tree since April 2003.
Really? I find it hard to believe that the last time someone used GHC's
C backend with GCC was in April 2003. There must be something else at
More information about the Cvs-ghc