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

[Thomas E. <te-...@en...>]

On 07.12.2006, at 17:03, Braden McDaniel wrote:

>>> 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.

At least it is a long going problem on OS X and chances are little  
it's gonna be fixed.
When I was researching for an fix half an year ago I found traces of  
that error (but no fix) some years back, which was IIRC shortly after  
OS X 10.1 was released...

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

The OP is someone different ;-) so I cannot comment on that.

>>  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.

Well, Apple apparently uses the Mach-O symbol format (that is pretty  
lame for register-rich RISC processors)  and not PEF or ELF, I guess  
it's a linker and symbol decoration problem...

> 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.

IIRC, it is sufficent to expose the symbols as a *static* (local)  
class in an compilation unit. Well that exposes the symbol just to a  
handful functions more in the same compilation unit...

> 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.

It is definitely not fink but OS X specific. My attempt (once again,  
long before that patch) was not based on fink, and I also had to fix  
quite some other opensource gl based projects in the same manner

Best regards,
	Tom_E