[PD-dev] help me with my DLL snafu

[Martin Peach]

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;