Mac OSX port?

[OneSadCookie]

Code: Select all

EXPCL_DTOOL int panda_version_1_0_3c = 0;

Any clues where the extra c might come from?

[drwr]

By convention, the "c" indicates the tree was built by the user, as opposed to an official version built by us. I considered this worth noting in the version number because a tree checked out by the user might not exactly match the 1.0.3 version across the board.

David

[OneSadCookie]

So why would the rest of the code be trying to use the un-c'd version?

[drwr]

It must be a mismatched compilation. If the symbol name defined in the header file matches the one in the cxx file, then the problem files must have been compiled with a different header file.

Either an earlier version that was built differently for some reason, or they are picking up the header file that is installed in /usr/local/panda or whatever.

David

[OneSadCookie]

The build is from clean (well, rm -rf built, anyway), and there's nothing in /usr/local/panda -- perhaps there's something I could have screwed up in makepanda.py?

[drwr]

Hmm. The symbol panda_version_* should really only appear in two places: checkPandaVersion.h and checkPandaVersion.cxx. You mentioned in an earlier post in this thread that it was externed in a few places. Is it actually being externed in other places, or is it just that the other code is including checkPandaVersion.h?

It might be useful to grep for this symbol in your .so files, and see where it's coming out wrong:

nm libdtoolutil.so | grep panda_version_
nm libpanda.so | grep panda_version_
nm libpandaexpress.so | grep panda_version_

And so on. You can also grep in the .o files:

nm pview_pview.o | grep panda_version_

Someone, somewhere must have picked up the wrong panda_version symbol.

David

[OneSadCookie]

Code: Select all

keith$ find . -name '*.dylib' | xargs nm -A | grep panda_version_
./built/lib/libdtool.dylib:dtoolutil_composite1.o: 00065008 D _panda_version_1_0_3c
./built/lib/libframework.dylib:framework_config_framework.o:          U _panda_version_1_0_3
./built/lib/libpanda.dylib:panda_panda.o:          U _panda_version_1_0_3
./built/lib/libpandaegg.dylib:pandaegg_pandaegg.o:          U _panda_version_1_0_3
./built/lib/libpandaexpress.dylib:pandaexpress_pandaexpress.o:          U _panda_version_1_0_3
./built/lib/libpandafx.dylib:pandafx_pandafx.o:          U _panda_version_1_0_3
./built/lib/libpandagl.dylib:pandagl_pandagl.o:          U _panda_version_1_0_3
./built/lib/libpandaphysics.dylib:pandaphysics_pandaphysics.o:          U _panda_version_1_0_3

IOW, only the one place thinks it should have a c; everyone else is convinced it shouldn't...

[drwr]

These other libraries are the ones that are in the panda tree; only the one in the dtool tree has it right. That strongly suggests there is some errant checkPandaVersion.h file out there that the panda tree is picking up.

Does OSX have the locate command?

locate checkPandaVersion.h

David

[OneSadCookie]

It does, but it also has Spotlight, which is better

I have two checkPandaVersion.h files, both within the one panda source tree --

dtool/src/dtoolutil/checkPandaVersion.h says: extern EXPCL_DTOOL int panda_version_1_0_3c;

built/include/checkPandaVersion.h says: extern EXPCL_DTOOL int panda_version_1_0_3;

so that's where the conflict comes from, at least.

[Josh Yelon]

OK, the problem is that you used both build systems: ppremake, and makepanda. The two aren't compatible with each other. If you decide to switch from one build system to the other, you need to get a clean source tree.

[OneSadCookie]

There's no way to clean an existing source tree?

[Josh Yelon]

After running makepanda, all the files are in the "built" subdirectory. If you remove the entire directory, then you're back to a clean source tree.

After running ppremake, there's a "make clean," but I know it doesn't delete everything. I have this vague recollection that there's also a "make veryclean" or something along those lines --- I can't speak authoritatively about that.

[happy go lucky]

i was hoping that there would be some more progress with getting panda3d compiled on os x. i gave it a shot with the 1.0.4 version and i've found:

* having two custom methods to compile is confusing and presents a steep learning curve. (e.g. which one is recommended? is makepanda.py newer? also, the first step with ppremake should be "compile ppremake"!)

* makepanda.py: "cp --recursive" doesn't work. need "cp -R" instead

* makepanda.py: checks if sys.platform is "win32" or "linux". if we are "darwin" then variables aren't defined, and it barfs.

* #include <malloc.h> doesn't exist on freebsd/OS X.

* direct/src/directbase/ppython.cxx: all the code is commented out if we are not WIN32 or __linux__ which gives a _main() is not defined error.

i'm sure the OS x people could supply some simple patches here, but it seesm that there needs to be a bit more direction from the package maintainers as to how to handle multiple platforms. currently, it seems the limit of the if windows else (linux) system has been reached!

[OneSadCookie]

I've been through all those things and patched 'em up... just keep hitting obstacle after obstacle. I guess I'll get around to properly cleaning my source dir and trying again at some point...

[Volpe]

For the makepanda just add another line:
elif sys.platform == 'darwin':
#linux settings

Macs are similar to linux (i.e both use gcc etc)

Of course you only get a little further.

[Fixer]

Change them to look like this instead:

Code: Select all

#undef OLD_STYLE_ALLOCATOR
#define GNU_STYLE_ALLOCATOR
#undef VC6_STYLE_ALLOCATOR
#undef MODERN_STYLE_ALLOCATOR
#undef NO_STYLE_ALLOCATOR 1

I just wanted to point out in case anyone is having difficulty with this code snippet, it should probably be

Code: Select all

#undef OLD_STYLE_ALLOCATOR
#undef GNU_STYLE_ALLOCATOR
#undef VC6_STYLE_ALLOCATOR
#undef MODERN_STYLE_ALLOCATOR
#define NO_STYLE_ALLOCATOR 1

The c preprocessor strikes again!

[malcolmr]

Has any progress been made on a Mac port?

Malcolm

[Fixer]

Greetings all!

Now that the 1.1.0 version of the Linux port seems to be semi-stable (see http://panda3d.org/phpbb2/viewtopic.php?t=977), I've begun trying to pull the Linux version over to Mac OS X.

So far, it's going pretty well! I've used the comments and information provided on this forum thread to sidestep some of the early hurdles. I now have an interrogate binary at built/bin/interrogate, but it's giving me a bit of difficulty when I give it a test-run. I'm very new to the interrogate tool, so I was hoping someone could give a bit of guidance concerning how to attack the following error message:

Code: Select all

built/bin/interrogate -srcdir panda/src/express -DCPPPARSER -D__STDC__=1 -D__cplusplus -D__ppc__ -D__const=const  -Sbuilt/include/parser-inc -S/usr/include -Ibuilt/python/include -Ithirdparty/linux-libs-a/zlib/include -oc built/tmp/libexpress_igate.cxx -od built/pandac/input/libexpress.in -fnames -string -refcount -assert -python-native -Ibuilt/tmp -Ipanda/src/express -Ibuilt/include -DBUILDING_PANDAEXPRESS -module pandaexpress -library libexpress atomicAdjust.h atomicAdjustDummyImpl.h atomicAdjustImpl.h atomicAdjustNsprImpl.h bigEndian.h buffer.h checksumHashGenerator.h circBuffer.h clockObject.h conditionVar.h conditionVarDummyImpl.h conditionVarImpl.h conditionVarNsprImpl.h config_express.h datagram.h datagramGenerator.h datagramIterator.h datagramSink.h dcast.h encryptStream.h encryptStreamBuf.h error_utils.h express_headers.h externalThread.h hashGeneratorBase.h hashVal.h indirectLess.h littleEndian.h mainThread.h memoryInfo.h memoryUsage.h memoryUsagePointerCounts.h memoryUsagePointers.h multifile.h mutexDummyImpl.h mutexHolder.h mutexImpl.h mutexNsprImpl.h namable.h nativeNumericData.h numeric_types.h ordered_vector.h password_hash.h patchfile.h pmutex.h pointerTo.h pointerToArray.h pointerToBase.h pointerToVoid.h profileTimer.h pta_uchar.h ramfile.h reMutex.h reMutexHolder.h referenceCount.h reversedNumericData.h selectThreadImpl.h streamReader.h streamWriter.h stringDecoder.h subStream.h subStreamBuf.h textEncoder.h thread.h threadDummyImpl.h threadImpl.h threadNsprImpl.h threadPriority.h tokenBoard.h trueClock.h typedReferenceCount.h typedef.h unicodeLatinMap.h vector_uchar.h virtualFile.h virtualFileComposite.h virtualFileList.h virtualFileMount.h virtualFileMountMultifile.h virtualFileMountSystem.h virtualFileSimple.h virtualFileSystem.h weakPointerTo.h weakPointerToBase.h weakPointerToVoid.h weakReferenceList.h windowsRegistry.h zStream.h zStreamBuf.h express_composite1.cxx express_composite2.cxx
                  *** Error in /usr/include/libkern/machine/OSByteOrder.h near line 50, column 14:
                  parse error, expecting `')''
Error parsing file: 'atomicAdjust.h'
Elapsed Time: 11 sec


Note that I did change the architecture definition line from __i386__ to __ppc__, since that seemed to follow the pattern of the other architectures. Looking over the offending line in OSByteOrder.h, I don't see any problems inherent to the line itself. Can anyone give any suggestions on this issue?

One other issue is the third-party binaries. I've created a directory named thirdparty/darwin-libs-a that I plan to populate following the pattern of the thirdparty/linux-libs-a directory. I'm a little hung up on the NSPR components right now. Josh left a README note (bonus points for proper documentation!) that mentions the original compilation unit was modified---specifically, that LIBRARY_NAME was changed to avoid namespace conflicts. I snagged a copy of NSPR's sources off of Netscape's website, but I wasn't able to find a LIBRARY_NAME key in the source. Would it be possible to obtain a copy of the modified source that was used to build the instance of nspr in linux-libs-a?

Thank you for all your help!

[Roger]

This is a system include.... suprising it is even trying to parse it ,, May be becouse the inlined function has a structure in it .. hmm

Easiest way I gnow of to get by this is to add a

ignorefile OSByteOrder.h

to an .N file.. Quick look at interigate.cxx and such will put you on the right track.

[drwr]

Another quick trick that we often do is to add a stubbed-out copy of this header file to dtool/src/parser-inc directory (and add a rule to the build script to install this header file to include/parser-inc).

This parser-inc directory is only scanned when running interrogate, no actual compiler ever pulls header files out of this directory. If you look in there, you'll see lots of stubbed out header files, including things like windows.h and rand.h.

The advantage to using a stubbed-out file is that you don't have to put a .N for it in every directory that might include OSByteOrder.h, and you can also put some typedefs in the stub file that might be necessary to parse files that include OSByteOrder.h and expect certain types to have been defined. Note that the typedefs don't necessarily have to be accurate; they usually just have to name the new type, it doesn't matter what it's typedeffed to.

David