[Crystal-develop] OS X Tiger compile issues

Post by Per Eckerdal
I've got some problems compiling CS on OS X Tiger. Most of it is
probably because of GCC 4.0. (I don't know if this has already been
C++ ./out/macosxppc/optimize/libs/cstool/mdltool.o
libs/cstool/mdltool.cpp: In static member function `static void
libs/cstool/mdltool.cpp:734: internal compiler error: in cp_tree_equal,
at cp/tree.c:1679

Whoops, internal error. Not sure we can do something about that... perhaps try
to play with the offending source, maybe GCC4 swallows something semantically
equivalent in slightly different syntax.

Post by Per Eckerdal
./include/csqsqrt.h:77: error: extra ';'
./include/csqsqrt.h:93: error: extra ';'

Fixed in CVS.

Post by Per Eckerdal
plugins/video/loader/dds/ImageLib/Table.h:35:20: error: malloc.h: No
such file or directory (and a lot more about malloc.h. If I've
understood that right, that is a deprecated header which is removed in
GCC 4)

Fixed.

Post by Per Eckerdal
plugins/video/render3d/opengl/gl_render3d.cpp:866: error: invalid
conversion from 'int*' to 'GLint*'

Fixed.

Post by Per Eckerdal
I hope this helped at least a little..

Yes. We don't have much people who compile CS with GCC4 and/or on OS/X, so
information about problems is appreciated.

-f.r.

Per Eckerdal

2005-05-18 11:45:24 UTC

Okay, I'll be playing around with this method.
Here is another error:

C++ ./out/macosxppc/optimize/apps/tools/cslight/cslight.o
apps/tools/cslight/cslight.cpp: In member function `bool
Lighter::Initialize(int, const char* const*, const char*)':
apps/tools/cslight/cslight.cpp:383: error: cannot allocate an object
of abstract type 'csCsLightProgressMeter'
apps/tools/cslight/cslight.h:39: note: because the following
virtual functions are pure within 'csCsLightProgressMeter':
./include/ivaria/pmeter.h:54: note: virtual void iProgressMeter::Step
(unsigned int)

g++ -c -o ./out/macosxppc/optimize/apps/tools/cslight/cslight.o -
I. -I./include -I./include -Wmost -Wno-unknown-pragmas -pipe -I/usr/
local/include -Wno-long-double -force_cpusubtype_ALL -fno-common -fno-
exceptions -fvisibility=hidden -O3 -fomit-frame-pointer -ffast-math -
fvisibility-inlines-hidden apps/tools/cslight/cslight.cpp

...failed C++ ./out/macosxppc/optimize/apps/tools/cslight/cslight.o ...
/Per Eckerdal

Post by Per Eckerdal
I've got some problems compiling CS on OS X Tiger. Most of it is
probably because of GCC 4.0. (I don't know if this has already
been posted, but I couldn't find anything..) This is the (first)
C++ ./out/macosxppc/optimize/libs/cstool/mdltool.o
libs/cstool/mdltool.cpp: In static member function `static void
libs/cstool/mdltool.cpp:734: internal compiler error: in
cp_tree_equal, at cp/tree.c:1679

Whoops, internal error. Not sure we can do something about that...
perhaps try to play with the offending source, maybe GCC4 swallows
something semantically equivalent in slightly different syntax.

Post by Per Eckerdal
./include/csqsqrt.h:77: error: extra ';'
./include/csqsqrt.h:93: error: extra ';'

Fixed in CVS.

Post by Per Eckerdal
No such file or directory (and a lot more about malloc.h. If
I've understood that right, that is a deprecated header which is
removed in GCC 4)

Fixed.

Post by Per Eckerdal
plugins/video/render3d/opengl/gl_render3d.cpp:866: error: invalid
conversion from 'int*' to 'GLint*'

Fixed.

Post by Per Eckerdal
I hope this helped at least a little..

Yes. We don't have much people who compile CS with GCC4 and/or on
OS/X, so information about problems is appreciated.
-f.r.

res

2005-05-18 11:56:09 UTC

Post by Per Eckerdal
Okay, I'll be playing around with this method.

This one is fixed in CVS already.

-f.r.

dr. W.C.A. Wijngaards

2005-05-18 11:55:33 UTC

Post by Per Eckerdal
Okay, I'll be playing around with this method.
C++ ./out/macosxppc/optimize/apps/tools/cslight/cslight.o
apps/tools/cslight/cslight.cpp: In member function `bool
apps/tools/cslight/cslight.cpp:383: error: cannot allocate an object
of abstract type 'csCsLightProgressMeter'
apps/tools/cslight/cslight.h:39: note: because the following
./include/ivaria/pmeter.h:54: note: virtual void iProgressMeter::Step
(unsigned int)

Fixed.
Best regards, Wouter

Post by Per Eckerdal
g++ -c -o ./out/macosxppc/optimize/apps/tools/cslight/cslight.o -
I. -I./include -I./include -Wmost -Wno-unknown-pragmas -pipe -I/usr/
local/include -Wno-long-double -force_cpusubtype_ALL -fno-common -fno-
exceptions -fvisibility=hidden -O3 -fomit-frame-pointer -ffast-math -
fvisibility-inlines-hidden apps/tools/cslight/cslight.cpp
...failed C++ ./out/macosxppc/optimize/apps/tools/cslight/cslight.o ...
/Per Eckerdal

Whoops, internal error. Not sure we can do something about that...
perhaps try to play with the offending source, maybe GCC4 swallows
something semantically equivalent in slightly different syntax.

Post by Per Eckerdal
./include/csqsqrt.h:77: error: extra ';'
./include/csqsqrt.h:93: error: extra ';'

Fixed in CVS.

Post by Per Eckerdal
No such file or directory (and a lot more about malloc.h. If I've
understood that right, that is a deprecated header which is
removed in GCC 4)

Fixed.

Post by Per Eckerdal
plugins/video/render3d/opengl/gl_render3d.cpp:866: error: invalid
conversion from 'int*' to 'GLint*'

Fixed.

Post by Per Eckerdal
I hope this helped at least a little..

Yes. We don't have much people who compile CS with GCC4 and/or on
OS/X, so information about problems is appreciated.
-f.r.

-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
_______________________________________________
Crystal-develop mailing list
https://lists.sourceforge.net/lists/listinfo/crystal-develop

Jeremy Bell

2005-05-18 13:35:26 UTC

Post by res
Whoops, internal error. Not sure we can do something about that... perhaps try
to play with the offending source, maybe GCC4 swallows something semantically
equivalent in slightly different syntax.

Per Eckerdal

2005-05-18 16:36:29 UTC

Now I've submitted the bug report (ID 4123010).
The bug does only appear when _all_ of "-fno-exceptions -O3 -ffast-
math" is sent to the compiler, so I fixed it by lowering the
optimization level to 2 by editing COMPILER.CFLAGS.optimize in
Jamconfig.

However, I encountered some more problems. Here are the error messages:

plugins/cscript/cspython/cs_pyth.cpp: In function `PyObject*
_wrap_csGraphics3DCaps_fog_set(PyObject*, PyObject*)':
plugins/cscript/cspython/cs_pyth.cpp:115100: error: 'G3D_FOGMETHOD'
was not declared in this scope
plugins/cscript/cspython/cs_pyth.cpp:115100: error: expected `;'
before "arg2"
plugins/cscript/cspython/cs_pyth.cpp:115108: error: 'arg2' was not
declared in this scope
plugins/cscript/cspython/cs_pyth.cpp:115111: error: 'struct
csGraphics3DCaps' has no member named 'fog'
plugins/cscript/cspython/cs_pyth.cpp:115111: error: expected `;'
before "arg2"
plugins/cscript/cspython/cs_pyth.cpp: In function `PyObject*
_wrap_csGraphics3DCaps_fog_get(PyObject*, PyObject*)':
plugins/cscript/cspython/cs_pyth.cpp:115123: error: 'G3D_FOGMETHOD'
was not declared in this scope
plugins/cscript/cspython/cs_pyth.cpp:115123: error: expected `;'
before "result"
plugins/cscript/cspython/cs_pyth.cpp:115129: error: 'result' was not
declared in this scope
plugins/cscript/cspython/cs_pyth.cpp:115129: error: 'struct
csGraphics3DCaps' has no member named 'fog'
plugins/cscript/cspython/cs_pyth.cpp: In function `void
SWIG_init_cspace()':
plugins/cscript/cspython/cs_pyth.cpp:152837: error:
'G3DFOGMETHOD_NONE' was not declared in this scope
plugins/cscript/cspython/cs_pyth.cpp:152840: error:
'G3DFOGMETHOD_ZBUFFER' was not declared in this scope
plugins/cscript/cspython/cs_pyth.cpp:152843: error:
'G3DFOGMETHOD_VERTEX' was not declared in this scope

g++ -c -o ./out/macosxppc/optimize/plugins/cscript/cspython/
cs_pyth.o -I. -I./include -I./include -Wmost -Wno-unknown-pragmas -
pipe -I/usr/local/include -Wno-long-double -force_cpusubtype_ALL -fno-
common -fno-exceptions -fvisibility=hidden -O2 -fomit-frame-pointer -
ffast-math -fvisibility-inlines-hidden -I/sw/include/python2.3 -Wno-
long-double -DSWIG_GLOBAL -Wno-unused -Wno-uninitialized plugins/
cscript/cspython/cs_pyth.cpp

...failed C++ ./out/macosxppc/optimize/plugins/cscript/cspython/
cs_pyth.o ...

LinkPlugin cgdriver2d.csbundle
/usr/bin/ld: Undefined symbols:
_OSXDelegate2D_blitToWindow
_OSXDelegate2D_setMouseCursor
_OSXDelegate2D_setMousePosition
_OSXDelegate2D_setTitle
_OSXDelegate2D_closeWindow
_OSXDelegate2D_delete
_OSXDelegate2D_focusChanged
_OSXDelegate2D_new
_OSXDelegate2D_openWindow
collect2: ld returned 1 exit status

export MACOSX_DEPLOYMENT_TARGET=10.2
g++ -bundle -o cgdriver2d.csbundle ./out/macosxppc/optimize/
plugins/video/canvas/macosx/coregraphics/CGDriver2D.o ./out/macosxppc/
optimize/plugins/video/canvas/macosx/coregraphics/
OSXDelegate2D_CGBlit.o -lm -lmx -ldl -Wl,-multiply_defined,suppress -
L/usr/local/lib -Wl,-framework,AppKit -Wl,-framework,Foundation -
bundle ./out/macosxppc/optimize/libs/libcrystalspace_macosx.a ./out/
macosxppc/optimize/libs/libcrystalspace.a -lz -lm -lmx -ldl -Wl,-
multiply_defined,suppress -L/usr/local/lib -Wl,-framework,AppKit -Wl,-
framework,Foundation

...failed LinkPlugin cgdriver2d.csbundle ...

LinkPlugin glosx2d.csbundle
/usr/bin/ld: Undefined symbols:
(the same error message as above)

/Per Eckerdal

Post by Jeremy Bell

Do you have an ADC account? It can be the free online account. If you
do, then you should file a bug report on radar. That's the fastest way
to have someone look at it, plus you can track the bug to see when
it's been looked at, fixed, and confirmed. You may have to include a
snapshot of the source and instructions for building it. See if you
can isolate the file and the headers it depends on as much as possible
and just send those files and maybe a makeshift makefile that just
tries to build the one file rather than the entire CS sourcecode.
-Jeremy
-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_idt12&alloc_id344&op=click
_______________________________________________
Crystal-develop mailing list
https://lists.sourceforge.net/lists/listinfo/crystal-develop

Eric Sunshine

2005-05-18 17:27:46 UTC

Post by Per Eckerdal
Now I've submitted the bug report (ID 4123010).
The bug does only appear when _all_ of "-fno-exceptions -O3 -ffast-
math" is sent to the compiler, so I fixed it by lowering the
optimization level to 2 by editing COMPILER.CFLAGS.optimize in Jamconfig.

Often, though, we can work around such crashes by transforming the code
slightly while maintaining the same functionality but in a way which
pacifies the compiler. You might want to run some tests.

Post by Per Eckerdal
plugins/cscript/cspython/cs_pyth.cpp:115100: error: 'G3D_FOGMETHOD' was
not declared in this scope

This will be fixed the next time the automated job re-generates
cs_pyth.cpp. (It runs once per day.) Alternately, you could install Swig
on your machine (www.swig.org) to work around this issue. (Be sure to
re-run the CS configure script after installing Swig.)

Post by Per Eckerdal
LinkPlugin cgdriver2d.csbundle
_OSXDelegate2D_blitToWindow

Per Eckerdal

2005-05-18 19:37:46 UTC

I'm not very familiar with this.. (I did a similar thing for some
time ago when I was fixing DirectX for Dev-C++ before it
supported .lib files, but I don't remember much of that)

Here is results of the jam and nm command: (Tell me if the things I
do don't make sense, I really don't understand this problem)

$ jam
...patience...
...patience...
...patience...
...found 3366 target(s)...
...updating 2 target(s)...
LinkPlugin cgdriver2d.csbundle
/usr/bin/ld: Undefined symbols:
_OSXDelegate2D_blitToWindow
_OSXDelegate2D_setMouseCursor
_OSXDelegate2D_setMousePosition
_OSXDelegate2D_setTitle
_OSXDelegate2D_closeWindow
_OSXDelegate2D_delete
_OSXDelegate2D_focusChanged
_OSXDelegate2D_new
_OSXDelegate2D_openWindow
collect2: ld returned 1 exit status

export MACOSX_DEPLOYMENT_TARGET=10.2
g++ -bundle -o cgdriver2d.csbundle ./out/macosxppc/optimize/
plugins/video/canvas/macosx/coregraphics/CGDriver2D.o ./out/macosxppc/
optimize/plugins/video/canvas/macosx/coregraphics/
OSXDelegate2D_CGBlit.o -lm -lmx -ldl -Wl,-multiply_defined,suppress -
L/usr/local/lib -Wl,-framework,AppKit -Wl,-framework,Foundation -
bundle ./out/macosxppc/optimize/libs/libcrystalspace_macosx.a ./out/
macosxppc/optimize/libs/libcrystalspace.a -lz -lm -lmx -ldl -Wl,-
multiply_defined,suppress -L/usr/local/lib -Wl,-framework,AppKit -Wl,-
framework,Foundation

...failed LinkPlugin cgdriver2d.csbundle ...
LinkPlugin glosx2d.csbundle
/usr/bin/ld: Undefined symbols:
_OSXDelegate2D_createOpenGLContext
_OSXDelegate2D_setMouseCursor
_OSXDelegate2D_setMousePosition
_OSXDelegate2D_setTitle
_OSXDelegate2D_updateOpenGLContext
_OSXDelegate2D_closeWindow
_OSXDelegate2D_delete
_OSXDelegate2D_focusChanged
_OSXDelegate2D_new
_OSXDelegate2D_openWindow
collect2: ld returned 1 exit status

export MACOSX_DEPLOYMENT_TARGET=10.2
g++ -bundle -o glosx2d.csbundle ./out/macosxppc/optimize/plugins/
video/canvas/macosx/opengl/GLOSXDriver2D.o ./out/macosxppc/optimize/
plugins/video/canvas/macosx/opengl/OSXDelegate2D_OpenGL.o -lm -lmx -
ldl -Wl,-multiply_defined,suppress -L/usr/local/lib -Wl,-
framework,AppKit -Wl,-framework,Foundation -bundle ./out/macosxppc/
optimize/libs/libcrystalspace_opengl.a ./out/macosxppc/optimize/libs/
libcrystalspace_macosx.a ./out/macosxppc/optimize/libs/
libcrystalspace.a -framework OpenGL -lm -lz -framework OpenGL -lm -lm
-lmx -ldl -Wl,-multiply_defined,suppress -L/usr/local/lib -Wl,-
framework,AppKit -Wl,-framework,Foundation

...failed LinkPlugin glosx2d.csbundle ...
...failed updating 2 target(s)...

$ nm out/macosxppc/optimize/libs/libcrystalspace_macosx.a

out/macosxppc/optimize/libs/libcrystalspace_macosx.a(OSXDelegate2D.o):
00000494 t -[OSXDelegate2D closeWindow]
00000088 t -[OSXDelegate2D dealloc]
00000580 t -[OSXDelegate2D dispatchEvent:forView:]
000004f4 t -[OSXDelegate2D focusChanged:shouldPause:]
00000000 t -[OSXDelegate2D initWithDriver:]
000003a0 t -[OSXDelegate2D mouseEntered:]
00000424 t -[OSXDelegate2D mouseExited:]
000008b8 t -[OSXDelegate2D
openWindow:width:height:depth:fullscreen:onDisplay:onScreen:]
00000158 t -[OSXDelegate2D setMouseCursor:]
00000110 t -[OSXDelegate2D setTitle:]
000001e8 t -[OSXDelegate2D startTrackingMouse]
00000320 t -[OSXDelegate2D stopTrackingMouse]
0000068c t -[OSXDelegate2D(PrivateMethods) adjustTitle]
000005f0 t -[OSXDelegate2D(PrivateMethods) configureTitles:]
0000075c t -[OSXDelegate2D(PrivateMethods) getLastEventType]
000005d8 t -[OSXDelegate2D(PrivateMethods) getWindowStyleForMode:]
00000754 t -[OSXDelegate2D(PrivateMethods) getWindow]
000006c8 t -[OSXDelegate2D(PrivateMethods) windowDidBecomeKey:]
000006e4 t -[OSXDelegate2D(PrivateMethods) windowDidResignKey:]
00000700 t -[OSXDelegate2D(PrivateMethods) windowShouldClose:]
00000764 t -[OSXDelegate2D(PrivateMethods) windowWillResize:toSize:]
00000000 A .objc_category_name_OSXDelegate2D_PrivateMethods
U .objc_class_name_NSConstantString
U .objc_class_name_NSCursor
U .objc_class_name_NSObject
U .objc_class_name_NSScreen
U .objc_class_name_NSString
U .objc_class_name_NSWindow
00000000 A .objc_class_name_OSXDelegate2D
U .objc_class_name_OSXView
U .objc_class_name_OSXWindow
U _CGDisplayPixelsHigh
U _CGDisplayPixelsWide
U _CGShieldingWindowLevel
U _OSXDriver2D_DispatchEvent
U _OSXDriver2D_HideMouse
U _OSXDriver2D_Resize
U _OSXDriver2D_ShowMouse
U __NSConstantStringClassReference
U _objc_msgSend
U _objc_msgSendSuper
U _objc_msgSend_stret
U dyld_stub_binding_helper

out/macosxppc/optimize/libs/libcrystalspace_macosx.a(OSXDriver2D.o):
U _CFDictionaryGetValue
U _CFNumberGetValue
U _CGDisplayBestModeForParameters
U _CGDisplayCapture
U _CGDisplayCurrentMode
U _CGDisplayRelease
U _CGDisplaySwitchToMode
U _CGGetActiveDisplayList
U _CGGetDisplayTransferByTable
U _CGMainDisplayID
U _CGSetDisplayTransferByTable
U _OSXDelegate2D_closeWindow
U _OSXDelegate2D_delete
U _OSXDelegate2D_focusChanged
U _OSXDelegate2D_new
U _OSXDelegate2D_openWindow
000009d8 T _OSXDriver2D_DispatchEvent
000009fc T _OSXDriver2D_HideMouse
000009ec T _OSXDriver2D_Resize
00000a0c T _OSXDriver2D_ShowMouse
U __Z13csStrNCaseCmpPKcS0_m
U __Z8csPrintfPKcz
U __Z9csFPrintfP7__sFILEPKcz
U __Z9csPrintfVPKcPc
000026b0 S __ZN10csArrayCmpIPP5iBaseS2_E14DefaultCompareERKS2_S5_
00001704 T __ZN11OSXDriver2D10InitializeEP15iObjectRegistry
00000b80 T __ZN11OSXDriver2D11HandleEventER6iEvent
00000fd8 T __ZN11OSXDriver2D12EventHandler11AddRefOwnerEPP5iBase
00000010 T __ZN11OSXDriver2D12EventHandler11GetRefCountEv
0000269c S __ZN11OSXDriver2D12EventHandler11HandleEventER6iEvent
00000018 T __ZN11OSXDriver2D12EventHandler14QueryInterfaceEmi
00000cb8 T __ZN11OSXDriver2D12EventHandler14RemoveRefOwnerEPP5iBase
00000a1c T __ZN11OSXDriver2D12EventHandler18scfRemoveRefOwnersEv
00000af8 T __ZN11OSXDriver2D12EventHandler6DecRefEv
00000000 T __ZN11OSXDriver2D12EventHandler6IncRefEv
000026dc S __ZN11OSXDriver2D12EventHandlerD0Ev
00002724 S __ZN11OSXDriver2D12EventHandlerD1Ev
000018ec T __ZN11OSXDriver2D12Initialize16Ev
00000104 T __ZN11OSXDriver2D12Initialize32Ev
00000df0 T __ZN11OSXDriver2D13ChooseDisplayEv
0000038c T
__ZN11OSXDriver2D16FadeToGammaTableEP18_CGDirectDisplayID10GammaTable
0000087c T __ZN11OSXDriver2D16ToggleFullscreenEv
000005f4 T __ZN11OSXDriver2D18ExitFullscreenModeEv
000006fc T __ZN11OSXDriver2D19EnterFullscreenModeEv
00001b6c T __ZN11OSXDriver2D4OpenEv
000006b0 T __ZN11OSXDriver2D5CloseEv
00000548 T __ZN11OSXDriver2D9FadeToRGBEP18_CGDirectDisplayIDfff
00000c90 T __ZN11OSXDriver2D9HideMouseEv
00000974 T
__ZN11OSXDriver2D9SaveGammaEP18_CGDirectDisplayIDR10GammaTable
00000ca4 T __ZN11OSXDriver2D9ShowMouseEv
00001270 T __ZN11OSXDriver2DC1EP12csGraphics2D
00001200 T __ZN11OSXDriver2DC2EP12csGraphics2D
000015b0 T __ZN11OSXDriver2DD0Ev
00001448 T __ZN11OSXDriver2DD1Ev
000012e0 T __ZN11OSXDriver2DD2Ev
00002558 S __ZN12scfInterfaceI11iEventQueueE5GetIDEv
00002630 S __ZN12scfInterfaceI13iOSXAssistantE5GetIDEv
000024ec S __ZN12scfInterfaceI18iCommandLineParserE5GetIDEv
000025c4 S __ZN12scfInterfaceI9iReporterE5GetIDEv
U __ZN14csConfigAccessC1EP15iObjectRegistryPKcbi
U __ZN14csConfigAccessD1Ev
U __ZN14csConfigAccessptEv
U __ZN16csKeyEventHelper10GetRawCodeEPK6iEvent
U __ZN16csKeyEventHelper12GetEventTypeEPK6iEvent
U __ZN16csKeyEventHelper16GetModifiersBitsEPK6iEvent
00002774 S __ZN16csReporterHelper6ReportEP15iObjectRegistryiPKcS3_z
U __ZN4iSCF3SCFE
00002748 S
__ZN7csArrayIPP5iBase21csArrayElementHandlerIS2_E22csArrayMemoryAllocato
rIS2_EE14DefaultCompareERKS2_S9_
00002140 S __ZTI11OSXDriver2D
0000212c S __ZTI13iEventHandler
00002138 S __ZTI5iBase
00002120 S __ZTIN11OSXDriver2D12EventHandlerE
000021c8 S __ZTS11OSXDriver2D
00002198 S __ZTS13iEventHandler
00002190 S __ZTS5iBase
000021a8 S __ZTSN11OSXDriver2D12EventHandlerE
00002208 S __ZTV11OSXDriver2D
00002148 S __ZTV13iEventHandler
00002170 S __ZTV5iBase
U __ZTVN10__cxxabiv117__class_type_infoE
U __ZTVN10__cxxabiv120__si_class_type_infoE
000021d8 S __ZTVN11OSXDriver2D12EventHandlerE
00002950 d
__ZZN11OSXDriver2D12EventHandler14QueryInterfaceEmiE19iEventHandler_scfI
D
00002954 s
__ZZN11OSXDriver2D16FadeToGammaTableEP18_CGDirectDisplayID10GammaTableE1
0TOTAL_USEC
00002240 S __ZZN12scfInterfaceI11iEventQueueE5GetIDEvE2ID
00002248 S __ZZN12scfInterfaceI13iOSXAssistantE5GetIDEvE2ID
0000223c S __ZZN12scfInterfaceI18iCommandLineParserE5GetIDEvE2ID
00002244 S __ZZN12scfInterfaceI9iReporterE5GetIDEvE2ID
U __ZdlPv
U __Znwm
U ___CFStringMakeConstantString
U ___cxa_pure_virtual
U ___sF
U _atoi
U _free
U _gettimeofday
U _malloc
U _memcpy
U _memmove
U _realloc
U dyld_stub_binding_helper
U restFP
U saveFP

out/macosxppc/optimize/libs/libcrystalspace_macosx.a(OSXView.o):
0000012c t -[OSXView acceptsFirstResponder]
00000070 t -[OSXView dealloc]
0000017c t -[OSXView flagsChanged:]
00000000 t -[OSXView initWithFrame:]
00000134 t -[OSXView keyDown:]
00000158 t -[OSXView keyUp:]
000001c4 t -[OSXView mouseDown:]
0000020c t -[OSXView mouseDragged:]
000001a0 t -[OSXView mouseMoved:]
000001e8 t -[OSXView mouseUp:]
0000029c t -[OSXView otherMouseDown:]
000002e4 t -[OSXView otherMouseDragged:]
000002c0 t -[OSXView otherMouseUp:]
00000230 t -[OSXView rightMouseDown:]
00000278 t -[OSXView rightMouseDragged:]
00000254 t -[OSXView rightMouseUp:]
000000d4 t -[OSXView setDelegate:]
U .objc_class_name_NSView
00000000 A .objc_class_name_OSXView
U _objc_msgSend
U _objc_msgSendSuper
U dyld_stub_binding_helper

out/macosxppc/optimize/libs/libcrystalspace_macosx.a(OSXWindow.o):
00000000 t -[OSXWindow canBecomeKeyWindow]
U .objc_class_name_NSWindow
00000000 A .objc_class_name_OSXWindow

If it helps: I don't have any OSXDelegate2D.cpp (not what I can
find), only OSXDelegate2D.m

Post by Per Eckerdal
Now I've submitted the bug report (ID 4123010).
The bug does only appear when _all_ of "-fno-exceptions -O3 -
ffast- math" is sent to the compiler, so I fixed it by lowering
the optimization level to 2 by editing COMPILER.CFLAGS.optimize
in Jamconfig.

Often, though, we can work around such crashes by transforming the
code slightly while maintaining the same functionality but in a way
which pacifies the compiler. You might want to run some tests.

Post by Per Eckerdal
However, I encountered some more problems. Here are the error
'G3D_FOGMETHOD' was not declared in this scope

This will be fixed the next time the automated job re-generates
cs_pyth.cpp. (It runs once per day.) Alternately, you could install
Swig on your machine (www.swig.org) to work around this issue. (Be
sure to re-run the CS configure script after installing Swig.)

Post by Per Eckerdal
LinkPlugin cgdriver2d.csbundle
_OSXDelegate2D_blitToWindow

Somehing strange is going on. The OSXDelegate2D.cpp source does get
compiled, but it seems to be missing symbols, or it is not present
in libcrystalspace_macosx.a for some reason. Try listing the
contents of the generated ./out/macosxppc/optimize/libs/
libcrystalspace_macosx.a to see if the OSXDelegate2D.o object is
present. If it is, extract it and use 'nm' to find out if those
symbols are present in the object file.
-- ES
-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
_______________________________________________
Crystal-develop mailing list
https://lists.sourceforge.net/lists/listinfo/crystal-develop

Eric Sunshine

2005-05-18 20:44:41 UTC

Post by Per Eckerdal
_OSXDelegate2D_blitToWindow
_OSXDelegate2D_setMouseCursor
_OSXDelegate2D_setMousePosition
_OSXDelegate2D_setTitle
_OSXDelegate2D_closeWindow
_OSXDelegate2D_delete
_OSXDelegate2D_focusChanged
_OSXDelegate2D_new
_OSXDelegate2D_openWindow

Perhaps there is a problem with the __private_extern__ usage in
CS/include/csplugincommon/macosx/OSXDelegate2D.h. Try removing
__private_extern__ entirely from that file and rebuild.

Post by Per Eckerdal
If it helps: I don't have any OSXDelegate2D.cpp (not what I can find),
only OSXDelegate2D.m

That's what I meant.

-- ES

Andreas Grosam

2005-05-19 00:34:24 UTC

Perhaps there is a problem with the __private_extern__ usage in
CS/include/csplugincommon/macosx/OSXDelegate2D.h. Try removing
__private_extern__ entirely from that file and rebuild.

Post by Per Eckerdal
If it helps: I don't have any OSXDelegate2D.cpp (not what I can
find), only OSXDelegate2D.m

That's what I meant.

Hint:
Regarding visibility of symbols, there are new cool possibilities for
GCC 4.x - which in particular ease the process of exporting symbols for
shared libraries - or making it possible to omit an exported-symbols
list. Please take a look at:
<http://developer.apple.com/documentation/DeveloperTools/Conceptual/
CppRuntimeEnv/Articles/SymbolVisibility.html>

notice: only for >=gcc-4.0

Post by Eric Sunshine
-- ES
-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
_______________________________________________
Crystal-develop mailing list
https://lists.sourceforge.net/lists/listinfo/crystal-develop

Eric Sunshine

2005-05-19 01:57:12 UTC

Post by Per Eckerdal
_OSXDelegate2D_blitToWindow
_OSXDelegate2D_setMouseCursor

Perhaps there is a problem with the __private_extern__ usage in
CS/include/csplugincommon/macosx/OSXDelegate2D.h. Try removing
__private_extern__ entirely from that file and rebuild.

Regarding visibility of symbols, there are new cool possibilities for
GCC 4.x - which in particular ease the process of exporting symbols for
shared libraries - or making it possible to omit an exported-symbols
<http://developer.apple.com/documentation/DeveloperTools/Conceptual/
CppRuntimeEnv/Articles/SymbolVisibility.html>

CS recently started using `-fvisibility=hidden'. Do we work around this
issue by replacing __private_extern__ with a normal `extern', or with
__attribute__((visibility("default")))?

-- ES

Andreas Grosam

2005-05-19 22:18:15 UTC

Post by Per Eckerdal
_OSXDelegate2D_blitToWindow
_OSXDelegate2D_setMouseCursor

Perhaps there is a problem with the __private_extern__ usage in
CS/include/csplugincommon/macosx/OSXDelegate2D.h. Try removing
__private_extern__ entirely from that file and rebuild.

Regarding visibility of symbols, there are new cool possibilities for
GCC 4.x - which in particular ease the process of exporting symbols
for shared libraries - or making it possible to omit an
<http://developer.apple.com/documentation/DeveloperTools/Conceptual/
CppRuntimeEnv/Articles/SymbolVisibility.html>

CS recently started using `-fvisibility=hidden'. Do we work around
this issue by replacing __private_extern__ with a normal `extern', or
with __attribute__((visibility("default")))?

Yes, this new feature is just too appealing, in order not to use it ;-)
I would say, get rid of all __private_extern__ and use the new
visibility feature.

CS would especially benefit from this concept because CS uses a lot of
shared libraries and plugins: less footprint, faster code.

I would like to propose the following (comments appreciated :-)
CAUTION: lengthy!):

In order to maintain compatibility with sources not yet
"visibility-feature" enabled, i would suggest to use a global configure
option (--enable-gcc-visibility-feature). This means, if this feature
is supported by the compiler and if the option is disabled, the class
visibility feature will not be used. If it is enabled, it assumes that
libraries are "visibility-feature" enabled, if not stated ortherwise
somewhere in a make script for an individual library.
The default value should be disabled.

I would like to point you to these links. There it will be discussed in
greater detail, very helpful!
<http://www.nedprod.com/programs/gccvisibility.html>
<http://people.redhat.com/drepper/dsohowto.pdf>
and
<http://gnu.xdanger.com/software/gcc/gcc-4.0/changes.html>

For CS, (most likely) all shared libs (plugins) require changes in the
sources (mainly in the headers) in order to become "visibility-feature"
enabled.

"visibility-feature" enabled libraries means, that they have
"class-visibilty-specs" added to their symbols, and that the compiler
uses certain options when building this library. Since the headers of
the lib will be changed, this also affects the clients including the
headers in order to import the interfaces.

"visibility-feature" enabled libraries shall be backward compatible,
means even when they are "enabled", they need still compile and link
with the clients seamlessly, when the new visibility feature is not
used - e.g. when using a gcc-3.x compiler.

It is also required that "visibility-feature" enabled libraries and old
libraries can be arbitrarily mixed when building an application.

It is easy to make changes, to get a "visibility-feature" enabled
library. But for the build system it is a bit more effort required, in
order to link with the new and the old libraries:

If we would enable it globally through a configure option, it would
cause to break non visibility-feature enabled libraries - means it
would cause that no symbols will be exported for this library.
On the other hand, if we would disable it globally, we wouldn´t benefit
from already visibility-feature enabled libraries.

Well, here my suggestion, how to accomplish this:

When the build system builds a shared library or a plugin, it does not
have a clue whether the programmer took care to make it
"visibility-feature" enabled. Thus, when compiling a library it must be
specified elsewhere (e.g. make files). When the library will be build
with this feature enabled, the configure script adds a definition of a
macro which is named
CS_BUILD_VISIBILITY_FEATURE_ENABLED_xxx
in the associated config.h file of the library, where xxx is a
placeholder of the name of the library. The name needs to be unique for
each library.

Once this macro has been added, the symbols for the library will be
propperly tagged with the visibility-specs, either when building the
library or when the haeader will be used for inclusion in other
headers. (this actually makes a difference only on other compilers than
gcc)

The goal is to propperly define the required "visibility specs" as two
macros, which will be used in the headers for the libraries:
CS_API symbols are public, reachable from outside the DSO
CS_API_LOCAL symbols are only reachable from within in the DSO

Note, a dynamic shared object (DSO) is a set of object files, e.g. a
shared dynamic library, a plug-in, etc.

The conditionals in the headers of "visibility-feature" enabled
libraries, need to work compatible for the case when
"visibility-feature" is *effectively* disabled, for instance when the
configure option is disabled or when the compiler simply does not
support it.

Example usage of the visibility macros:

int CS_API foo_public(); // public accessable free function

struct CS_API SFooPublic {}; // public accessable struct

struct CS_API_LOCAL SFooLocal {}; // accessable only withn the DSO

class CS_API MyClassPublic // public class and members ...
{
public:
MyClassPublic();

int foo_public();

private:
int CS_API_LOCAL foo_private(); // ... excpet this functio: only
reachable from within the DSO

SFooLocal x;
};

Each header of a library needs to included the following macros to
define the visibility specs. Note that unique names need to be used for
each library. A handy macro might ease the usage.
For gcc and the fictive library "foo" this might be coded like this:

#include "config.h"

#if defined (__GNUC__)
#if not defined (CS_BUILD_STATIC_foo)
/* building as shared lib */

#ifdef CS_BUILD_VISIBILITY_FEATURE_ENABLED_foo /* in config.h */
#define CS_API __attribute__ ((visibility("default")))
#define CS_API_LOCAL __attribute__ ((visibility("hidden")))
#else /* visibility feature not enabled */
#define CS_API
#define CS_API_LOCAL
#endif

#else
/* building as static lib */

#define CS_API
#define CS_API_LOCAL

#endif
#endif

The configure script generating the make commands should work like
this, configure-gcc:
if (building foo as shared library)
if visibility-feature is enabled and supported
config-header = open("config.h")
config-header << "#define CS_BUILD_VISIBILITY_FEATURE_ENABLED_foo"
make: c_flags += -fvisibility=hidden
make: c_flags += -fvisibility-inlines-hidden
else
/*nothing*/
else if (building foo as static library)
make: define CS_BUILD_STATIC_foo
end

=====================================================================
Example for MSC compiler:

#include "config.h"

#ifdef _MSC_VER
#if not defined (CS_BUILD_STATIC_foo)
#define CS_API_LOCAL
#ifdef CS_BUILDING_DLL_foo
#define CS_API __declspec(dllexport)
#else
#define CS_API __declspec(dllimport)
#endif
#else
#define CS_API
#endif
#endif

configure-MSC:
if (building foo as shared library)
make: define CS_BUILDING_DLL_foo
else if (building foo as static library)
make: define CS_BUILD_STATIC_foo
end

=====================================================================

The mentioned links above, show how to accomplish this for building a
single library but it does not maintain backward compatibility.

The info whether or not a library is "visibility-feature" enabled, can
be stored as a macro in a config.h associated to the lib, which will be
created during building the library.

Regards
Andreas

res

2005-05-19 23:59:57 UTC

Post by Andreas Grosam
I would say, get rid of all __private_extern__ and use the new

You wouldn't entirely, __private_extern__ is prolly needed of older gccs.
I think what you described is essentially already done for CS.

Post by Andreas Grosam
In order to maintain compatibility with sources not yet
"visibility-feature" enabled, i would suggest to use a global configure
option (--enable-gcc-visibility-feature). This means, if this feature is
supported by the compiler and if the option is disabled, the class
visibility feature will not be used.

CS' configure already detects the visibility options. They can't be disabled,
tho - but that isn't actually needed for backward compatibility, see below.

Post by Andreas Grosam
The goal is to propperly define the required "visibility specs" as two
CS_API symbols are public, reachable from outside the DSO

The CS public headers where outfitted which suchalike macro when the initial
shared library stuff was added (all those CS_SOMETHING_EXTERN macros...).

Post by Andreas Grosam
CS_API_LOCAL symbols are only reachable from within in the DSO

Such a macro could be added. (I didn't bother to when I first added gcc
visibility support mostly b/c I was/am too lazy ;)

Post by Andreas Grosam
The info whether or not a library is "visibility-feature" enabled, can
be stored as a macro in a config.h associated to the lib, which will be
created during building the library.

I don't think that information needs to be exposed to the outside at all. The
visibility stuff should really only matter during build time. Beyond that, a
symbol was either exported or not, doesn't matter what is in the headers then.
(OTOH, on Windows you need to somehow expose whether you built a DLL or not, so
dllexport can be invoked).

-f.r.

Andreas Grosam

2005-05-20 21:49:31 UTC

Post by Andreas Grosam
I would say, get rid of all __private_extern__ and use the new

You wouldn't entirely, __private_extern__ is prolly needed of older gccs.

A macro would be helpful in order to make it backward compatible, it
would either expand to __private_extern__ or the new visibility
attributes. It can be used only for free functions and variables,
though.

Post by Andreas Grosam
I would like to propose the following (comments appreciated :-)

I think what you described is essentially already done for CS.

fine!

Post by Andreas Grosam
In order to maintain compatibility with sources not yet
"visibility-feature" enabled, i would suggest to use a global
configure option (--enable-gcc-visibility-feature). This means, if
this feature is supported by the compiler and if the option is
disabled, the class visibility feature will not be used.

CS' configure already detects the visibility options. They can't be
disabled, tho - but that isn't actually needed for backward
compatibility, see below.

Does that mean, when the configure script detects a gcc4 compiler it
unconditionally emits the following C-flags for compiling all sources,
-fvisibility=hidden and -fvisibility-inlines-hidden?
And furthermore assumes, all CS-SDK sources have its propper visibility
specs?

Post by Andreas Grosam
The goal is to propperly define the required "visibility specs" as
CS_API symbols are public, reachable from outside the DSO

The CS public headers where outfitted which suchalike macro when the
initial shared library stuff was added (all those CS_SOMETHING_EXTERN
macros...).

Yes, but IMO there is room for improvments, leading to a smaller binary
and faster code. But this can be done step by step.

For instance, class members with private access specifier, could
possibly be declared hidden (private_extern).

Example:
class CS_CRYSTALSPACE_EXPORT csBSPTree
{
private:
size_t CS_API_LOCAL FindBestSplitter(); // reachable only from within
the DSO
void CS_API_LOCAL Build(); // dito
void CS_API_LOCAL Back2Front(); // dito

public:
csBSPTree (); // exported, since class is exported
int foo(); // dito
...
};

Post by Andreas Grosam
CS_API_LOCAL symbols are only reachable from within in the DSO

Such a macro could be added. (I didn't bother to when I first added
gcc visibility support mostly b/c I was/am too lazy ;)

The benefit of fine grained visibility specification comes with this
macro and it becomes more important in the future, with more complex
interfaces and when it is applied on templates:

A pretty hypothetical example:

class CS_API MyClass {
private:

template <typename U>
class CS_API_LOCAL MyExampleLocal: public MorePrivateSymbols<U> {
/* lots of symbols, which need not and will not be exported */
};

public:
/* a few exported members */
};

Only members of MyClass can access the member template class, thus
instantiating code. All template instantiations of class MyExampleLocal
are only reachable from within the DSO where the members of class
MyClass are defined, and will not be exported.
A cleaner approach might avoid to mention the member template class
(pimpl idiom) at the cost of runtime.

In this example above, the local template class is only an
implementation detail, and relatively easy to solve.
Exporting a template classes requires a bit more attention and might
become somewhat tricky.
A CS_API_LOCAL macro would be very useful for these cases, though.

Post by Andreas Grosam
The info whether or not a library is "visibility-feature" enabled,
can be stored as a macro in a config.h associated to the lib, which
will be created during building the library.

I don't think that information needs to be exposed to the outside at
all. The visibility stuff should really only matter during build time.
Beyond that, a symbol was either exported or not, doesn't matter what
is in the headers then. (OTOH, on Windows you need to somehow expose
whether you built a DLL or not, so dllexport can be invoked).

You are right!
A visibility spec does not have any effect on the reachability of
symbols when importing.

Andreas

Post by res
-f.r.

Eric Sunshine

2005-05-21 00:16:27 UTC

Post by res
You wouldn't entirely, __private_extern__ is prolly needed of older gccs.

We could also just remove __private_extern__ altogether. It would not be
tremendously devastating if those few functions happened get exported
beyond the library (they won't cause any naming conflicts, for instance).

Anyhow, back to the original question, should these be declared as
"extern" or as "__attribute__((hidden("default")))" for gcc4, or do we
need any qualifier at all?

Post by res
CS' configure already detects the visibility options. They can't be
disabled, tho - but that isn't actually needed for backward
compatibility, see below.

Does that mean, when the configure script detects a gcc4 compiler it
unconditionally emits the following C-flags for compiling all sources,
-fvisibility=hidden and -fvisibility-inlines-hidden?

It checks if the compiler has these features and utilizes them if
available (it doesn't specifically check the compiler version).

Post by Andreas Grosam
And furthermore assumes, all CS-SDK sources have its propper visibility
specs?

That is the assumption. The CS headers have been pretty well audited.
The public API is marked as such with appropriate qualifier(s).

-- ES

Andreas Grosam

2005-05-21 10:29:19 UTC

Post by res
You wouldn't entirely, __private_extern__ is prolly needed of older gccs.

We could also just remove __private_extern__ altogether. It would not
be tremendously devastating if those few functions happened get
exported beyond the library (they won't cause any naming conflicts,
for instance).
Anyhow, back to the original question, should these be declared as
"extern" or as "__attribute__((hidden("default")))" for gcc4, or do we
need any qualifier at all?

for gcc4, the equivalent for __private_extern__ is "__attribute__
((visibility("hidden")))".

The visibility should be set *explicitly*, even when symbols wouldn't
be exported by default:

When the visibility feature is present, the compiler should compile
with flags
-fvisibilty=hidden and -fvisibility-inlines-hidden, which causes no
symbols to be reachable from outside the DSO, if not otherwise
overriden.

However, there are new pragmas which can be used to set the visibility
for a whole range of names in the sources, which do override the
compiler options. Thus, if a __private_extern__ has been used,
"__attribute__ ((visibility("hidden")))" shall be used.

#pragma GCC visibility push(default)

void pub_foo();
void pub_bar();

__attribute__((visibility("hidden"))) void local_foo();

#pragma GCC visibility pop

Andreas

Post by res
CS' configure already detects the visibility options. They can't be
disabled, tho - but that isn't actually needed for backward
compatibility, see below.

Does that mean, when the configure script detects a gcc4 compiler it
unconditionally emits the following C-flags for compiling all
sources, -fvisibility=hidden and -fvisibility-inlines-hidden?

It checks if the compiler has these features and utilizes them if
available (it doesn't specifically check the compiler version).

Post by Andreas Grosam
And furthermore assumes, all CS-SDK sources have its propper
visibility specs?

That is the assumption. The CS headers have been pretty well audited.
The public API is marked as such with appropriate qualifier(s).
-- ES
-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
_______________________________________________
Crystal-develop mailing list
https://lists.sourceforge.net/lists/listinfo/crystal-develop

Eric Sunshine

2005-05-22 04:24:37 UTC

Post by Andreas Grosam
for gcc4, the equivalent for __private_extern__ is "__attribute__
((visibility("hidden")))".

Has this been tested for our case? Does it resolve the problem on
Tiger of the symbols being reported as unresolved?

-- ES

Andreas Grosam

2005-05-22 10:41:32 UTC

Post by Andreas Grosam
for gcc4, the equivalent for __private_extern__ is "__attribute__
((visibility("hidden")))".

Has this been tested for our case? Does it resolve the problem on
Tiger of the symbols being reported as unresolved?

Sorry, i can't test it yet myself, Per might do so. (I could test with
FSF gcc4 on Mac OS X - not sure what exactly is the diff, though.)

I would like to cite some part of the Apple docs regarding:

Symbol Visibility and Objective-C

Objective-C is a strict superset of C, and Objective-C++ is a strict
superset of C++. This means that all of the discussion regarding symbol
visibility in C and C++ applies to Objective-C and Objective-C++ too.
You can use the compiler flags, visibility attributes, and the
visibility pragma to hide C and C++ code in your Objective-C code
files. However, these visibility controls apply only to the C or C++
subset of your code. They do not apply to Objective-C classes and
methods.

Objective-C class and message names are bound by the Objective-C
runtime, not by the linker, so the notion of visibility does not apply
to them. There is no mechanism for hiding an Objective-C class defined
in a dynamic library from the clients of that library.

Post by Eric Sunshine
-- ES
-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_idt12&alloc_id344&op=click
_______________________________________________
Crystal-develop mailing list
https://lists.sourceforge.net/lists/listinfo/crystal-develop

Eric Sunshine

2005-05-22 18:33:04 UTC

Post by Eric Sunshine
Has this been tested for our case? Does it resolve the problem on
Tiger of the symbols being reported as unresolved?

Sorry, i can't test it yet myself, Per might do so. (I could test with
FSF gcc4 on Mac OS X - not sure what exactly is the diff, though.)

The reason I ask is because I don't understand the behavior we are seeing.
Thanks. I read the full document when you first cited it. Unfortunately,
I didn't find that it was entirely clear about some things, such as
explaining why we were seeing those errors about unresolved symbols, or
how we should resolve the issue properly. For instance, it didn't
explain the interaction of -fvisibility=hidden with __private_extern__.
Anyhow, since we are using -fvisibility=hidden and experiencing link
errors about unresolved symbols, I don't understand why we would want to
use __attribute__((visibility("hidden")) to resolve the problem.

-- ES

Andreas Grosam

2005-05-23 10:41:25 UTC

Post by Eric Sunshine
Has this been tested for our case? Does it resolve the problem on
Tiger of the symbols being reported as unresolved?

Sorry, i can't test it yet myself, Per might do so. (I could test
with FSF gcc4 on Mac OS X - not sure what exactly is the diff,
though.)

The reason I ask is because I don't understand the behavior we are seeing.

OK, i got gcc-dp-4.0, via DarwinPorts and installed it. Was painless,
on my 10.3.9.
I added CXX=/opt/local/bin/g++-dp-4.0 and CC=/opt/local/bin/g++-dp-4.0
to my environment, and started.

I ran configure with these options:
--prefix=$HOME/Develop/CrystalSpace/dest-test --enable-debug
--with-cal3d=$HOME/Develop/Cal3D/Install
Configure passed, and also got this what was expected:
checking if -fvisibility-inlines-hidden is accepted...
-fvisibility-inlines-hidden
checking if -fvisibility=hidden is accepted... yes
checking if GCC supports visibility attribute... yes

Well, when looking at the compiler output, two things are suspect:

1) the visibility flags are not set. This means, visibility is
"default", means all symbols will be exported by default. This is
probably a configure issue, don't think this is because of a debug
build.
Example output:
/opt/local/bin/g++-dp-4.0 -c -o
./out/macosxppc/debug/libs/csutil/ansiparse.o -I../CS/. -I./include
-I../CS/./include -Wall -Wno-unknown-pragmas -pipe -I/usr/local/include
-force_cpusubtype_ALL -fno-common -fno-exceptions -g3 -DCS_DEBUG
-DCS_CRYSTALSPACE_LIB
-DCS_CONFIGDIR='"/Users/agrosam/Develop/CrystalSpace/dest-test/etc/
crystalspace"'
-DCS_PLUGINDIR='"/Users/agrosam/Develop/CrystalSpace/dest-test/lib/
crystalspace"' ../CS/libs/csutil/ansiparse.cpp

2) There are lot of warnings in the form:
../CS/./include/csutil/scf.h:78: warning: 'struct iBase' has virtual
functions but non-virtual destructor

This is certainly a reasonable warning. An interface class shall have a
virtual destructor!

Otherwise, this code does not work:
iBase* p = new DerivedBase();
delete p; // surprise!

Yeah, i heard of a problem which had been there, but i can't imaging
that removing the virtual d-tor does fix a problem. I suspect other
reasons for that problem: please, try to get rid of *all* implicit
pointer casts and use static_cast<T>. Then you might get compiler
errors which might reveal the problem.

Well after adding the -fvisibility=hidden -fvisibility-inlines-hidden
options, i compiled everything again.

Please notice, that i compiled with "gcc-dp", which is essentially, a
fsf-GCC4 compiled on Mac OS X.
I got these issues:
1) fsf-GCC4 does not have Objective-C++. Due to this, it fails to
compile *.mm sources.
2) it does not recognize __private_extern__

Unfortunately, i can not proceed with testing, due to this errors.

Well, it would be nice when CS would also compile on Mac OS X, with the
DarwinPorts and FSF GCC4 compiler. AFAIK, we could figure out whether
we have a FSF or an Apple version, through checking either the version
string reported with g++ --version or through checking the built-in
define __VERSION__.
e.g.
$ touch foo.h
$ g++ -E -dM foo.h

this prints out a list of all the defined macros, including the
built-ins.

For FSF gcc4, __VERSION__ equals "4.0.0"

for Apple, it is "3.3 20030304 (Apple Computer, Inc. build 1671)"

Both define __APPLE__, so this does not help.

If possible, i would prefere to use conditional macros, to check at
compile time if we have an Apple or a FSF version, instead using a
configure script. But checking __private_extern__ would also be a good
idea.

General:
--------

Anyway,
in order to benefit from the new visibility feature, within the public
headers we need to explicitly specify the visibility of symbols with
macros, e.g.:
CS_API_LOCAL int func_local();
CS_API_EXPORT int func_public();

By means of the config script or at compile time, we need to
appropriately expand the CS_API_LOCAL macro to either
__attribute__ ((visibility("hidden")))
__private_extern__
or void

in that order, if it is supported by the compiler.

Such a macro CS_API_LOCAL does not yet exist.

Well, i'm pretty sure that it is possible to successfully compile CS on
Mac OS X with any combination of FSF or Apple compiler and the version
gcc3 or gcc4.
A further usefull config option would be to optionally install on a
pure darwin (without using Cocoa or Carbon frameworks). Note that -
AFAIK - bundles should work on a pure darwin, too (there are a few
frameworks installed with pure darwin).

And a side note: if you like the concept of bundles to be useful on
other platforms:
There is the portable CoreFoundation Light, framework which includes
the bundle stuff and which is portable at least to x86 systems. It also
contains the CFString classes.

Well, while i'm writing this message, i'm going to install Apple GCC4.
Not sure if this compiler is running on my 10.3.9. But, we see it
later. ;-)
(don't want to install Tiger, yet for the sake testing CS on 10.3. I
also suspect some issues when runnig on 10.2 -- but later...).

Regards
Andreas

Post by Eric Sunshine
Thanks. I read the full document when you first cited it.
Unfortunately, I didn't find that it was entirely clear about some
things, such as explaining why we were seeing those errors about
unresolved symbols, or how we should resolve the issue properly. For
instance, it didn't explain the interaction of -fvisibility=hidden
with __private_extern__. Anyhow, since we are using
-fvisibility=hidden and experiencing link errors about unresolved
symbols, I don't understand why we would want to use
__attribute__((visibility("hidden")) to resolve the problem.
-- ES
-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
_______________________________________________
Crystal-develop mailing list
https://lists.sourceforge.net/lists/listinfo/crystal-develop

res

2005-05-23 11:10:50 UTC

Post by Andreas Grosam
1) the visibility flags are not set. This means, visibility is
"default", means all symbols will be exported by default.

The flags are emitted when compiling CS in optimize mode. The idea is that the
extra symbols emitted might be useful for debugging ... I'm not 100% certain,
though.

Post by Andreas Grosam
../CS/./include/csutil/scf.h:78: warning: 'struct iBase' has virtual
functions but non-virtual destructor
This is certainly a reasonable warning. An interface class shall have a
virtual destructor!

Not at all. Interfaces should be completely virtual abstract - a destructor
would break that "no implementations in interfaces" paradigma. Also, it
contradicts reference counting, see below.

Post by Andreas Grosam
iBase* p = new DerivedBase();
delete p; // surprise!

It isn't supposed to work. iBase is the base for all interface and provides the
reference counting interface. A class is supposed to be destroyed once all
references to interfaces of it are not used any more; if you could write code
like above, you could wreak havoc by destroying classes why still in use (at
least its more difficult).

-f.r.

Andreas Grosam

2005-05-23 21:16:25 UTC

Post by Andreas Grosam
1) the visibility flags are not set. This means, visibility is
"default", means all symbols will be exported by default.

The flags are emitted when compiling CS in optimize mode. The idea is
that the extra symbols emitted might be useful for debugging ... I'm
not 100% certain, though.

I think, we have debug symbols for that and they are independend on the
exported symbols.
Wouldn't it be better to get link errors early when linking the
debug-target - rather when eventually doing a final build?

Not at all.
Interfaces should be completely virtual abstract - a destructor would
break that "no implementations in interfaces" paradigma.

Why do we need that?
I just ask, because there are other modern designs for implementing
interfaces, and it depends how you implement your approach :-)

In the case of this "classic" aproach of interface design, IMO, an
abstract base class of an interface should look like this:

class Interface {
protected:
virtual ~Interface() = 0;

private:
Interface(const Interface& rhs); // declared, but not
defined Interface& operator=(const Interface& rhs); // declared, but
not defined
};

These are just common guide-lines:
1) in general, the d-tor of a base class should be virtual if it is
accessable, otherwise you MUST ensure that derived objects will never
be destroyed polymorphical.
2) the c-tor needs to be pure only if there are no other pure virtual
members in that class
3) a pure virtual c-tor must be defined! e.g.:
Interface:~Interface() {}

Post by res
Also, it contradicts reference counting, see below.

Post by Andreas Grosam
iBase* p = new DerivedBase();
delete p; // surprise!

It isn't supposed to work.

Then it must not compile.

Post by res
iBase is the base for all interface and provides the reference
counting interface.

Yes, and if i'm a clueless thrillseeker, i can do things like this:
while (p->foo())
p->DecRef();

which bombs very quickly :-)

Post by res
A class is supposed to be destroyed once all references to interfaces
of it are not used any more;

then, it's implementation should ensure that.
p->IncRef(); // ??

Post by res
if you could write code like above, you could wreak havoc by
destroying classes why still in use (at least its more difficult).

Actually, it's too easy to do something disastrous - inadvertantly, of
course.

DecRef() has about 200 occurences, IncRef() about 50 in CS Sources. So,
it seems, it is common practice to use this functions to tweak
something.

Hope, you get the my point. ;-)

Well, the smart-pointer topic is beyond the scope of this thread - but
i really would like to discuss this later because there are
possibilities for improvments.

I'm still struggling with Apple-GCC4 on 10.3.9, but o think i can
manage it ... it's bootstrapping.
Hopefully, i can soon to proceed to look at the linker errors ...

Regards
Andreas

Post by res
-f.r.

Andreas Grosam

2005-05-25 10:17:06 UTC

Post by Andreas Grosam
for gcc4, the equivalent for __private_extern__ is "__attribute__
((visibility("hidden")))".

Has this been tested for our case? Does it resolve the problem on
Tiger of the symbols being reported as unresolved?

Actually, this problem wasn't a visibility problem, please see other
mail.

Post by Eric Sunshine
-- ES
-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_idt12&alloc_id344&op=click
_______________________________________________
Crystal-develop mailing list
https://lists.sourceforge.net/lists/listinfo/crystal-develop

Andreas Grosam

2005-05-24 22:46:32 UTC

Well, finally i managed to get rid of the most errors and was able to
compile (almost) all sources successfully, and also could link them.
At least, i fixed that "undefined symbols" problem.

Firstly, i need to mention that i didnŽt build on Tiger but on Panther
using the newest Apple-GCC4. The environment relavant for the basic CS
tests shouldn't be significantly different, though. It took that long
to fix that problem, because it is inherently difficult to install GCC4
in panther, *sigh* ....

Secondly, i encountered an odd behavior of the new GCC4 which might
occure (and does so in CS) which leads to compile errors. I will
discuss this in a different thread, because this is common GCC4, and
not Tiger specific. So, if not yet done already, CS sources require a a
change to fix that, otherwise it will still not compile ... but later.

To be frankly, the undefined symbols error in this issue, are GCC4 and
not Apple specific, but they occure only in the Objective-C sources of
CS, which will not be used on other platforms. Thus, this problem only
occurs on Mac OS X, and it seems, it requires a bit clarification.

Thirdly, i didn't tested the runtime behavior, yet -- just building.
This needs to be done later.

Ok, the reason why the symbols, namely the wrapper functions for
Objective-C methods, will not be found is simple:
They don't exist!

Here is an example of how a wrapper function is defined, in a .m file:
Note, this wrapper function shall only be reachable from inside the
shared lib where this function is defined (please correct me, if iŽm
wrong about that!).
In order not to be reachable from outside the DSO (dynamic share
object, aka plug-in, shared lib, etc.), the symbols visibility is
declared __private_extern__. The symbols are still reachable from other
.o files from within the same DSO, though.

// file: xxx.m
// C API to OSXDelegate2D class (CGBlit category)
#define DEL2D_FUNC(ret, func) __private_extern__ inline ret
OSXDelegate2D_##func

// C API to driver delegate class - wrappers around methods
DEL2D_FUNC(bool, blitToWindow)(OSXDelegate2DHandle delegate, unsigned
char *buffer, int width, int height, int depth)
{
return [(OSXDelegate2D *) delegate blitToWindow:buffer width:width
height:height depth:depth];
}

Just to foreclose this: the visbility feature wasn' t the problem.

The problem was the inconspicuously "inline" in the declaration of the
wrapper function!

Since this function will not be referenced from inside the .o file, it
caused the compiler to not generate code for this function.

This would have been no problem for a client, if it had seen this
interface description too, but unfortunately, a client will include
another header with a copy of that function declaration --- which
unfortunately omitted the "inline". Thus, as the compiler was to
compile the client, he assumed that there would be a function
definition elsewhere.

This file is the interface file for a client module, which calls
function OSXDelegate2D_ blitToWindow:
// file: xxx.h
#define DEL2D_FUNC(ret, func) __private_extern__ "C" ret
OSXDelegate2D_##func
DEL2D_FUNC(bool, blitToWindow)(OSXDelegate2D delegate, unsigned char
*buffer, int width, int height, int depth);

The fix is easy: just do not declare the wrapper inline. In fact, this
is the only possibility, otherwise, if the client would inline the
wrapper, this DSO would need to be able to reach the symbols inside the
wrapper, which might be defined private in the other DSO, and thus not
reachable, which would cause again linker errors.

Well, a note on the visibility of symbols in GCC4: per default, symbols
are all exported. However, in order to benefit from the visibility
feature, we should compile a file with visibility "hidden" per default.
Thus all symbols become private extern, by default. If we want to
export symbols so that they are reachable from outside this DSO, we
need to explicitly declare them "exported" in the declaration of the
corresponding symbol. This is just the same concept as it works for
years in Windows or Borland compilers.

A note to __private_extern__:
On Apple- GCC4, there is a built-in macro which is
#define __private_extern__ extern

This means essentially, __private_extern__ is not functional anymore.
However, since GCC4 supports the superior visibility concept, this does
not necessarily lead to a problem. I would suggest to invent new macros
and a change in the sources, as mentioned earlier.

Regards
Andreas Grosam

snip, snip

If it helps: I don't have any OSXDelegate2D.cpp (not what I can find),
only OSXDelegate2D.m

Often, though, we can work around such crashes by transforming the
code slightly while maintaining the same functionality but in a way
which pacifies the compiler. You might want to run some tests.

Post by Per Eckerdal
plugins/cscript/cspython/cs_pyth.cpp:115100: error: 'G3D_FOGMETHOD'
was not declared in this scope

This will be fixed the next time the automated job re-generates
cs_pyth.cpp. (It runs once per day.) Alternately, you could install
Swig on your machine (www.swig.org) to work around this issue. (Be
sure to re-run the CS configure script after installing Swig.)

Post by Per Eckerdal
LinkPlugin cgdriver2d.csbundle
_OSXDelegate2D_blitToWindow

Somehing strange is going on. The OSXDelegate2D.cpp source does get
compiled, but it seems to be missing symbols, or it is not present in
libcrystalspace_macosx.a for some reason. Try listing the contents of
the generated ./out/macosxppc/optimize/libs/libcrystalspace_macosx.a
to see if the OSXDelegate2D.o object is present. If it is, extract it
and use 'nm' to find out if those symbols are present in the object
file.
-- ES
-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
_______________________________________________
Crystal-develop mailing list
https://lists.sourceforge.net/lists/listinfo/crystal-develop

Eric Sunshine

2005-05-25 11:58:43 UTC

Post by Andreas Grosam
To be frankly, the undefined symbols error in this issue, are GCC4 and
not Apple specific, but they occure only in the Objective-C sources of
CS, which will not be used on other platforms.

Thanks for tracking this down.

Post by Andreas Grosam
Note, this wrapper function shall only be reachable from inside the
shared lib where this function is defined (please correct me, if i´m
wrong about that!).

This is correct for these wrapper functions. They are not needed outside
the library (although it wouldn't especially hurt if they were visible
to the outside).

Post by Andreas Grosam
// file: xxx.m
#define DEL2D_FUNC(ret, func) __private_extern__ inline ret
OSXDelegate2D_##func
The problem was the inconspicuously "inline" in the declaration of the
wrapper function!
Since this function will not be referenced from inside the .o file, it
caused the compiler to not generate code for this function.

Makes sense. I have corrected this in developer CVS.

Post by Andreas Grosam
Well, a note on the visibility of symbols in GCC4: per default, symbols
are all exported. However, in order to benefit from the visibility
feature, we should compile a file with visibility "hidden" per default.
Thus all symbols become private extern, by default.

We do this for optimize mode; that's when -fvisibility=hidden is used.

Post by Andreas Grosam
If we want to export
symbols so that they are reachable from outside this DSO, we need to
explicitly declare them "exported" in the declaration of the
corresponding symbol. This is just the same concept as it works for
years in Windows or Borland compilers.

This we also do (all the CS_FOO_EXTERN stuff).

Post by Andreas Grosam
On Apple- GCC4, there is a built-in macro which is
#define __private_extern__ extern
This means essentially, __private_extern__ is not functional anymore.
However, since GCC4 supports the superior visibility concept, this does
not necessarily lead to a problem. I would suggest to invent new macros
and a change in the sources, as mentioned earlier.

I don't think that there are very many places where we have such
functions, though we certainly can add such a macro.

-- ES

Eric Sunshine

2005-05-18 20:51:46 UTC

Post by Per Eckerdal
C++ ./out/macosxppc/optimize/libs/cstool/mdltool.o
libs/cstool/mdltool.cpp: In static member function `static void
libs/cstool/mdltool.cpp:734: internal compiler error: in cp_tree_equal,
at cp/tree.c:1679

Per Eckerdal

2005-05-19 05:26:53 UTC

I did that, but I couldn't make it make any sense. The error
disappears when one or more of line 816-819 is commented out;

CS_MDLTOOL_HELPER (Vertex);
CS_MDLTOOL_HELPER (Normal);
CS_MDLTOOL_HELPER (Color);
CS_MDLTOOL_HELPER (Texel);

It seems to be something with the macro, but I can't figure it out.
/Per Eckerdal

Bump the optimization back up to -O3 and try to figure out which
line is causing problems for the compiler. An easy way to do this
is to remove some code and attempt the compile again. For instance,
remove all of the code inside the outermost while() loop and see if
the error goes away. If it does, re-add that code and remove the
code inside one of the inner while() or for() loops. Keep removing
bits of code until you have narrowed down the compiler crash to a
particular line (or lines). Once we know what line is problematic,
we can figure ways to transform it into something the compiler likes.
-- ES
-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
_______________________________________________
Crystal-develop mailing list
https://lists.sourceforge.net/lists/listinfo/crystal-develop

Eric Sunshine

2005-05-19 06:08:28 UTC

I did that, but I couldn't make it make any sense. The error disappears
when one or more of line 816-819 is commented out;
CS_MDLTOOL_HELPER (Vertex);
It seems to be something with the macro, but I can't figure it out.

You might try some simple transformations. For instance, starting with:

#define CS_MDLTOOL_HELPER(obj) \
n = obj##IndexTable->Find (Polygon->Get##obj (j)); \
if (n != (size_t)-1) { \
Polygon->Set##obj (j, (int)n); \
} else { \
obj##IndexTable->Push (Polygon->Get##obj (j)); \
Polygon->Set##obj (j, (int)(obj##IndexTable->Length () - 1)); \
}

Try changing the last couple statements to:

n = obj##IndexTable->Push (Polygon->Get##obj (j)); \
Polygon->Set##obj (j, (int)n); \

Or you could simplify it even more:

#define CS_MDLTOOL_HELPER(obj) \
n = obj##IndexTable->Find (Polygon->Get##obj (j)); \
if (n == (size_t)-1) { \
n = obj##IndexTable->Push (Polygon->Get##obj (j)); \
Polygon->Set##obj (j, (int)n); \
}

-- ES

Andreas Grosam

2005-05-25 10:34:36 UTC

There is still an issue when building on Mac OS X (GCC4 and GCC3):

(note, i have SWIG installed)

** use a font with fixed width to display this error message! **

Ant errors (one expample):

"/usr/bin/ant" -quiet -emacs -Dbuild.compiler.emacs=true -buildfile
./out/macosxppc/optimize/plugins/cscript/csjava/build.xml

/Users/agrosam/Develop/CrystalSpace/build-test-apple-gcc4-final/out/
macosxppc/optimize/plugins/cscript/csjava/src/org/crystalspace3d/
cspace.java:20: cannot resolve symbol
symbol : class SWIGTYPE_p_csStringBase
location: class org.crystalspace3d.cspace
public static SWIGTYPE_p_csStringBase add(String iStr1,
SWIGTYPE_p_csStringBase iStr2) {
^

Means: ant can't resolve symbol SWIGTYPE_p_csStringBase

And linker errors (one example):

export MACOSX_DEPLOYMENT_TARGET=10.2
/opt/gcc4/bin/apple-g++-4.0 -bundle -o cspython.csbundle
./out/macosxppc/optimize/plugins/cscript/cspython/cspython.o
./out/macosxppc/optimize/plugins/cscript/cspython/pytocs.o -lm -lmx
-ldl -Wl,-multiply_defined,suppress -L/usr/local/lib
-Wl,-framework,AppKit -Wl,-framework,Foundation -bundle
./out/macosxppc/optimize/libs/libcrystalspace_python.a
./out/macosxppc/optimize/libs/libcrystalspace.a
-L/System/Library/Frameworks/Python.framework/Versions/2.3/lib/
python2.3
-L/System/Library/Frameworks/Python.framework/Versions/2.3/lib/
python2.3/config
-L/System/Library/Frameworks/Python.framework/Versions/2.3/lib
-L/System/Library/Frameworks/Python.framework/Versions/2.3/libs
-framework Python -ldl -lz
-L/System/Library/Frameworks/Python.framework/Versions/2.3/lib/
python2.3
-L/System/Library/Frameworks/Python.framework/Versions/2.3/lib/
python2.3/config
-L/System/Library/Frameworks/Python.framework/Versions/2.3/lib
-L/System/Library/Frameworks/Python.framework/Versions/2.3/libs
-framework Python -ldl -lm -lmx -ldl -Wl,-multiply_defined,suppress
-L/usr/local/lib -Wl,-framework,AppKit -Wl,-framework,Foundation

/opt/local/bin/odld: warning -L: directory name
(/System/Library/Frameworks/Python.framework/Versions/2.3/libs) does
not exist
/opt/local/bin/odld: warning -L: directory name
(/System/Library/Frameworks/Python.framework/Versions/2.3/libs) does
not exist
/opt/local/bin/odld: Undefined symbols:
iBase__DynamicCast(iBase*, char const*)
collect2: ld returned 1 exit status

Any ideas?

I don´t have any clue about SWIG.

For the linker error part, we would need to check which .o module calls
the undefined iBase__DynamicCast() function and why. Then figuring out,
how to define it. It looks like, the iBase__DynamicCast() is a RTTI
runtime function, but not sure. If so, RTTI needs to be enabled.
I can check this, if there is no solution yet.

Andreas

Eric Sunshine

2005-05-25 12:33:22 UTC

Post by Andreas Grosam
(note, i have SWIG installed)

Which version?

Post by Andreas Grosam
"/usr/bin/ant" -quiet -emacs -Dbuild.compiler.emacs=true -buildfile
./out/macosxppc/optimize/plugins/cscript/csjava/build.xml
cspace.java:20: cannot resolve symbol
symbol : class SWIGTYPE_p_csStringBase
location: class org.crystalspace3d.cspace
public static SWIGTYPE_p_csStringBase add(String iStr1,
SWIGTYPE_p_csStringBase iStr2) {

I seem to recall this being a bug in Swig. Swig's Java support is not
especially stable. For instance, Swig 1.3.24 is unusable with CS; it
generates .java filenames which overflow the OS's length limit. I think
the bug above was from 1.3.21(?). On the other hand, Swig 1.3.23's Java
support does work correctly with CS, and I think that 1.3.22 also worked.

Post by Andreas Grosam
iBase__DynamicCast(iBase*, char const*)
For the linker error part, we would need to check which .o module calls
the undefined iBase__DynamicCast() function and why. Then figuring out,
how to define it. It looks like, the iBase__DynamicCast() is a RTTI
runtime function, but not sure. If so, RTTI needs to be enabled.
I can check this, if there is no solution yet.

It is an RTTI of sorts, but it is a particularly ugly (and very slow)
hand-crafted RTTI specific to CS's Swig bindings. You can find the
master "template" for iBase__DynamicCast() in
CS/include/ivaria/cspace.i, however, to really see it in action, look at
the generated out/macosxppc/optimize/plugins/cscript/csjava/csjava.cpp.
You will see both the definition of the function and the various places
where it is called. That link error is pretty odd considering that the
function is defined used only in that one file.

-- ES

Andreas Grosam

2005-05-25 14:20:35 UTC

Post by Andreas Grosam
(note, i have SWIG installed)

Which version?

SWIG Version 1.3.24
Compiled with g++ [powerpc-apple-darwin7.9.0]

I seem to recall this being a bug in Swig. Swig's Java support is not
especially stable. For instance, Swig 1.3.24 is unusable with CS; it
generates .java filenames which overflow the OS's length limit. I
think the bug above was from 1.3.21(?). On the other hand, Swig
1.3.23's Java support does work correctly with CS, and I think that
1.3.22 also worked.

I chose just the most easiest way: port install swig -- and got this
;-)

Post by Andreas Grosam
iBase__DynamicCast(iBase*, char const*)
For the linker error part, we would need to check which .o module
calls the undefined iBase__DynamicCast() function and why. Then
figuring out, how to define it. It looks like, the
iBase__DynamicCast() is a RTTI runtime function, but not sure. If
so, RTTI needs to be enabled.
I can check this, if there is no solution yet.

It is an RTTI of sorts, but it is a particularly ugly (and very slow)
hand-crafted RTTI specific to CS's Swig bindings. You can find the
master "template" for iBase__DynamicCast() in
CS/include/ivaria/cspace.i, however, to really see it in action, look
at the generated
out/macosxppc/optimize/plugins/cscript/csjava/csjava.cpp. You will see
both the definition of the function and the various places where it is
called.

I did that, it looks even more ugly :-)

Post by Eric Sunshine
That link error is pretty odd considering that the function is defined
used only in that one file.

hm, hm, hmhmhm ...

I need to check, how this module has been compiled.

The symbol is defined as:
(undefined [lazy bound]) external
__Z18iBase__DynamicCastP5iBasePKc

It seems, this is not what it ought to be..... (later)

Andreas

Post by Eric Sunshine
-- ES
-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit
http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
Crystal-develop mailing list
https://lists.sourceforge.net/lists/listinfo/crystal-develop

Andreas Grosam

2005-05-25 14:34:58 UTC

Post by Andreas Grosam
(note, i have SWIG installed)

Which version?

SWIG Version 1.3.24
Compiled with g++ [powerpc-apple-darwin7.9.0]

I seem to recall this being a bug in Swig. Swig's Java support is not
especially stable. For instance, Swig 1.3.24 is unusable with CS; it
generates .java filenames which overflow the OS's length limit. I
think the bug above was from 1.3.21(?). On the other hand, Swig
1.3.23's Java support does work correctly with CS, and I think that
1.3.22 also worked.

I chose just the most easiest way: port install swig -- and got this
;-)

Post by Andreas Grosam
iBase__DynamicCast(iBase*, char const*)
For the linker error part, we would need to check which .o module
calls the undefined iBase__DynamicCast() function and why. Then
figuring out, how to define it. It looks like, the
iBase__DynamicCast() is a RTTI runtime function, but not sure. If
so, RTTI needs to be enabled.
I can check this, if there is no solution yet.

It is an RTTI of sorts, but it is a particularly ugly (and very slow)
hand-crafted RTTI specific to CS's Swig bindings. You can find the
master "template" for iBase__DynamicCast() in
CS/include/ivaria/cspace.i, however, to really see it in action, look
at the generated
out/macosxppc/optimize/plugins/cscript/csjava/csjava.cpp. You will
see both the definition of the function and the various places where
it is called.

I did that, it looks even more ugly :-)

Post by Eric Sunshine
That link error is pretty odd considering that the function is
defined used only in that one file.

hm, hm, hmhmhm ...
I need to check, how this module has been compiled.
(undefined [lazy bound]) external
__Z18iBase__DynamicCastP5iBasePKc
It seems, this is not what it ought to be..... (later)

Yup, i guess i got it:

The problem is, in cs_pyth.cpp, the function iBase__DynamicCast() will
be called before it is defined, thus, the compiler can't reference it
immediately. So, it obviously needs a declaration before it will be
used, somewhere near on top of the file:

static csWrapPtr iBase__DynamicCast(iBase *self,char const *to_name);

*sigh* -- dunno how to fix that, since this file is auto-generated. Any
idea?

Post by Andreas Grosam
Andreas

Eric Sunshine

2005-05-26 08:38:10 UTC

Post by Andreas Grosam
The problem is, in cs_pyth.cpp, the function iBase__DynamicCast() will
be called before it is defined, thus, the compiler can't reference it
immediately. So, it obviously needs a declaration before it will be
static csWrapPtr iBase__DynamicCast(iBase *self,char const *to_name);
*sigh* -- dunno how to fix that, since this file is auto-generated. Any
idea?

I can't even get that far with Swig 1.3.24. It bombs out before it even
emits iBase__DynamicCast() to csjava.cpp. This version seems more buggy
with Java than earlier versions; and I haven't had time to sit down to
determine if there is any way to work around these bugs. It's not a good
overall solution, but for now the general recommendation is to use Swig
1.3.23.

If you want to take a crack at resolving these problems, there are at
least three or four serious issues (possibly all related) plaguing 1.3.24:

(1) It generates ridiculously long names for output files which seem to
overflow the OS limit, such as:

Unable to open
./out/linuxx86/optimize/plugins/cscript/csjava/src/org/crystalspace3d/
SWIGTYPE_p_csArrayTcsArrayTcsShaderVariable_p_csArrayElementHandlerT
csShaderVariable_p_t_csArrayMemoryAllocatorTcsShaderVariable_p_t_t_
csArrayElementHandlerTcsArrayTcsShaderVariable_p_csArrayElementHandlerT
csShaderVariable_p_t_csArrayMemoryAllocatorTcsShaderVariable_p_t_t_t_
csArrayMemoryAllocatorTcsArrayTcsShaderVariable_p_csArrayElementHandlerT
csShaderVariable_p_t_csArrayMemoryAllocatorTcsShaderVariable_p_t_t_t_t.java

(2) It bombs before emitting a complete csjava.cpp (in my case, it
emitted only about 92 lines). This may be a consequence of problem #2.

(3) The missing SWIGTYPE_p_Foo.java classes. Upon investigation, at
least for my attempt, this also may be a consequence of #1. It seems to
have bombed before emitting the majority of the .java files to
/out/macosx/optimize/plugins/cscript/csjava/src/org/crystalspace3d/.

(4) The invocation of iBase__DynamicCast() before its
declaration/definition. This problem does not impact earlier versions of
Swig. (I am unable to reproduce this.)

-- ES

Andreas Grosam

2005-05-26 20:26:37 UTC

Hi Eric,

i switched back to swig-1.3.23 and --- the errors diminished. So, then
I downloaded the newset CS via cvs, and started again ...

Finally, i got everything to compile and to link with GCC4 - for
optimized and debug build. Hurray!
No errors, only harmless linker warnings because of multible
gcc++-libs, which is ok, since i have multible installed.

I think, it would be a good idea to upadate the documentation section
for the third party libs. Now, since i have much experience installing
the required and optional libraries on Mac OS X :-) i could contribute
a bit there.

One thing i would like to mention is, that we could improve the build
options. There are some optimizations possible when compiling objects
for shared libs and also when linking them.
I would also prefer to have the visibility options set for debug builds.

Another thing which comes to my mind and needs further investigation
is, that in case of optimization O3, the compiler inlines functions -
even those not explicitlly declared inline. This might be problematic
for exported functions, especially short wrapper functions.
This is not a direct problem, since the linker would then normally
complain about missing symbols.

After a short break, I will take a deeper look into the test programs,
there are still a lot of issues.

At least csdemo is running fine. (the optimized version achieves 50%
higher frame rates).

Regards
Andreas

Post by Andreas Grosam
The problem is, in cs_pyth.cpp, the function iBase__DynamicCast()
will be called before it is defined, thus, the compiler can't
reference it immediately. So, it obviously needs a declaration before
static csWrapPtr iBase__DynamicCast(iBase *self,char const *to_name);
*sigh* -- dunno how to fix that, since this file is auto-generated.
Any idea?

I can't even get that far with Swig 1.3.24. It bombs out before it
even emits iBase__DynamicCast() to csjava.cpp. This version seems more
buggy with Java than earlier versions; and I haven't had time to sit
down to determine if there is any way to work around these bugs. It's
not a good overall solution, but for now the general recommendation is
to use Swig 1.3.23.
If you want to take a crack at resolving these problems, there are at
(1) It generates ridiculously long names for output files which seem
Unable to open
./out/linuxx86/optimize/plugins/cscript/csjava/src/org/crystalspace3d/
SWIGTYPE_p_csArrayTcsArrayTcsShaderVariable_p_csArrayElementHandlerT
csShaderVariable_p_t_csArrayMemoryAllocatorTcsShaderVariable_p_t_t_
csArrayElementHandlerTcsArrayTcsShaderVariable_p_csArrayElementHandlerT
csShaderVariable_p_t_csArrayMemoryAllocatorTcsShaderVariable_p_t_t_t_
csArrayMemoryAllocatorTcsArrayTcsShaderVariable_p_csArrayElementHandler
T
csShaderVariable_p_t_csArrayMemoryAllocatorTcsShaderVariable_p_t_t_t_t.
java
(2) It bombs before emitting a complete csjava.cpp (in my case, it
emitted only about 92 lines). This may be a consequence of problem #2.
(3) The missing SWIGTYPE_p_Foo.java classes. Upon investigation, at
least for my attempt, this also may be a consequence of #1. It seems
to have bombed before emitting the majority of the .java files to
/out/macosx/optimize/plugins/cscript/csjava/src/org/crystalspace3d/.
(4) The invocation of iBase__DynamicCast() before its
declaration/definition. This problem does not impact earlier versions
of Swig. (I am unable to reproduce this.)
-- ES
-------------------------------------------------------
SF.Net email is sponsored by: GoToMeeting - the easiest way to
collaborate
online with coworkers and clients while avoiding the high cost of
travel and
communications. There is no equipment to buy and you can meet as often
as
you want. Try it
free.http://ads.osdn.com/?ad_id=7402&alloc_id=16135&op=click
_______________________________________________
Crystal-develop mailing list
https://lists.sourceforge.net/lists/listinfo/crystal-develop

Eric Sunshine

2005-05-27 04:57:36 UTC

Post by Andreas Grosam
I think, it would be a good idea to upadate the documentation section
for the third party libs. Now, since i have much experience installing
the required and optional libraries on Mac OS X :-) i could contribute
a bit there.

Which section precisely needs updating? Do you refer to the
MacOS/X-specific portion or the generic portion? Certainly, it would be
a good idea to mention DarwinPorts in the Mac-specific documentation.

Please feel free to update the documentation; making whatever
clarifications and enhancements seem necessary.

Post by Andreas Grosam
One thing i would like to mention is, that we could improve the build
options. There are some optimizations possible when compiling objects
for shared libs and also when linking them.
I would also prefer to have the visibility options set for debug builds.

Will this have a negative impact on debugging itself, or is debugging
independent of that?

Post by Andreas Grosam
After a short break, I will take a deeper look into the test programs,
there are still a lot of issues.

These issues impact gcc4? Or earlier gcc, as well?

-- ES

Andreas Grosam

2005-05-27 09:44:37 UTC

Post by Andreas Grosam
I think, it would be a good idea to upadate the documentation section
for the third party libs. Now, since i have much experience
installing the required and optional libraries on Mac OS X :-) i
could contribute a bit there.

Which section precisely needs updating? Do you refer to the
MacOS/X-specific portion or the generic portion? Certainly, it would
be a good idea to mention DarwinPorts in the Mac-specific
documentation.
Please feel free to update the documentation; making whatever
clarifications and enhancements seem necessary.

ok.

Post by Andreas Grosam
One thing i would like to mention is, that we could improve the build
options. There are some optimizations possible when compiling
objects for shared libs and also when linking them.
I would also prefer to have the visibility options set for debug builds.

Will this have a negative impact on debugging itself, or is debugging
independent of that?

No. Debugging symbols are independend on symbol names, and it is also a
difference if symbols are available and if they are global or local.
The availability of symbol names may help in backtracing and debugging.

Well, the visbility is part of the interface contract. It is another
orthogonal aspect which has to be defined by the programmer and it has
to be tested as well. Visibility defines whether a symbol name is
reachable from another DSO. This only occurs during linking or during
runtime.

With the visibility feature, we can explicitly specify which symbols
shall be exported (can be dynamically referenced from another DSO).
Symbol names which will not be referenced during linking or runtime can
be stripped in order to optimize runtime behavior. Symbol stripping
should be a final step in the build process.

Symbols may be left in for a final product (without debugging info) if
"high quality" backtracing should be available for debugging purposes.

Additional info:
See man strip(1) or certain linker options ld(1) during link time.