help with compiling on ubuntu feisty

i’m using ppremake. building ppremake and dtool worked fine, but when i go to build panda, it dies on the interrogate step for libexpress_igate.cxx.

the error:

      *** Error in /usr/include/malloc.h near line 136, column 60:
      syntax error, unexpected IDENTIFIER, expecting '{' or ';' or ':' or '='

Error parsing file: ‘bigEndian.h’
make: *** [Opt3-Linux/libexpress_igate.cxx] Error 1

did i make interrogate wrong, or something? i’d think it could understand malloc.h …

thanks,

–ben

the full command from ppremake at that point:

interrogate -od Opt3-Linux/libexpress.in -oc Opt3-Linux/libexpress_igate.cxx -DCPPPARSER -D__STDC__=1 -D__cplusplus -D__i386__ -D__const=const -Dvolatile= -S/usr/local/panda/include/parser-inc -S/usr/include -I/home/badzmaru/panda/panda3d-1.3.2/panda -I…/pandabase -I/usr/local/panda/include -I/usr/include/python2.4 -fnames -string -refcount -assert -python-native -module “pandaexpress” -library “libexpress” bigEndian.h buffer.h checksumHashGenerator.h circBuffer.h config_express.h datagram.h datagramGenerator.h datagramIterator.h datagramSink.h dcast.h encryptStreamBuf.h encryptStream.h error_utils.h hashGeneratorBase.h hashVal.h indirectLess.h littleEndian.h memoryInfo.h memoryUsage.h memoryUsagePointerCounts.h memoryUsagePointers.h multifile.h namable.h nativeNumericData.h nodePointerToBase.h nodePointerTo.h nodeReferenceCount.h objectDeletor.h ordered_vector.h password_hash.h patchfile.h pointerTo.h pointerToArray.h pointerToBase.h pointerToVoid.h profileTimer.h pta_uchar.h ramfile.h referenceCount.h reversedNumericData.h streamReader.h streamWriter.h stringDecoder.h subStream.h subStreamBuf.h textEncoder.h threadSafePointerTo.h threadSafePointerToBase.h trueClock.h typedReferenceCount.h typedef.h unicodeLatinMap.h vector_uchar.h virtualFileComposite.h virtualFile.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

Actually, it doesn’t surprise me that it can’t understand malloc.h–interrogate is a pure C++ parser, and doesn’t know anything about the nonstandard symbols that system library writers like to put in their system header files. No doubt your system’s malloc.h has one of these nonstandard symbols at line 136.

No problem, though. Interrogate doesn’t actually need to parse any of the symbols in malloc, or really in any of the system header files, since it’s not actually generating code. It just needs to be able to get past what it thinks is a syntax error.

This is why we have the parser-inc directory, which is where we put a lot of stub header files that serve to shadow their actual system counterparts, and hide them from interrogate. So, it sounds like we need one more, for malloc.h.

In the short term, just create an empty file there yourself, e.g.:

touch /usr/local/panda/include/parser-inc/malloc.h

David

thanks david, that got me further. i did the same for unistd.h and string.h to get around the same problem. now i’m getting the error in /usr/local/panda/include/addHash.h :

badzmaru@silverado:~/panda/panda3d-1.3.2/panda$ make

*** Error in /usr/local/panda/include/addHash.h near line 35, column 35:
syntax error, unexpected IDENTIFIER, expecting ‘{’ or ‘;’ or ‘:’ or ‘=’
Error parsing file: ‘buffer.h’

but that’s one of panda’s own includes, so interrogate does need to process it, right?

is interrogate something that was built in a previous part of the panda build, or did it come from python or something? i wonder if i might have the wrong version…

Hmm, perhaps you’ve gone too far in your stubbing out. The symbol at line 35, column 35 of addHash.h is “size_t”, which is supposed to be defined in one of the system header files.

It doesn’t matter much what, precisely, you define it to be, as long as you make it vaguely an unsigned int. So I suggest putting the following in one of your stub header files:

typedef unsigned int size_t;

David

true. size_t is in unistd.h. but if i don’t stub it, i get

    *** Error in /usr/include/unistd.h near line 566, column 26:
    syntax error, unexpected IDENTIFIER, expecting '{' or ';' or ':' or '='

which is

#ifdef __USE_POSIX2
565 /* Get the value of the string-valued system variable NAME. */
566 extern size_t confstr (int __name, char *__buf, size_t __len) __THROW;
567 #endif

if i do redefine size_t in my stub unistd.h, interrogate gives an error at

*** Error in /usr/local/panda/include/stl_compares.h near line 42, column 44: syntax error, unexpected IDENTIFIER

so this seems like a dangerous hole to go down :0

All right, let’s take a different approach. Instead of stubbing out all of these system header files, let’s try #defining away the non-ANSI symbols they are relying on.

So remove all of the stub files you’ve created, and try again. Go back to your original error:

Error in /usr/include/malloc.h near line 136, column 60:
syntax error, unexpected IDENTIFIER, expecting '{' or ';' or ':' or '=' 

Look at your malloc.h, and see what’s there at line 136, column 60.

Then modify dtool/Config.Linux.pp. Look for the line that looks like:

#define SYSTEM_IGATE_FLAGS -D__i386__ -D__const=const -Dvolatile=

This is already defining away a handful of non-standard symbols that interrogate doesn’t know about: “i386”, “__const”, and “volatile” (ok, that last one is standard, but interrogate still doesn’t know about it and doesn’t care about it). Presumably there’s a new symbol on the offending line in malloc.h. Add it to the list with a parameter like “-Dsymbol=” (which means define the new symbol “symbol”, and make it equivalent to the empty string).

Repeat as necessary.

David

just on a whim, i recompiled dtool. bam, a whole bunch of stub headers appeared in /usr/local/panda/include that weren’t there before! now things are much better. not quite working yet, but closer.

now i’m just chasing linking errors (Cg needs pthreads, something’s not linking with libavcodec correctly, yadda yadda).

with the Config.pp files - which ones are used? the one in /usr/local/panda/ is loaded, but does ppremake also always read the one in dtool source directory? (for me, ~/panda/panda3d-1.3.2/dtool).

does Config.linux.pp actually get read or is that just an example?

when i make a change to /usr/local/panda/Config.pp, do i have to do a full cycle of ppremake, make, and make install for dtool before attempting to compile panda again?

Right, it should always read dtool/Config.pp, as well as dtool/Config.Linux.pp. You can prove this by putting a #print directive in either of these files.

If you make changes to /usr/local/panda/Config.pp, you should (strictly) repeat the whole cycle from the beginning.

David

david, thanks for your help & patience … i’m so close but so far.

i can get past the interrogate stage, but now i’m running into problems getting libpthread linked in. ppremake doesn’t set HAVE_POSIX_THREADS or HAVE_THREADS for me; but, libCg needs libpthread.

in /usr/local/panda/Config.pp i set

#define HAVE_POSIX_THREADS 1
#define HAVE_THREADS 1

but this doesn’t lead to having -lpthread in my makefiles. now, the dtool build dies trying to build interrogate:

g++ -o Opt3-Linux/interrogate Opt3-Linux/interrogate_interrogate_composite1.o Opt3-Linux/interrogate_interrogate_composite2.o -L…/cppparser/Opt3-Linux -L…/dconfig/Opt3-Linux -L…/dtoolbase/Opt3-Linux -L…/dtoolutil/Opt3-Linux -L…/interrogatedb/Opt3-Linux -L…/prc/Opt3-Linux -L…/pystub/Opt3-Linux -L/usr/local/panda/lib -lcppParser -lpystub -linterrogatedb -ldconfig -ldtoolutil -ldtoolbase -lprc -ldl -lssl -lcrypto
…/interrogatedb/Opt3-Linux/libinterrogatedb.so: undefined reference to pthread_mutexattr_destroy' ../interrogatedb/Opt3-Linux/libinterrogatedb.so: undefined reference topthread_mutexattr_settype’
…/interrogatedb/Opt3-Linux/libinterrogatedb.so: undefined reference to `pthread_mutexattr_init’

that line should have -lpthread in it. if i do the link by hand from the command line with -lpthread added in, it links succesfully. is there something else i need to put in Config.pp to tell it to link with pthreads?

Strange that it doesn’t set HAVE_POSIX_THREADS for you or add -lpthread. It really should be doing this automatically. You don’t happen to have WINDOWS_PLATFORM accidentally getting defined, do you?

Try running “make cleanall”, or checking out a clean build from scratch, to make sure you’re not being polluted by some partially built previous pass.

David

i wiped it and started over; still no pthreads. if i were to set HAVE_POSIX_THREADS, should that just be ‘1’ or does it need to point to an actual location?

here’s another thought - the only reason i want to build from ppremake actually is just to build maya2egg. building with makepanda or just using the .deb installer works fine for the rest, i just really need maya2egg.

• is it possible to compile just maya2egg without compiling everything else, or to convince makepanda to build it on linux?
• would it be ridiculous for me to just write another maya plugin, without using the panda libraries at all? egg looks like a really clear file format…

maya2egg is really big and complex. You could write another one without using the Panda library, but to write one as full-featured would be a lot of work.

But since the maya2egg in the Panda tree links with the rest of Panda, you can’t just build that in isolation. It has to exactly match the Panda .so’s it is compiled against, so you have to build the whole thing at the same time.

Since you don’t really need to build a threaded version of Panda, so you don’t need pthreads everywhere, try just putting:

#define UNIX_SYS_LIBS pthread

in the Sources.pp file for Cg. That will add -lpthread to that link line, but not anywhere else (and thus won’t break the interrogate build).

david

I can speak to this:

• is it possible to convince makepanda to build it on linux?

This should not be hard. The only reason I’ve never tried it is because we don’t own a copy of maya for linux.

If you look in makepanda, you can find this code:

for (ver,key) in MAYAVERSIONINFO:
print “Checking for “+ver
if (OMIT.count(ver)==0):
if (sys.platform == “win32”):
if (MAYASDK.has_key(ver)==0):
MAYASDK[ver]=GetRegistryKey(key, “MAYA_INSTALL_LOCATION”)
if (MAYASDK[ver] == 0):
WARNINGS.append(“The registry does not appear to contain a pointer to the “+ver
+” SDK.”)
WARNINGS.append(“I have automatically added this command-line option: --no-”+ve
r.lower())
OMIT.append(ver)
else:
MAYASDK[ver] = MAYASDK[ver].replace(”\”, “/”).rstrip("/")
else:
WARNINGS.append(ver+" not yet supported under linux")
WARNINGS.append(“I have automatically added this command-line option: --no-”+ver.lower(
))
OMIT.append(ver)

What this does is try to locate the maya SDK. On windows, it looks in the registry to find the appropriate directory. On linux, it gives up. So the first thing you need to do is alter the “else” clause here to enable it to find the SDK (ie, include files). Note that on windows, you can have several versions of maya installed — maybe this is true on linux too. So if you have, say, maya 6, you need to set MAYASDK[“MAYA6”] to the location of the maya 6 header files.

Then there’s this little piece of code:

    for ver in MAYAVERSIONS:
        if (PkgSelected(opts,"MAYA"+ver)):
            cmd = cmd + ' /I"' + MAYASDK["MAYA"+ver] + '/include"'
            cmd = cmd + " /DMAYAVERSION=" + ver

This is in the compile subroutine. It adds an “include” directive to the command-line if a maya-related program is being compiled. This only exists in the win32 codepath. You need to add an equivalent piece of code in the linux codepath.

Then, there’s this, in the interrogate code. Once again, this adds an include-directive to the interrogate command line if a maya-related program is being compiled. Once again, you need to duplicate this in the linux codepath. NO, wait… I see that it’s already there in the linux codepath! I wonder why? However, I’m sure I’ve never tested that code. You’ll need to test it.

    for ver in MAYAVERSIONS:
        if ((COMPILER=="MSVC") and PkgSelected(opts,"MAYA"+ver)):
            cmd = cmd + ' -I"' + MAYASDK["MAYA"+ver] + '/include"'

Then, there’s this:

    for ver in MAYAVERSIONS:
        if (PkgSelected(opts,"MAYA"+ver)):
            cmd = cmd + ' "' + MAYASDK["MAYA"+ver] +  '/lib/Foundation.lib"'
            cmd = cmd + ' "' + MAYASDK["MAYA"+ver] +  '/lib/OpenMaya.lib"'
            cmd = cmd + ' "' + MAYASDK["MAYA"+ver] +  '/lib/OpenMayaAnim.lib"'
            cmd = cmd + ' "' + MAYASDK["MAYA"+ver] +  '/lib/OpenMayaUI.lib"'

In the linking routine. If a maya-related program is being compiled, it adds the maya libraries to the linker command line. Once again — duplicate on linux codepath.

Finally, there’s mayaWrapper. This won’t compile under Linux, and I don’t think this program is needed under linux. Find the code that compiles mayawrapper, and add in an if-statement — “if (platform==“win32”): then compile mayawrapper-related stuff.”

That should get you most of the way. Let me know how it turns out.

tackling the maya exporter on linux challenge again

trying the makepanda route. i was able to get most of the options modified correctly, but i’m getting stuck on the step where maya2egg builds:

g++ -o built/bin/maya2egg85-wrapped -Lbuilt/lib -L/usr/X11R6/lib built/tmp/maya2egg85_mayaToEgg.o built/lib/libmayaegg85.a built/lib/libmaya85.a built/lib/libeggbase.a built/lib/libprogbase.a built/lib/libconverter.a built/lib/libpandatoolbase.a -lpandaegg -lpanda -lpandaexpress -lp3dtoolconfig -lp3dtool -lp3pystub -L/usr/autodesk/maya8.5/lib -lFoundation -lOpenMaya -lOpenMayaAnim -lOpenMayaUI -lpthread
/usr/bin/ld: warning: libimf.so, needed by /usr/autodesk/maya8.5/lib/libFoundation.so, not found (try using -rpath or -rpath-link)

pages and pages of ld errors follow, as libFoundation, libOpenMaya, etc have all suddenly forgotten how to link to all the libs they use (which, needless to say, are all right next to them in /usr/autodesk/maya8.5/lib, as always).

Fixed most by adding

-Wl,rpath,/usr/autodesk/maya/lib

but i still get a few errors:

g++ -o built/bin/maya2egg85-wrapped -Lbuilt/lib -L/usr/X11R6/lib built/tmp/maya2egg85_mayaToEgg.o built/lib/libmayaegg85.a built/lib/libmaya85.a built/lib/libeggbase.a built/lib/libprogbase.a built/lib/libconverter.a built/lib/libpandatoolbase.a -lpandaegg -lpanda -lpandaexpress -lp3dtoolconfig -lp3dtool -lp3pystub -L/usr/autodesk/maya8.5/lib -Wl,-rpath,/usr/autodesk/maya8.5/lib -Wl,-rpath-link,/usr/autodesk/maya8.5/lib -lFoundation -lOpenMaya -lOpenMayaAnim -lOpenMayaUI -lpthread
built/lib/libmaya85.a(maya85_composite1.o): In function `MayaApi::~MayaApi()':
maya_composite1.cxx:(.text+0x1de3): undefined reference to `MLibrary::cleanup(int)'

Maybe MLibrary::cleanup() is in some additional library we don’t have on the list yet?

David

according to the maya documentation MLibrary is part of the OpenMaya library. but, I just discovered that there’s two Open Maya libraries - there’s libOpenMaya.so, the shared library, and libOpenMayalib.a, a static one. nm tells me that the .a has the symbols for MLibrary. weird. ok, will try that tonight …