Re: [openvrml-develop] Link failure in building OpenVRML-0.16.1 on Mac OS X ppc

[Braden M. <br...@en...>]

On Thu, 2006-12-07 at 10:44 +0100, Thomas Engelmeier wrote:
> On 07.12.2006, at 10:23, Braden McDaniel wrote:
> 
> >> So the current state of my patch file to get OpenVRML 0.16.2 to build
> >> for Mac OS X is:
> >
> > I'm glad you got it working. Am I correct in assuming that Fink
> > accommodates patching pristine sources as part of the packaging  
> > process?
> >
> > As long as that's possible, I don't perceive a pressing need to
> > integrate these changes into the official sources.
> 
> Well, not everyone on OS X uses fink and the patches don't hurt on  
> any compiler anyway (I am not sure if inner classes like used  
> unpatched are guaranteed to work according to the standard,

C++ supports defining classes in function definitions. And that's used
other places in OpenVRML; so I'm pretty sure the problem with this bit
of code is more subtle than just that.

Moving these class definitions out of the function definitions was just
one of the three suggestions I gave; were the other two suggestions
ineffective?

>  and if  
> it's just Apple's GCC variant that mocks up due to an ABI that can't  
> handle them or if it's an general gcc problem...)

FWIW, there apparently is no problem building on PPC for Fedora Core 6,
which uses Red Hat's gcc 4.1.1.

Part of the problem is that the patch as currently given exposes symbols
that weren't exposed before. That's not something I'd like to introduce
everywhere. My preferred alternative to defining them locally would be
to define them as OPENVRML_LOCAL in the unnamed namespace--if that
works.

If the symbols *must* be visible on OS X, I'd want to make the code
conditional--which means that the compiler problem needs to be
sufficiently understood that a configure test can be written to detect
it.

With regard to the GL-related changes in the patch, I think the issue is
even more complicated. My understanding is that there are three or more
potential sources for glu.h on an OS X system--and most of them *don't*
exhibit the problem that the patch accommodates. I'm not certain, but I
think this particular problem is, more or less, Fink-specific.

-- 
Braden McDaniel                           e-mail: <br...@en...>
<http://endoframe.com>                    Jabber: <br...@ja...>