[WIP] --How to handle Windows 32 and 64 bit externals

[Lucarda]

Extracted from @umlaeute @ #38 :

that problem only exists if somebody wants to use both 32bit and 64bit Pds on the same machine.

in theory Pd already has a mechanism to care for this: use a different filename extension for each platform/architecture. e.g. on linux we use .pd_linux instead of the (more standard) .so.

on w32 we could already use .m_i386 instead of the (more standard) .dll. so far nobody has adopted to this. also there currently isn't a .m_amd64 searched for on w64.

so, i think:

• W32 32bit externals should use the .m_i386 extension instead of .dll
• Pd ought to support the .m_amd64 extension for w64
  • for now "W32 64bit" (W64) externals should use .dll as the extension

that's probably a much better scheme than using different paths for different architectures, as it allows a single deken-external to contain multiple architectures.

[katjav]

that's probably a much better scheme than using different paths for different architectures, as it allows a single deken-external to contain multiple architectures.

That could be extended to Linux as well. Also see issue #30. We could set 'alternative extensions' (where available) as the default to facilitate 'fat libraries'. I guess that people will frown upon such a decision though.

[umlaeute]

yes, it should be handled (consistently) on all platforms, at least those that don't natively support fat binaries (everything but OSX).

@katja i'm not sure abut which part of which decision people would frown upon.

[Lucarda]

Although I like the idea of changing file extension I believe we are going to clash with other [external] resources. For example the pthread implementation of Msys2 has the same name for w32 and w64: “libwinpthread-1.dll” and we are going to find same clash with other dependencies.

Eg: Even if we had:

• coll.dll
• coll.m_i386? <-- I beleive in linux is: coll.l_i386
• pthread.dll
• pthread.m_i386

Would be nice to test if a simple rename of a dll extension will effectivly allow this file to be called (windows auto-magic?). Will try to test but I’m expecting negative results.

[umlaeute]

no, you cannot just rename libwinpthread-1.dll to libwinpthread-1.m_i386 (or libwinpthread-1.fudeldudel and expect it to work.

Pd manually does special handling of the extensions, but the windows dependency resolution will not.

[Lucarda]

How horrible will be if Pd adds w64 to the search path.

trying cyclone/coll.dll ...not found
trying cyclone/w64/coll.dll ...succeded

[umlaeute]

very horrible.

[Lucarda]

Obviously
trying cyclone/coll.dll ...not found

is not true as it will be there and it will be found but incompatible. : (

[Lucarda]

Are you sure is "very horrible"?

[umlaeute]

yes: very

[Lucarda]

So I guess users that wants 32 & 64 versions of Pd to coexist should do their appropriate -path -lib thing.

[umlaeute]

well, they could install the 32bit externals into the system-specific path (%CommonProgramFiles%/Pd) and the 64bit externals into the user-specific path (%AppData%\Pd).
this way, they don't have to play with -path or -lib at all.

[Lucarda]

Good solution. Will test asap... : )

[umlaeute]

i'd rather say its a somewhat sane hack (but far from a good solution)

[katjav]

@katja i'm not sure abut which part of which decision people would frown upon.

Quoting @umlaeute as in https://lists.puredata.info/pipermail/pd-dev/2015-02/020082.html:

and the extensions in Pd are already a big mess; any other environment
i know that supports loading of binary plugins, uses the OS's default
extensions: .so, .dylib, .dll; using non-standard extensions is often
very inconvenient...so please do not add another one.

I'm not personally opposed to the 'carnival of extensions' (quoting Miller in the same mailing list thread). It is very useful for projects where you want to supply binaries for 'all' platforms.