[PD-dev] Problem building pdlua on MinGW

[PSPunch]

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
tried .\lua\lua-meta.pd and failed
tried C:\Documents and Settings\gyokimae\Application 
Data\Pd\lua\lua-meta.pd and failed
tried C:\Program Files\Common Files\Pd\lua\lua-meta.pd and failed
--------

Did you imply that if pd.lua not being recognized is the case, there 
should be an output mentioning it?

The file seems to be found.
It seems like it is not able to load.


--
David Shimamoto


> PSPunch wrote:
>> This may or may not be a question specific to pdlua.
> 
> I have no mingw machines, but I can try to answer.
> 
>> 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
>>
>>
>> Although I am not fully aware of the compatibilities between binaries
>> built on different compilers, if the above combination is an obvious no
>> no, that may be the problem. (The last two lines of the output seem a
>> bit suspicious)
> 
> No clue on this.
> 
>> Attempting to build pdlua, the build completes but leaving me with a dll
>> which fails to load on pd-extended 0.40.3-20080721 (Windows installer).
> 
> More info on this would be useful - ie, what error messages are 
> produced, what is printed if you start pd from the console with the 
> -stderr -verbose flags (in case some system messages don't go to Pd's 
> window)?
> 
> The main pdlua-related problem I can think of is not having pd.lua in 
> Pd's -path, but pdlua should print out messages to that effect if it 
> can't find it.
> 
> [snip]
> 
>> Info: resolving _garray_class by linking to __imp__garray_class
>> (auto-import)
>> Info: resolving _s_ by linking to __imp__s_ (auto-import)
> 
> No idea about these either.
> 
> 
> Claude