geiger wrote:
On Tue, 20 Dec 2005, Miller Puckette wrote:
OK, I'm liking "pd_win32" more and more. If Microsoft makes a new dll format that permits bundling, that would be a good moment to change the suffix again...
Which leads me to a question I always wanted to ask, but never dared to. What should be done on platforms that support more than one architecture, like linux or macosx ? Obvioulsy a xxx.pd_linux from a powerpc machine is not usable on a pentium, which makes bundling impossible. One would need a pd_linux_368, pd_linux_ppc, etc ...
I think .pd_lib for a suffix on all platforms is a good idea.
Then inside pd/src would be a set of platform-specific subdirectories containing the code that only works on one platform, replacing the #ifdef system currently in use, which is difficult to maintain outside of m_pd.h. (s_loader.c currently has six ifdef variants and uses six file extensions).
The makefile would access the appropriate directory and install would put the libraries in the right place. So in a few sols when Ps and PPCs are only toxic scrap all that needs to be changed to run on hyperspintiums is in one place and the files will have the same names...
Given that files with .pd suffix have the same function for all platforms, using .pd_ext for externs and maybe .pd_lib for libraries makes sense to me.
If you have the wrong one, it will probably fail to load rather than crashing pd.
Each library format is identifiable* (e.g. the first 8 bytes of a 32-bit intel .pd_linux looks like 7F 45 4C 46 01 01 01 00 or 0x7f "ELF", the first 2 bytes of a .dll are 4D 5A or "MZ") so user-friendly code could even determine what platform the thing was for before attempting to load it. Currently in sys_load_lib the file is opened once before it is loaded anyway, just to see if it exists.
Martin
_________________________________________________________ *From the ELF Specification (http://www.skyfree.org/linux/references/ELF_Format.pdf):
The first 4 bytes of the file hold a "magic number" identifying the file as an ELF object file. They are {0x7f, 'E', 'L', 'F'}. Following these are bytes for 32/64-bit big/little-endian, etc.
typedef struct { unsigned char e_ident [16]; //"The initial bytes mark the file //as an object file and provide //machine-independent data //with which to decode and interpret the //file’s contents." Elf32_Half e_type; // should be ET_DYN 3 Shared object file Elf32_Half e_machine; // e.g. EM_386 3 Intel 80386 ... } Elf32_Ehdr;