PSPunch wrote: > Hi Claude, > > > I have lua.dll and pd.lua both in my "extra" directory now. > > A little excerpt of the output of -stderr -verbose.. > This is when trying to create a [lua] object. > > -------- > tried C:\Program Files\pd\extra\flatspace\lua.dll and failed > tried C:\Program Files\pd\extra\lua.dll and succeeded > C:\Program Files\pd\extra\lua.dll: couldn't load
hmm, very uninformative error message. any windows experts know what this error means? > Did you imply that if pd.lua not being recognized is the case, there > should be an output mentioning it? yes. that error message looks like: """" error: lua: error loading `pd.lua': canvas_open() failed error: lua: loader will not be registered! """" to fix it, add the directory containing pd.lua into the -path (TODO: look relative to the pdlua binary, so that you don't need to fiddle with path settings) > The file seems to be found. Yes. > It seems like it is not able to load. Indeed, but why? >>> As a base line, I am using the following combination of files. >>> >>> - MinGW for building >>> - Using pd.dll from pd-extended 0.40.3-20080721 (Win binary package) >>> - Using m_pd.h from pd-0.40.3 source what is pd-extended compiled with? internet search suggests that there might be incompatibilities between Microsoft and GNU compilers, but now I'm thinking the below is more likely the cause: >>> Info: resolving _garray_class by linking to __imp__garray_class >>> (auto-import) >>> Info: resolving _s_ by linking to __imp__s_ (auto-import) Guessing now: pd.dll doesn't export "s_" or "garray_class", which means externals can't use them like on the unixoid OSs? That would be "somewhat disadvantageous" :( Any windows people have any ideas? Claude _______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev