[PD-dev] 64-bit vs 32-bit info

[Christof Ressi]

> 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 at lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20200528/f3813de2/attachment-0001.html>