the more complicated part is the first one, as it requires to actually open the file that dlopen()/LoadLibrary() could not open and inspect the binary data to understand the architecture of the blob.
Yes, but I already have the code (I wrote it for [vstplugin~]). It's ~300 lines of C++, I just have to port it to C.
https://git.iem.at/pd/vstplugin/-/blob/master/vst/Plugin.cpp#L352
It maybe overkill, though. Dunno...
Christof
On 28.05.2020 20:53, IOhannes m zmölnig wrote:
to answer martin's question: deken will print platform information at startup time, albeit the printout is only visible if you raise the verbosity in the Pd-console.
something like:
[deken] Platform detected: Linux-x86_64-float32 [deken] Platform re-detected: Linux-amd64-float32
this is basically the information you asked for, with a few caveats:
- if you clear the Pd-console, the printouts are gone.
- there's some naming inconsistency (e.g. in the example above you see
both "amd64" and "x86_64" which is really the same.
- it might be confusing to see *two* lines with essentially the same
information.
the first line is the result of an architecture detection on the GUI-side. however, the GUI might have a *different* architecture than the Pd-core (and the latter matters when it comes to loading externals). therefore the Pd-core sends its architecture to the GUI as well, triggering the 2nd output.
i guess the printout could be improved, i'm open to suggestions.
On 5/28/20 7:22 PM, Christof Ressi wrote:
I have some cross-platform CPU architecture detection code which I code port to Pd, so that we could have more descriptive error messages.
hmm, i don't think *that* is the problem here. it's quite clear which binaries Pd can load at compile time (as is reported by the 2nd line in the deken initialisation; see above)
but i think your idea is to improve the error message along the lines of:
failed to load foo.dll (the library is 32bit, but Pd is a 64bit process)
the trivial part is the 2nd one ("this Pd is 64bit"). the more complicated part is the first one, as it requires to actually open the file that dlopen()/LoadLibrary() could not open and inspect the binary data to understand the architecture of the blob.
the deken cmdline utility can do this, but it utilizes several specialized libraries for the task. i think embedding such libraries into Pd would be an overkill for the problem.
mgasf IOhannes
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev