[haiku-development] Re: gcc2.95.3??
- From: John Scipione <jscipione@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Thu, 10 May 2012 02:08:51 -0400
On Wed, May 9, 2012 at 3:59 AM, Oliver Tappe <zooey@xxxxxxxxxxxxxxx> wrote:
> On 2012-05-09 at 07:56:19 [+0200], John Scipione <jscipione@xxxxxxxxx>
> wrote:
> > On Wed, May 9, 2012 at 12:54 AM, John Scipione <jscipione@xxxxxxxxx>
> wrote:
> >
> > > I am scratching my head here on this one a bit.
> > >
> > > I am getting an error "cast specifies signature type" when I set a
> pointer
> > > to a member function to NULL on gcc2 built on Mac OS X 10.7 Lion, but
> not
> > > gcc2 build on 10.6 Snow Leopard. That is weird enough but it gets
> > > stranger.
>
> I agree with Stephan and find it *very* peculiar that the gcc-2.95.3 built
> on
> Mac OS X 10.6 behaves differently from the one built on Mac OS X 10.7.
> Unlikely as it seems, the difference in behaviour may be triggered gccs
> build
> system - maybe the feature (signature-handling) is being switched off on
> 10.6?
>
I also find this to be quite peculiar. Is it possible that the Haiku build
system is hardcoding /usr/bin/gcc or /usr/bin/cc somewhere instead of
looking at my CC and CXX environmental variables when building gcc2?
Because if it were, it would get llvm-gcc which I could imagine could cause
problems. I've installed gcc4 on my host, but the default compiler in Lion
(installed by Xcode) is llvm-gcc, and /usr/bin/gcc is a symlink to llvm-gcc.
> In any case, it'd be good to know how other build platforms behave, so: do
> you get the error when building Haiku?
>
Yes, I get the error when building Haiku... well I did before I hacked
around it anyway. There are a couple of places where Haiku is using
pointers to member functions, an obvious one is
src/lib/print/libprint/Halftone.cppL87. There fDither is set to a do
nothing function which I added to get around this bug, but, if I change it
back to NULL again, it will trigger the bug, and I'll get a "cast specifies
signature type" error on gcc2. gcc4 works fine.
> This question still remains though, perhaps I can back-port a fix from the
> > gcc sources. Although, I was expecting to see the bug fixed after 2001,
> not
> > in 1999. Since this is gcc2 and binary compatibility is critical here,
> I'd
> > like someone with more experience in this area to check out the code and
> > see if there is anything I can do to fix this.
>
> The change is pretty large (rev.28677 involves many more files than just
> cp/typeck.c), thus I find it a bit difficult to judge its effect on binary
> compatibility (the ABI). That being said, it looks as if they've just
> removed
> one specific feature in that patch, so I think it's rather unlikely that
> the
> ABI has been changed.
> The problem here is though, that it's not easy to find out if that is
> indeed
> the case. One could rebuild all of Haiku and then compare the names and
> sizes
> of each and every symbol in all the shared libraries living in /system/lib.
> But even that still isn't a reliable check, just a hint.
>
I guess back porting a fix like this would be tricky, I don't want to break
ABI compatibility. Since this change happened in August 1999 and gcc 2.95
was released in July 1999, perhaps this is a change they made in-tree once
they were free to break the gcc2 ABI which eventually got released in gcc
3.0. I am guessing here, I have no idea.
John Scipione
Other related posts:
