makepanda patch and thirdparty issues

Hi,

I sent this patch:

dev.gentoo.org/~chriswhite/panda … anda.patch

to the email address listed in LICENSE as per reqeuest, but I’m including it here for consistancy.

This patch basically addresses the problem of lib/lib64 on 64 bit architecture by allowing to override the lib directory. I applied the patch and and tested it out. It works ok from what I can tell.

Also, it allows the user to ovverride the basic CFLAGS/CXXFLAGS used during the compilation. This helps address the need for abi specific compilation, as well as being able to add -fPIC in for certain architectures that require it (see the amd64 compilation thread for more details on that). The current code simply pulls from the environment variables CFLAGS and CXXFLAGS if they exist. If they don’t, it uses the default. This let’s more advanced users have control over the process. I also created a OPTIMIZE = 0 situation in the case that compile flags have optimizations in them and don’t want to collide.

One more thing I’m sort of confused on is the thirdparty directory. Let me explain (some lines removed for readability):

chris@localhost ~/panda3d-1.0.4/thirdparty/linux-libs-a $ ls -R1
.:
fftw
fmod
nspr
nvidiacg
vrpn

./fftw/lib:
libfftw.a
librfftw.a

Where did rfftw come from? I’ve been trying to find out so I can use my own libs that I compiled from fftw, but I seem to be unable to find out what enables this.

./fmod/lib:
libfmod-3.74.so

Having this as version specific seems problematic. What’s wrong with just a simple -lfmod style link?

./nspr/lib:
libpandanspr4.so
libpandaplc4.so
libpandaplds4.so

Are this panda specific libraries? I know there’s an nspr library already installed on my system. However judging from the naming, it doesn’t look like I can replace them with my own libs.

Also, how were these compiled. For i386? If so it seems that simply copying over the libs would be the only choice, and in that case nspr wouldn’t work unless they weren’t “special libs” (which is what they appear to be).

Let me know if anything I said doesn’t make sense here, and thanks ahead of time.

Just out of curiosity… are you trying to build for a different architecture? PPC or something like that?

‘rfftw’ is part of the fftw distribution. I vaguely recall that when I downloaded the source for fftw and compiled it, it built rfftw as well. Now, if my memory serves me correctly, we’re using version 2.15 of fftw, not version 3, which is a complete redesign.

As for libfmod — I think I just used the first thing that I could get to work. I remember when I wrote that code I was still struggling with getting makepanda operational. You’re right, there’s probably a better way.

As for libpandanspr — it’s just nspr. Several of the operating systems we support do include NSPR, but they seem to include some older version of it that doesn’t work with panda. I figured the easiest way to avoid version conflicts was just to recompile it from source and rename it. I believe there’s a single line in the NSPR makefile that allows you to change the name of the library.

[snip]
Just out of curiosity… are you trying to build for a different architecture? PPC or something like that?
[/snip]

not just ppc, but maybe other architectures as well (sparc, amd64, alpha, etc.). The means exist, such as custom cflags for specifying various abi and architecture specific options, and the LIBDIR variable for working with lib/lib64 variants.

[snip]
‘rfftw’ is part of the fftw distribution. I vaguely recall that when I downloaded the source for fftw and compiled it, it built rfftw as well. Now, if my memory serves me correctly, we’re using version 2.15 of fftw, not version 3, which is a complete redesign.
[/snip]

Ok, so this probably wouldn’t work as far as using external libraries (because of the complete design revision?).

[snip]
As for libfmod — I think I just used the first thing that I could get to work. I remember when I wrote that code I was still struggling with getting makepanda operational. You’re right, there’s probably a better way.
[/snip]

This I think can be like -ltiff and friends, where it pulls from non-third party with a non version specific library suffix. I haven’t had a chance to try that out as of yet.

Let me know if there are ways I can help as well. I’ve sort of got my feet wet with makepanda.py (as well as some previous python scripts), so working on this would be interesting :slight_smile:.

[snip]
As for libpandanspr — it’s just nspr. Several of the operating systems we support do include NSPR, but they seem to include some older version of it that doesn’t work with panda. I figured the easiest way to avoid version conflicts was just to recompile it from source and rename it. I believe there’s a single line in the NSPR makefile that allows you to change the name of the library.
[/snip]

Ok, that’s good to know as well. I was sort of wondering about that. I think probably the best thing to do would be to include a specification file with a list of packages and relevant version numbers. That way distribution maintainers/users could know exactly what they need.

Hi Chris,

The link above is broken. I’m not sure if the patch was applied, but it sounds like it would be useful. I’m on ubuntu 11.10 and i’m getting abi errors.

darKoram

This thread is ancient history. Panda has been building on x64 architectures for years.

David