Fwd: Torcs Universal Binary for Mac OS X 10.5

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H

_______________________________________________
Torcs-devel mailing list
Torcs-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/torcs-devel

OS X linkage problems

A couple weeks ago I asked about OS X port, and saw the responses
here. I've also been in contact with Steve Hudson about it, and have
gotten a running version. With a few other tweaks, I got the trackgen
program built and seemingly usable.

I'm building on new macbook, leopard 10.5.6, XCode 3.1.2 (GCC 4.0.1),
and have set the project default architectures to be "Universal
32-bit" (i386/ppc). Oh, this is the 1.3.0 Torcs source.

There are some odd intermittant linkage problems that I haven't
figured out yet. At one point, I was able to get a full, clean build
of everything in the projects that Steve shared, but it's eluding me
now. The ssggraph.so project is the epicenter of the 6 linkage
problems.

Two errors are this:
"ssgVtxTable::ssgVtxTable(unsigned long, ssgVertexArray*,
ssgNormalArray*, ssgTexCoordArray*, ssgColourArray*)", referenced
from:
      initWheel(CarElt*, int)in grcar.o
      initBackground()     in grscene.o
   ... etc

Other errors are GCC "vtable of" errors. Here's a complete error:
  "ssgSimpleState::isEnabled(unsigned long)", referenced from:
      vtable for grMultiTexState in grmultitexstate.o
      vtable for grManagedState in grtexture.o

The GCC vtable issue is this: when a class is declared in a header
file AND has virtual methods with the function body defined in the
header also, GCC will not generate a vtable anywhere. GCC requires at
least one of the virtual functions to have an implementation in a
compilation unit (.cpp), and GCC will place the vtable in that unit's
object file. A class defined like the following will generate this
error:
/* Foo.h */
class Foo {
    public:
    ~Foo() {}
};

To fix it, just move any virtual function body out of the header, and
into a .cpp file somewhere. I made this change to the grManagedState
class (grtexture.h, grtexture.cpp) and that cleared up about half of
the specific error locations. Ditto for grMultiTexState. I'm stumped
as to what is causing the remaining vtable issues.

Has anybody else been trying out the OS X builds, and if they are
working for you, what's your hardware and versions?

BTW, I also fetched the plib-185 disk image Steve shared, and rebuilt
that framework ensuring the GCC arches and SDK version matched Torcs.
No change, as it matched OK.

-Brent

p.s. $ gcc --version
i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5490)

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H

Re: OS X linkage problems

Some observations on the linkage issue with plib.

The issue occurs with the ssggraph module, and the grVtxTable subclass
of plib's ssgVtxTable. One of the ssgVtxTable constructors is:
ssgVtxTable(GLenum type, ssgVertexArray* va, ssgNormalArray* na,
ssgTexCoordArray* ta, ssgColourArray* ca)

GLenum is defined as "unsigned int" in GL/gl.h, so the output from the
plib framework's dylib (or a local static lib) has the signature:
    $ nm -g plib.framework/Versions/A/plib  | c++filt | grep
'ssgVtxTable::ssgVtxTable'
    00075972 T ssgVtxTable::ssgVtxTable(unsigned int,  ...as above...)
    0000234e T ssgVtxTable::ssgVtxTable(unsigned int, .....)
# <- output from my /usr/local/lib/libplibssg.a

I wrote a small test code based on the grVtxTable subclassing that
replicates this problem. The main() simply instantiates a grVtxTable,
which in turn invokes the above constructor. In tinkering with this
test, I found when it works and when it doesn't link.

If I compile the code manually, but link against *static* libraries,
the link works fine. The test source object file is looking for:
    nm -g libvtx.o | c++filt | grep 'ssgVtxTable::ssgVtxTable'
             U ssgVtxTable::ssgVtxTable(unsigned int, ...as above...)
and the linker finds it in the static libraries.

If I compile the test code to make a .so (as Torcs does), then the
compiler is attempting to find the signature with "unsigned long":
    $ nm -g libvtx.o | c++filt | grep 'ssgVtxTable::ssgVtxTable'
             U ssgVtxTable::ssgVtxTable(unsigned long, ...as above...)
and the linker does not find this in the dynamic library (plib framework).

Static linking finds the "unsigned int" version OK, and dynamic
linking is looking for "unsigned long". I've looked through project
settings and compiler options, but I didn't find anything relevant.

Any ideas?

thanks,
-Brent

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H

Re: OS X linkage problems

Found it. This may be a help to anyone else who is trying to build
portable software.

The issue is caused by the platform SDK one compiles against. The PLIB
framework was built against the Leopard 10.5 SDK, and I was attempting
to build everything against the 10.4 SDK.

Sure enough, OpenGL/gl.h in 10.5 defines GLenum as "unsigned int", and
the old 10.4 gl.h has "unsigned long". Unsigned int is the safer of
the two going forward into 64bit apps, which is probably why it
changed.

Once I set everything to build against 10.5 SDK, the errors went away.
I could have also rebuilt plib with 10.4.

Libraries that do not link against anything beyond standard C/C++
libraries will not have this problem, but whenever any SDK framework
is used (CoreImage, OpenAL, OpenGL, etc), the SDK choice is important.

-Brent

On Sun, Mar 8, 2009 at 9:36 PM, Brent Burton <brentpburton <at> gmail.com> wrote:
> Some observations on the linkage issue with plib.
>
> The issue occurs with the ssggraph module, and the grVtxTable subclass
> of plib's ssgVtxTable. One of the ssgVtxTable constructors is:
> ssgVtxTable(GLenum type, ssgVertexArray* va, ssgNormalArray* na,
> ssgTexCoordArray* ta, ssgColourArray* ca)
> ...
> [unsigned int vs unsigned long in link search]

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H

Cofundos.org project: Network game torcs-ng

Dear friends,

I created a new open-source project "Network game torcs-ng" on Cofundos.org.
You can view the complete project description at:

     http://www.cofundos.org/project.php?id=152

Since I assume the project could be of interest for you too I would like to invite you to comment and bid on the project.

Thanks,

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com