Menu
▾
▴
#455 Setting externals file extension, check for ANDROID platform
The Android GCC toolchain #defines linux, so the Android specific branch was never being hit. Moving the check above Linux fixes it.
Before this patch external extensions ".l_i386" and ".pd_linux" are checked for on Android. This patch will accept either ".l_arm" or ".pd_linux", so the externals built by PdCore will still work.
It doesn't address the issue of Android x86.
Should probably add a check for arm vs x86 architecture too, but I haven't been able to find documentation of the architecture macros.
Discussion
Anonymous
View and moderate all "patches Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Patches"
View and moderate all "patches Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Patches"
What about just defining '.so' has a possibility if __linux__, __FreeBSD__, __FreeBSD_kernel__, __OpenBSD__ are defined, then people can choose to manage the architecture in their own way.
Those file extension have a lot of issues as they are, for example, no other program for Darwin/MacOSX uses per-arch file extensions: they use universal binaries. For this reason , Pd-extended on Mac OS X only uses .pd_darwin and universal binaries and ignores .d_fat and .d_ppc. Also, Pd's .l_ia64 does not actually mean ia64 arch but instead amd64/x86_64, so that file extension is just wrong.
<flames>
"Those file extension have a lot of issues as they are, for example, no other program for Darwin/MacOSX uses per-arch file extension"...what exactly is the "lot of issues" here? no other program for Darwin/MacOSX is called "Pd", and still this is no issue.
</flames>
<moreflames>
if Pd-extended ignores binary files that it could happily load and by doing so breaks compatibility with Pd-vanilla, i would say this is a bug in Pd-extended.
</moreflames>
In response to #1: very few people are using .d_ppc and .d_fat files with Pd vanilla.
and #2: patches welcome
thanks for the respone.
ad #1: very few people using .d_ppc/.d_fat is not really creating any "problems", is it?
ad #2: will do (though afaict, PdX has a patch that actively removes the functionality; should i create a patch that re-adds the extensions or should i modify (eventually remove) the patch that erroneously removes the extensions?
Personally, I think its a waste your time and mine. Its been discussed, check out the archives for the problems it causes. I've long since moved on. We should be putting this energy solving the issue in this tracker, rather than beating the .d_ppc/.d_fat dead horse.
My intention in having the wierd extensions was to permit people to distribute patches (such as realizations
of pieces) containing in-house externals that can run under any Pd version and any OS. In this context
"externs" can be directories containing the various binaries which Pd distinguishes by filename. OTOH, Pd
distributions themselves run on a single OS and architecture so don't need the disambiguation, although in
my experience it hasn't been harmful (Hans has experienced otherwise in the context of Pd extended though :)
So Pd is sort of stuck allowing both types of extensions.
File extensions are very OS-specific. The Linux extensions are fine (except perhaps the l_ia64 being the wrong arch). Mac OS X does not need different ones since you can build universal "fat" binaries.
One example of a problem caused by adding more extensions is that it increases the load time since Pd will have to check for more variations on filenames. There are other issues, I don't remember them, but they're in the archives.
for the record, here are the relevant threads i found in the archives:
- http://lists.puredata.info/pipermail/pd-list/2009-01/067498.html
- http://lists.puredata.info/pipermail/pd-list/2009-07/071476.html
as you will see, the only real issue that was ever raised was the increased load-time when adding more and more extensions. all the "other" issues where always referred to as "there are other issues which i don't remember right now, check the archive", without ever giving evidence that there are indeed other issues.
How about we instead solve the problem listed above in this bug report? I think we should have the add an #else that sets the file extension to ".so". The generic .dll extension has been used for Windows since forever and I don't hear about problems there. And then ditch the __ANDROID__ section and move the ARM arch under the __linux__ section.
The file extensions are a mess in terms of accurate naming. __GNU__ and __FreeBSD_kernel__ are not Linux at all, and they are set to use .pd_linux. I don't think the kernel even matters for generic externals, it is probably the libc that matters, so it should be something like .gnu_i386 or .bsd_i386. Or maybe its the binary format that's more important, i.e. .elf_i386 and .mach_i386. Makes me think this approach to naming is just fundamentally flawed.
Lastly, IOhannes, the key part that you are missing about .d_fat/.d_ppc is that they do not solve any problems. So something that causes a minor problem, but solves nothing seems pretty worthless to me. Even discussing it as much as we have seems like a waste of time.
patch to apply using 'git am'
I attached a patch for my solution to the problem at hand: Android file extensions. It will also fix file extensions for GNU/Linux on ARM. The original code would make GNU/Linux/ARM use .l_i386.
This also adds '.so' as the default extension when the particular case is undefined. I think this is better than having the default be nothing at all, and it should be quite safe since .so is the standard extension for shared libraries on GNU systems, BSD systems, Android, and others.
accepted (0.44)