Hi,
This may or may not be a question specific to pdlua. 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)
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).
Things I have done, - Modify Makefile.static; comment out lines to specify building on MinGw - Manually download lua-5.1.3.tar.gz as my MinGW setup did not have wget originally used in the Makefile.
I would appreciate advise on how I may be able to get this running.. Thanks.
------------------------- $ make -f Makefile.static tar xzf lua-5.1.3.tar.gz touch lua-5.1.3/unpack.stamp make -C lua-5.1.3 mingw local make[1]: Entering directory `/home/gyokimae/pdlua-0.5/lua-5.1.3' cd src && make mingw make[2]: Entering directory `/home/gyokimae/pdlua-0.5/lua-5.1.3/src' make "LUA_A=lua51.dll" "LUA_T=lua.exe" \ "AR=gcc -shared -o" "RANLIB=strip --strip-unneeded" \ "MYCFLAGS=-DLUA_BUILD_AS_DLL" "MYLIBS=" "MYLDFLAGS=-s" lua.exe make[3]: Entering directory `/home/gyokimae/pdlua-0.5/lua-5.1.3/src' gcc -O2 -Wall -DLUA_BUILD_AS_DLL -c -o lua.o lua.c gcc -O2 -Wall -DLUA_BUILD_AS_DLL -c -o lapi.o lapi.c gcc -O2 -Wall -DLUA_BUILD_AS_DLL -c -o lcode.o lcode.c gcc -O2 -Wall -DLUA_BUILD_AS_DLL -c -o ldebug.o ldebug.c gcc -O2 -Wall -DLUA_BUILD_AS_DLL -c -o ldo.o ldo.c gcc -O2 -Wall -DLUA_BUILD_AS_DLL -c -o ldump.o ldump.c gcc -O2 -Wall -DLUA_BUILD_AS_DLL -c -o lfunc.o lfunc.c gcc -O2 -Wall -DLUA_BUILD_AS_DLL -c -o lgc.o lgc.c gcc -O2 -Wall -DLUA_BUILD_AS_DLL -c -o llex.o llex.c gcc -O2 -Wall -DLUA_BUILD_AS_DLL -c -o lmem.o lmem.c gcc -O2 -Wall -DLUA_BUILD_AS_DLL -c -o lobject.o lobject.c gcc -O2 -Wall -DLUA_BUILD_AS_DLL -c -o lopcodes.o lopcodes.c gcc -O2 -Wall -DLUA_BUILD_AS_DLL -c -o lparser.o lparser.c gcc -O2 -Wall -DLUA_BUILD_AS_DLL -c -o lstate.o lstate.c gcc -O2 -Wall -DLUA_BUILD_AS_DLL -c -o lstring.o lstring.c gcc -O2 -Wall -DLUA_BUILD_AS_DLL -c -o ltable.o ltable.c gcc -O2 -Wall -DLUA_BUILD_AS_DLL -c -o ltm.o ltm.c gcc -O2 -Wall -DLUA_BUILD_AS_DLL -c -o lundump.o lundump.c gcc -O2 -Wall -DLUA_BUILD_AS_DLL -c -o lvm.o lvm.c gcc -O2 -Wall -DLUA_BUILD_AS_DLL -c -o lzio.o lzio.c gcc -O2 -Wall -DLUA_BUILD_AS_DLL -c -o lauxlib.o lauxlib.c gcc -O2 -Wall -DLUA_BUILD_AS_DLL -c -o lbaselib.o lbaselib.c gcc -O2 -Wall -DLUA_BUILD_AS_DLL -c -o ldblib.o ldblib.c gcc -O2 -Wall -DLUA_BUILD_AS_DLL -c -o liolib.o liolib.c gcc -O2 -Wall -DLUA_BUILD_AS_DLL -c -o lmathlib.o lmathlib.c gcc -O2 -Wall -DLUA_BUILD_AS_DLL -c -o loslib.o loslib.c gcc -O2 -Wall -DLUA_BUILD_AS_DLL -c -o ltablib.o ltablib.c gcc -O2 -Wall -DLUA_BUILD_AS_DLL -c -o lstrlib.o lstrlib.c gcc -O2 -Wall -DLUA_BUILD_AS_DLL -c -o loadlib.o loadlib.c gcc -O2 -Wall -DLUA_BUILD_AS_DLL -c -o linit.o linit.c gcc -shared -o lua51.dll lapi.o lcode.o ldebug.o ldo.o ldump.o lfunc.o lgc.o llex.o lmem.o lobject.o lopcodes.o lparser.o lstate.o lstring.o ltable.o ltm.o lundump.o lvm.o lzio.o lauxlib.o lbaselib.o ldblib.o liolib.o lmathlib.o loslib.o ltablib.o lstrlib.o loadlib.o linit.o strip --strip-unneeded lua51.dll gcc -o lua.exe -s lua.o lua51.dll -lm make[3]: Leaving directory `/home/gyokimae/pdlua-0.5/lua-5.1.3/src' make "LUAC_T=luac.exe" luac.exe make[3]: Entering directory `/home/gyokimae/pdlua-0.5/lua-5.1.3/src' gcc -O2 -Wall -c -o luac.o luac.c gcc -O2 -Wall -c -o print.o print.c ar rcu liblua.a lapi.o lcode.o ldebug.o ldo.o ldump.o lfunc.o lgc.o llex.o lmem.o lobject.o lopcodes.o lparser.o lstate.o lstring.o ltable.o ltm.o lundump.o lvm.o lzio.o lauxlib.o lbaselib.o ldblib.o liolib.o lmathlib.o loslib.o ltablib.o lstrlib.o loadlib.o linit.o ranlib liblua.a gcc -o luac.exe luac.o print.o liblua.a -lm make[3]: Leaving directory `/home/gyokimae/pdlua-0.5/lua-5.1.3/src' make[2]: Leaving directory `/home/gyokimae/pdlua-0.5/lua-5.1.3/src' make install INSTALL_TOP=.. make[2]: Entering directory `/home/gyokimae/pdlua-0.5/lua-5.1.3' cd src && mkdir -p ../bin ../include ../lib ../man/man1 ../share/lua/5.1 ../lib/lua/5.1 cd src && install -p -m 0755 lua luac ../bin cd src && install -p -m 0644 lua.h luaconf.h lualib.h lauxlib.h ../etc/lua.hpp ../include cd src && install -p -m 0644 liblua.a ../lib cd doc && install -p -m 0644 lua.1 luac.1 ../man/man1 make[2]: Leaving directory `/home/gyokimae/pdlua-0.5/lua-5.1.3' make[1]: Leaving directory `/home/gyokimae/pdlua-0.5/lua-5.1.3' touch lua-5.1.3/build.stamp gcc -ansi -pedantic -Wall -O2 -fPIC -Ilua-5.1.3/include/ -I./ -export_dynamic -shared -o src/lua.dll src/lua.c lua-5.1.3/lib/liblua.a pd.dll src/lua.c:1: warning: -fPIC ignored for target (all code is position independent) src/lua.c:51:4: warning: #warning is a GCC extension src/lua.c:51:4: warning: #warning "Pd version is not new enough for 64-bit safe arrays" src/lua.c: In function `pdlua_setvalue': src/lua.c:899: warning: passing arg 1 of `gensym' discards qualifiers from pointer target type src/lua.c: In function `pdlua_getvalue': src/lua.c:915: warning: passing arg 1 of `gensym' discards qualifiers from pointer target type src/lua.c: In function `pdlua_getarray': src/lua.c:938: warning: passing arg 1 of `gensym' discards qualifiers from pointer target type src/lua.c: In function `pdlua_redrawarray': src/lua.c:1001: warning: passing arg 1 of `gensym' discards qualifiers from pointer target type Info: resolving _garray_class by linking to __imp__garray_class (auto-import) Info: resolving _s_ by linking to __imp__s_ (auto-import)
-- 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
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
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
Hi, Claude
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" :(
I have a feeling that the compiler output I am seeing and the behavior of Pd when failing to load the extern is similar to what I've seen when the entry function is not properly exported during building the DLL.
If I find out anything, I will certainly post here.
Has anyone managed to build pdlua on Windows anyway? Is it only tested against Pd built with MinGW which pdlua's Makefile suggests to use?
-- David Shimamoto
Some progress.
Now [lua] creates an instance properly. I haven't had the chance to actually load Lua scripts yet..
Sorry for my writing as I am not yet familiar with any of the patching tools.
----- lua.c ----- Before: extern void lua_setup(void) {
After: extern __declspec(dllexport) void lua_setup(void) {
----- Makefile.static ----- Before: CFLAGS_mingw = -export_dynamic -shared
After: CFLAGS_mingw = -shared
-- David Shimamoto
Hi, Claude
Thank you for your patience. I think pdlua is now working on my Win Pd-extended.. at least the counter example is working properly.
I have sorted out the changes that were necessary. Again, apologies for my style of reporting. This has been my first attempt to modifying any existing C/C++ project.
------------ 1. Copy the following files to the same directory as Makefile.static 1) lua-5.1.3.tar.gz (My MinGW did not have 'wget') 2) m_pd.h 3) pd.dll
------------ 2. Modify lua.c
- line:1271
Before: extern void lua_setup(void) {
After: EXTERN void lua_setup(void) {
------------- 3. Modify Makefile.static
- line:5 Comment out (#PLATFORM = linux) - line:7 Uncomment (PLATFORM = mingw) - line:30 Before: CFLAGS_mingw = -export_dynamic -shared
After: CFLAGS_mingw = -shared -D MSW -D PD_INTERNAL -I./
------------- (After `make -f Makefile.static') 4. Copy the following files to 'extra' 1) lua.dll 2) pd.lua
-- David Shimamomto
Hallo, PSPunch hat gesagt: // PSPunch wrote:
- Modify Makefile.static
line:5 Comment out (#PLATFORM = linux)
line:7 Uncomment (PLATFORM = mingw)
line:30 Before: CFLAGS_mingw = -export_dynamic -shared
After: CFLAGS_mingw = -shared -D MSW -D PD_INTERNAL -I./
Could you try if this:
CFLAGS_mingw = -shared -D MSW -I./
works as well?
I think, defining PD_INTERNAL is not necessary, as in (my) m_pd.h not defining it should have the same results:
#ifdef MSW #ifdef PD_INTERNAL #define EXTERN __declspec(dllexport) extern #else #define EXTERN __declspec(dllimport) extern #endif /* PD_INTERNAL */ #else #define EXTERN extern #endif /* MSW */
Ciao
Hi Frank,
#ifdef MSW #ifdef PD_INTERNAL #define EXTERN __declspec(dllexport) extern #else #define EXTERN __declspec(dllimport) extern #endif /* PD_INTERNAL */
Without PD_INTERNAL defined, dllexport -> dllimport which looks kind of critical.
Below are the last few lines of output when PD_INTERNAL is not defined.
---------------------- src/lua.c:1001: warning: passing arg 1 of `gensym' discards qualifiers from pointer target type src/lua.c: In function `lua_setup': src/lua.c:1305: internal compiler error: in rest_of_handle_final, at toplev.c:2067 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://www.mingw.org/bugs.shtml for instructions. make: *** [src/lua.dll] Error 1 ----------------------
BTW, do you know off hand what the -export_dynamic option was originally there for? I searched some but could not find a clear explanation, however, among search results were some Pd related pages mentioning it to be needed.
-- David Shimamoto
PSPunch wrote:
Hi Frank,
#ifdef MSW #ifdef PD_INTERNAL #define EXTERN __declspec(dllexport) extern #else #define EXTERN __declspec(dllimport) extern #endif /* PD_INTERNAL */
Without PD_INTERNAL defined, dllexport -> dllimport which looks kind of critical.
well obvisouly there are two clashing things: you want pdlua to _import_ things from pd.dll (e.g. "post()"), therefore you should NOT define PD_INTERNAL you want pdlua to _export_ things (namely "pdlua_setup()")
Below are the last few lines of output when PD_INTERNAL is not defined.
you should never ever define PD_INTERNAL when you are not writing Pd internals (hence the name).
BTW, do you know off hand what the -export_dynamic option was originally there for?
it's there to make life easier: to not have to declare symbols to imported/exported (which as we have seen above is basically the same, just from a different point of view).
I searched some but could not find a clear explanation, however, among search results were some Pd related pages mentioning it to be needed.
unfortunately i don't know any mingw, so i cannot really help you.
fmgadsr IOhannes
Hi IOhannes,
well obvisouly there are two clashing things: you want pdlua to _import_ things from pd.dll (e.g. "post()"), therefore you should NOT define PD_INTERNAL you want pdlua to _export_ things (namely "pdlua_setup()")
Below are the last few lines of output when PD_INTERNAL is not defined.
you should never ever define PD_INTERNAL when you are not writing Pd internals (hence the name).
I think lua_setup() needs to be 'exported' in order to be read externally with Windows DLLs. So, if the only route to have m_pd.h define the EXTERN macro as expected, what will be a clean way to add __declspec(dllexport) to the function definition and yet let the code remain compatible with other platforms? Simply introduce new macros in lua.c?
Also, from your description I thought that PD_INTERNAL was reserved for internal functions or classes, etc. However, when grepping the source of vanilla Pd, I did not find the macro being used anywhere else other than this part of m_pd.h. What is this reserved for?
-- David Shimamoto
PSPunch wrote:
Hi IOhannes,
I think lua_setup() needs to be 'exported' in order to be read externally with Windows DLLs.
correct
Also, from your description I thought that PD_INTERNAL was reserved for internal functions or classes, etc. However, when grepping the source of vanilla Pd, I did not find the macro being used anywhere else other than this part of m_pd.h. What is this reserved for?
well it's enough to have it defined in the header-file as this is _declares_ the functions to be exported (the _definitions_ need not care about that anymore)
mfgadr. IOhannes
Hallo, PSPunch hat gesagt: // PSPunch wrote:
#ifdef MSW #ifdef PD_INTERNAL #define EXTERN __declspec(dllexport) extern #else #define EXTERN __declspec(dllimport) extern #endif /* PD_INTERNAL */
Without PD_INTERNAL defined, dllexport -> dllimport which looks kind of critical.
Sorry, actually this difference slipped me (must be my new glasses ...)
Ciao
Hi,
Thanks for the help, hopefully pdlua svn should now build (and run!) on mingw with the only changes required being in the "user configuration" section at the top of the 'Makefile.static'.
PSPunch wrote:
- Copy the following files to the same directory as Makefile.static
- lua-5.1.3.tar.gz (My MinGW did not have 'wget')
- m_pd.h
- pd.dll
Added to the documentation.
- Modify lua.c
line:1271
Before: extern void lua_setup(void) {
After: EXTERN void lua_setup(void) {
Applied this change.
- Modify Makefile.static
line:5 Comment out (#PLATFORM = linux)
line:7 Uncomment (PLATFORM = mingw)
line:30 Before: CFLAGS_mingw = -export_dynamic -shared
After: CFLAGS_mingw = -shared -D MSW -D PD_INTERNAL -I./
Modified this slightly (no PD_INTERNAL, no -I which should go in the PDINCLUDE in the user configuration section).
(After `make -f Makefile.static') 4. Copy the following files to 'extra'
- lua.dll
- pd.lua
Added as a suggestion in the documentation.
Thanks again,
Claude
Claude Heiland-Allen wrote:
After: EXTERN void lua_setup(void) {
Applied this change.
Actually, I had to define a new macro depending on MSW, because otherwise the EXTERN stuff operates in the wrong direction (oops).
Should work now, thanks to IOhannes for pointing out the issue (albeit obliquely).
So the question is, does every external have to jump through this kind of hoop if it wants to compile on Windows?
/* support windows */ #ifdef MSW #define EXPORT __declspec(dllexport) extern #else #define EXPORT extern #endif
Claude
Am 03.09.2008 um 22:11 schrieb Claude Heiland-Allen:
So the question is, does every external have to jump through this kind of hoop if it wants to compile on Windows?
/* support windows */ #ifdef MSW #define EXPORT __declspec(dllexport) extern #else #define EXPORT extern #endif
Yes and no. With the above hoop you define all what is needed - on the other hand you could also roll it out to the build stage and instruct the linker via flags or .def files about which symbols to export. gr~~~
Hi all,
Am 03.09.2008 um 22:11 schrieb Claude Heiland-Allen:
So the question is, does every external have to jump through this kind of hoop if it wants to compile on Windows?
/* support windows */ #ifdef MSW #define EXPORT __declspec(dllexport) extern #else #define EXPORT extern #endif
Yes and no. With the above hoop you define all what is needed - on the other hand you could also roll it out to the build stage and instruct the linker via flags or .def files about which symbols to export. gr~~~
I found the same topic regarding compilation of pdlua on Windows.
http://lists.puredata.info/pipermail/pd-list/2007-12/057637.html
To add a quick update to the topic, I think the built pdlua will not work on the binary package of Vanilla-Pd.
It does not have sys_register_loader() visible externally which I think in another discussion, Hans had mentioned he had patched for extended.
At least the symbol to that function was not found neither in pd.dll nor pd.lib attached to Vanilla.
-- David Shimamoto
Claude Heiland-Allen wrote:
/* support windows */ #ifdef MSW
i guess it would be far nicer to use automatically defined macros whenever possible: #ifdef _MSC_VER /* for Visual Studio C-Compiler */ #ifdef _WIN32 /* for win32; whichever compiler */
fmgasdr IOhannes