Hi

Is there anyone who can help with compiling pd for an x86_64 processor. I have used the instructions in the install.txt with it. I using Fedora Core 2 with the latest upgrades (asuming this also means ALSA) and JACK.

I do:

./configure --enable-jack
make depend
make install

Everything is fine untill the make install command after which it gives me loads of warning saying something to the effect of:

x_gui.c: In function `savepanel_new':
x_gui.c:233: warning: cast from pointer to integer of different size

After lots of these it ends with:

bonk~.c: In function `bonk_perform':
bonk~.c:481: warning: cast to pointer from integer of different size
make[1]: *** [bonk~.pd_linux] Error 1
make[1]: Leaving directory `/home/cocteau/download/pd-0.37-1/extra/bonk~'
make: *** [externs] Error 2


Can anyone tell what this means?

Thanks in advance

not really a useful reply, but i'm having the same difficulties. I'm guessing that something in the source code specifically is written for the 32 architecture. For instance on a 32 bit machine integers and floats are a specific size but in a 64 bit machine that size is different. Perhaps Puckette has some variables that are created on a low level so that he has specified the size to be that which is normally used in a 32 bit environment.

Hopefully when (if) I get the time i can take a look at the source code and see if I can find anything out. A cursory look at x_gui.c says that the line in quesiton reads "sprintf(buf, "d%x", (t_int)x);" . sprintf is this buffer writting mechanism...here he is writting something into the buffer and converting it to his own type (t_int), through explicit type casting, in the process.

He defines t_int in m_pd.h where he takes care of making sure all the precompiler junk is squared away.
"#ifdef __alpha__
typedef long t_int;
#else
typedef int t_int;
#endif"

Perhaps someone with experience in multiple architectures could help...or perhaps someone wants to bug a pd-extended developer or even Puckette himself.

My guess at a solution is to get the compiler to use a 32 bit word ("word" is the term for the size a variable takes up) and not a 64 bit word for all variables. (not quite sure if this is really possible though). You might also try compiling it on a 32 bit machine and copying the whole pd directory over to your 64 and giving that a shot.

Also you may want to change the makefile so that it points entirely to ../libs64/ or entirely to ../libs/

i don't have an idea myself, but since guenter (geiger) has ported pd a long time ago to alpha-architecture and he is maintaining the debian-packages (which run on 11 different architectures including arm and ia64) he is definitely the one to ask

i believe you can try "make -m32" and it will make pd as a 32 bit binary....but you might want to "man make" to see what other switches there are.

eh, I was wrong. I did some poking around and found out that porting an app to be 64 bit can be much more difficult than it looks...depending on how it was written. In a 64 bit architecture certain variables are stored with a 64 bit word length and some with a 32 bit word length and when there is typecasting involved it gets even more complicated.

I got PD working on the amd64 machine and if used the 64 bit libs. Here is what i did:

1. i used pd-extended with the source from the pd-extended sourceforge page.
2. extract the archive somewhere...
3. enter puredata/bin and run ./configure
4. edit "Makefile" so that paths read /usr/X11R6/libs64, /usr/libs64, etc. (I believe there are three that you have to change.
5. make
6. run pd

The only problem i have so far (and it is a big one) is that it isn't reading the example files (bells, voice, and voice2) because it says they have malformed headers or something. I hope its just the files and not the program itself, because the work i do relies on bringing in sound files. Still, I think that if the program was broke i would have seen at least a warning when compiling.

Thank you for this. It compiled without problems and almost without warnings. Gave me a couple of typecast warnings but they weren't many. Also I could only find two places in the makefile to change but hey, it's working.

I don't know what objects are using the soundfiles as examples, so I can't help you with that. They play fine in xmms here, if that's any help and I didn't find any warnings regarding them when compiling.

In ./pd/docs/audio.examples/ the sampler patches are ones that take in soundfiles...

The only problem i have so far (and it is a big one) is that it isn't reading the example files (bells, voice, and voice2) because it says they have malformed headers or something. I hope its just the files and not the program itself,

Unfortunately this is very likely a problem with the program. Different processors expect different alignment of words in memory. For example, if you declare a C data structure of { int32, int8, int32 } and one processor A expects int32's to be on 16bit boundaries and another processor Bexpects int32's to be on 32bit boundaries, the C data structure will be represented in memory differently:

A: { int32, int8, pad8, int32 }
B: { int32, int8, pad8, pad8, pad8, int32 }

The padding is just empty space to align the data on the correct word boundaries.

The problem occurs when the program's assumptions of data layout in memory do not match what the compiler does, and instead of reading a file format word by word and populating the data structure, reads a chunk of data and assumes that it matches the data format in memory.

Compare this with problems transferring data between big-endian and little-endian machines - you have to translate to and from the file format, not assume that the data in the file will match the data in memory for all architectures.