Happy to help! Glad to hear it worked for you. I suppose the forum automatically removes special characters like ~ from filenames when they're uploaded... good to know for future reference.
As alexandros noted (much) earlier in this thread, d_fat is another valid Mac OS format. I see 2 versions of bsaylor available for Mac via "Find externals", perhaps the one you downloaded was a d_fat version? In any case, if it works, it works!
Indeed, if you’ve read the long thread above you know that this was my first time compiling as well, so I can definitely relate to the feeling of flying blind!
5 months later I can’t quite remember which edits I made to the bsaylor makefile, but I’m pretty sure this one is the final version that ended up working for me:
If memory serves, I removed all objects other than pvoc~.c and partconv~.c from “SOURCES” (I think because the others were already working in 64 bit?), and also made sure the path pointed to “PD_PATH = /Applications/Pd-0.47-1-64bit.app/Contents/Resources”. Then I ran “make” (with the patched pvoc~.c in the same directory as the makefile, and fftw installed as noted), and got my new pvoc~.pd_darwin file to replace the old (non-64 bit) version in my bsaylor folder.
It was rather satisfying to successfully compile, but I still can’t say that I understand most of the errors that pop up during the process. It’s also entirely possible I’m forgetting other key steps that I took, as I was beating my head against this for days at the time. If it helps, here’s the darwin file that I got working on 64 bit:
Success! My internet has been down for a week, so had to wait until today before I could try installing fftw via Homebrew. I was able to do so without much trouble, and after re-editing the bsaylor makefile & recompiling, the patched version of pvoc~.pd_darwin is up & running properly in 64-bit!
I really appreciate your help! I wouldn't have known where to begin without your helpful advice.
Thanks for those links to compiling info, much appreciated!
I think I'm getting closer... I realized that the makefile is pointing to /include because that's where m_pd.h is located in Pd-Extended, but that file is in /src in the vanilla versions I'm using. I tried changing that path, and also tried pointing to a version of Pd-Extended that I have, but now I get this:
fatal error: 'fftw3.h' file not found
The bsaylor library comes with a /libs folder containing libfftw3.3.dylib and libfftw3f.3.dylib (required for partconv~ and pvoc~). Perhaps the makefile is looking for these libraries when compiling? I don't see a fftw3.h file anywhere in the source code of pd (including extended).
OK, so applying the pvoc~ 64-bit patch was rather easy:
patch pvoc~.c < bsaylor_pvoc~.c.patch
But unfortunately I'm back to my original problem—the makefile that is included with bsaylor throws a bunch of errors when I try to compile the library, and I don't have any expertise (besides a few days ago with iem_dp) to guide my troubleshooting. I spent a good chunk of the day editing everything I could make sense of in the makefile (changing the path from Pd-extended.app to Pd-0.47-1-64bit.app, deleting things that seemed to be causing warnings), but still no luck.
clang: error: unknown argument: '-ftree-vectorizer-verbose=2' ... fatal error: 'm_pd.h' file not found ... /usr/include/sys/cdefs.h:761:2: error: Unsupported architecture ... In file included from /usr/include/stdint.h:52: /usr/include/sys/_types.h:55:9: error: unknown type name '__int64_t' typedef __int64_t __darwin_blkcnt_t; /* total blocks */ In file included from /usr/include/stdint.h:52: /usr/include/sys/_types.h:68:9: error: unknown type name '__darwin_natural_t' typedef __darwin_natural_t __darwin_mach_port_name_t; /* Used by mach */
Does anybody know of a very simple step-by-step beginner's guide to compiling objects/libraries from source? I see the words "just recompile for your system" quite a bit, but even with several days of unguided googling, I can't say I feel like I understand even the basics. (other than running a makefile & hoping for the best...) I'm not averse to rolling up my sleeves & learning how to do it, rather than bug everyone for help every time I run into an error.
Aha! You're correct, I was pointing to the 32 bit version of Pd-0.47-1. I tried once again with Pd-0.47-1-64bit (updating the PD_INSTALL_PATH in the makefile), and it seems to have compiled successfully! But, as you point out, the library can only load in the 64 bit version of pd.
The only reason I've been temporarily sticking with the 32 bit version is because my main performance patch uses a few libraries & objects which don't seem to work in 64 bit. But I would like to migrate at some point, as it seems like CPU performance is somewhat better in 64 bit (and maybe also other benefits that I don't know about?).
Unfortunately that brings me back to a similar noob problem: I use bsaylor's pvoc~ quite a bit, and although there is a fix which updates it to be 64-bit compliant (https://lists.puredata.info/pipermail/pd-list/2015-06/110377.html), I don't know how to apply a .patch file to a .c file & compile for my platform. I'll keep searching online & see if I can teach myself, but if anyone has any quick pointers for how to pull this off, I'd be very grateful!
Thanks for the idea; I removed -Werror from the makefile_darwin CFLAGS and tried it again. As you indicated, the unused parameter warnings didn't generate errors, so the process went as far as creating .0 files for every object in the library.
But here's where it seems to have run into more trouble (I think):
touch iem_dp.c cc -DPD -DUNIX -g -Wall -W -Wno-unused -Wno-parentheses -Wno-switch -O2 -fno-strict-aliasing -I. -I"/Applications/Pd-0.47-1.app/Contents/Resources"/src -DPD -I. -I"/Applications/Pd-0.47-1.app/Contents/Resources"/src -c -o iem_dp.o iem_dp.c :: symtodp.o dptosym.o dptohex.o ftohex.o vline~~.o samphold~~.o wrap~~.o phasor~~.o print~~.o add__.o sub__.o mul__.o div__.o add~~.o sub~~.o mul~~.o div~~.o tabwrite_dp.o tabread_dp.o tabread4_dp.o tabwrite~~.o tabread~~.o tabread4~~.o max__.o min__.o max~~.o min~~.o random__.o delay~~.o iem_dp.o cc -bundle -bundle_loader "/Applications/Pd-0.47-1.app/Contents/Resources"/bin/pd -o iem_dp.pd_darwin *.o -ldl -lm -lpthread ld: warning: ignoring file /Applications/Pd-0.47-1.app/Contents/Resources/bin/pd, missing required architecture x86_64 in file /Applications/Pd-0.47-1.app/Contents/Resources/bin/pd (2 slices) Undefined symbols for architecture x86_64: "_atom_getfloatarg", referenced from: _add___new in add__.o _add_tilde_tilde_new in add~~.o _delread_tilde_tilde_new in delay~~.o _div___new in div__.o _div_tilde_tilde_new in div~~.o _max_dp_new in max__.o _max_tilde_tilde_new in max~~.o ... "_atom_getsymbolarg", referenced from: _delread_tilde_tilde_new in delay~~.o "_bug", referenced from: _tabwrite_tilde_tilde_stop in tabwrite~~.o _tabwrite_tilde_tilde_perform in tabwrite~~.o "_class_addanything", referenced from: _symtodp_setup in symtodp.o "_class_addbang", referenced from: _add___setup in add__.o _div___setup in div__.o _dptohex_setup in dptohex.o _dptosym_setup in dptosym.o _max_dp_setup in max__.o _min_dp_setup in min__.o _mul___setup in mul__.o```
...etc, omitting a long list of 50 or so undefined symbols, ending with:
ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) make: *** [all] Error 1
Not sure what sense to make of that... missing required architecture x86_64 seems significant?
Thanks for your insights, Alexandros!
I did indeed run into that problem with the naming of Pd-0.47-1.app; when I first tried the pd_darwin makefile, I got an error that the compiler couldn't find m_pd.h, so I figured the path might need to be updated.
I tried makefile_d_fat as well (with the correct Pd /src path), and got even more errors in addition to the same unused parameter errors as the darwin version.
/usr/include/sys/cdefs.h:761:2: error: Unsupported architecture
I'm not sure whether I have any other compilers I can try (I do see "gnumake" in my newly-downloaded Command Line Tools, don't know if that's any different than the other "make"? this is literally my very first attempt at compiling).
But if there is indeed a problem with the source code, I suppose it could be a moot point. I did try deleting symtodp & running the darwin makefile again—this time it got as far as creating a dptosym.o file, but it ran into the unused parameter error once again on dptohex.c and gave up.
I've been trying for a solid few days to get iem_dp working on my Mac (for double precision lookup of long arrays), but I seem to have reached the limits of my abilities.
I downloaded the library from https://git.iem.at/pd/iem_dp/tree/master which contains the helpfiles, .c files for each object, and four makefiles for different architectures (including makefile_darwin, which I assume is the one I want for MacOS 10.12. I have no experience with compiling files, so I tried downloading Command Line Tools, and ran "make -f makefile_darwin" in Terminal, but I only get errors (see below).
Does anyone know what the problem might be? Or, does anyone happen to have iem_dp compiled for pd_darwin?
touch symtodp.c cc -DPD -DUNIX -g -Wall -W -Werror -Wno-unused -Wno-parentheses -Wno-switch -O2 -fno-strict-aliasing -I. -I"/Applications/Pd-0.47-1.app/Contents/Resources"/src -DPD -I. -I"/Applications/Pd-0.47-1.app/Contents/Resources"/src -c -o symtodp.o symtodp.c symtodp.c:86:50: error: unused parameter 's' [-Werror,-Wunused-parameter] static void symtodp_list(t_symtodp *x, t_symbol *s, int ac, t_atom *av) ^ symtodp.c:96:61: error: unused parameter 'ac' [-Werror,-Wunused-parameter] static void symtodp_anything(t_symtodp *x, t_symbol *s, int ac, t_atom *av) ^ symtodp.c:96:73: error: unused parameter 'av' [-Werror,-Wunused-parameter] static void symtodp_anything(t_symtodp *x, t_symbol *s, int ac, t_atom *av) ^ symtodp.c:120:37: error: unused parameter 'x' [-Werror,-Wunused-parameter] static void symtodp_free(t_symtodp *x) ^ 4 errors generated. make: *** [symtodp.o] Error 1```