I just realized that pd is now available on Windows 64bit, thanks a lot ! So I updated my CMake library build system for Pd ( https://github.com/pierreguillot/pd.build) and I realized that the Windows distributions of Pd now offers the files pd.lib and pd.def that are necessary for compiling using MSVC (I think I saw something about it on the list but I don't find it...). But there are missing symbols: on Windows 64bit I can't use s_list and s_signal for example. I solved the issue by creating my own pd.lib and pd.def from pd.dll. So if you encounter the same issue, you can simply do
dumpbin /EXPORTS pd.dll > pd.exports
Then paste the names of all the functions and symbols from pd.exports into a new pd.def file and add a line with the word EXPORTS at the top of this file then do
lib /def:pd.def /out:pd.lib
I hope it could help some of you. Perhaps we could add a documentation somewhere about it... (I don't know if it useful...) I can help if needed. Cheers,
Pierre
On 2018-05-23 11:29, Pierre Guillot wrote:
But there are missing symbols: on Windows 64bit I can't use s_list and s_signal for example. I solved the issue by creating my own pd.lib and pd.def from pd.dll. So if you encounter the same issue, you can simply do
dumpbin /EXPORTS pd.dll > pd.exports lib /def:pd.def /out:pd.lib
the problem with this is that it requires MSVC tools now, the target audience are MSVC-users (who else needs that pd.lib...), so they already have it. however, it would be nice if the shipped pd.lib (which uses the MinGW toolchain and doesn't have the MSVC tools) would contain all the required symbols.
otoh, i do think that those global variables (`e.g. `s_float`) shouldn't be used in the first place: use the `gensym()` equivalents.
gasdmr IOhannes
I hope it could help some of you. Perhaps we could add a documentation somewhere about it... (I don't know if it useful...) I can help if needed.
however, it would be nice if the shipped pd.lib (which uses the MinGW toolchain and doesn't have the MSVC tools) would contain all the required symbols.
Yes, what seems strange is that s_list and s_signal were defined in the shipped pd.def but not in pd.lib...
otoh, i do think that those global variables (`e.g. `s_float`) shouldn't be used in the first place: use the `gensym()` equivalents.
Why? I used these variable because I assumed that they are more efficient than using `gensym()` (and as they are defined EXTERN I also assumed that they can be used). But yes perhaps a better solution would be to generate and store the symbols in the new method of the object using `gensym()` (and it will be the same but for the sustainability of old codes, these symbols must be included).
Thanks
2018-05-23 11:38 GMT+02:00 IOhannes m zmoelnig zmoelnig@iem.at:
On 2018-05-23 11:29, Pierre Guillot wrote:
But there are missing symbols: on Windows 64bit I can't use s_list and s_signal for example. I solved the issue by creating my own pd.lib and pd.def from pd.dll. So if you encounter the
same
issue, you can simply do
dumpbin /EXPORTS pd.dll > pd.exports lib /def:pd.def /out:pd.lib
the problem with this is that it requires MSVC tools now, the target audience are MSVC-users (who else needs that pd.lib...), so they already have it. however, it would be nice if the shipped pd.lib (which uses the MinGW toolchain and doesn't have the MSVC tools) would contain all the required symbols.
otoh, i do think that those global variables (`e.g. `s_float`) shouldn't be used in the first place: use the `gensym()` equivalents.
gasdmr IOhannes
I hope it could help some of you. Perhaps we could add a documentation somewhere about it... (I don't know if it useful...) I can help if
needed.
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
this is odd. I made a simple Pd external which uses s_list and s_signal with MSVC in two versions: one links against Miller's pd.lib, the other links against the pd.lib I get when building from source with MinGW and autotools. Both versions compile, link and load just fine with either Pd version.
I'm using the Developer command prompt, these are my commands:
cl /W3 /DNT /DPD /nologo /I. /IPDSOURCEPATH /c testobj.c link /dll /export:testobj_setup testobj.obj oldnames.lib kernel32.lib PDBINPATH\pd.lib
Christof
Gesendet: Mittwoch, 23. Mai 2018 um 12:01 Uhr Von: "Pierre Guillot" guillotpierre6@gmail.com An: "IOhannes m zmoelnig" zmoelnig@iem.at Cc: pd-dev pd-dev@lists.iem.at Betreff: Re: [PD-dev] pd.lib & msvc - missing symbols
however, it would be nice if the shipped pd.lib (which uses the MinGW toolchain and doesn't have the MSVC tools) would contain all the required symbols.
Yes, what seems strange is that s_list and s_signal were defined in the shipped pd.def but not in pd.lib...
otoh, i do think that those global variables (`e.g. `s_float`) shouldn't be used in the first place: use the `gensym()` equivalents.
Why? I used these variable because I assumed that they are more efficient than using `gensym()` (and as they are defined EXTERN I also assumed that they can be used). But yes perhaps a better solution would be to generate and store the symbols in the new method of the object using `gensym()` (and it will be the same but for the sustainability of old codes, these symbols must be included). Thanks 2018-05-23 11:38 GMT+02:00 IOhannes m zmoelnig <zmoelnig@iem.at[mailto:zmoelnig@iem.at]>:On 2018-05-23 11:29, Pierre Guillot wrote:
But there are missing symbols: on Windows 64bit I can't use s_list and s_signal for example. I solved the issue by creating my own pd.lib and pd.def from pd.dll. So if you encounter the same issue, you can simply do
dumpbin /EXPORTS pd.dll > pd.exports lib /def:pd.def /out:pd.lib
the problem with this is that it requires MSVC tools now, the target audience are MSVC-users (who else needs that pd.lib...), so they already have it. however, it would be nice if the shipped pd.lib (which uses the MinGW toolchain and doesn't have the MSVC tools) would contain all the required symbols.
otoh, i do think that those global variables (`e.g. `s_float`) shouldn't be used in the first place: use the `gensym()` equivalents.
gasdmr IOhannes
I hope it could help some of you. Perhaps we could add a documentation somewhere about it... (I don't know if it useful...) I can help if needed.
_______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at[mailto:Pd-dev@lists.iem.at] https://lists.puredata.info/listinfo/pd-dev _______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev%5Bhttps://lists.puredata.info/li...]
Hi Christof,
I'm not a specialist of Windows so I can miss something important. How do you specify the target machine? Are you sure you compiled against the 64bit version of pd.lib? Because I didn't check the symbols of the 32 bit distribution, perhaps they are available.
Another question: I assumed that **_WIN32** must be defined (isn't it?) and so **PD_INTERNAL** must also be used if we want to export properly the function `setup_class()` using **EXTERN**. I see that you don't define any of these constants, are they useless in your case? And why?
2018-05-23 13:40 GMT+02:00 Christof Ressi christof.ressi@gmx.at:
this is odd. I made a simple Pd external which uses s_list and s_signal with MSVC in two versions: one links against Miller's pd.lib, the other links against the pd.lib I get when building from source with MinGW and autotools. Both versions compile, link and load just fine with either Pd version.
I'm using the Developer command prompt, these are my commands:
cl /W3 /DNT /DPD /nologo /I. /IPDSOURCEPATH /c testobj.c link /dll /export:testobj_setup testobj.obj oldnames.lib kernel32.lib
PDBINPATH\pd.lib
Christof
Gesendet: Mittwoch, 23. Mai 2018 um 12:01 Uhr Von: "Pierre Guillot" guillotpierre6@gmail.com An: "IOhannes m zmoelnig" zmoelnig@iem.at Cc: pd-dev pd-dev@lists.iem.at Betreff: Re: [PD-dev] pd.lib & msvc - missing symbols
however, it would be nice if the shipped pd.lib (which uses the MinGW toolchain and doesn't have the MSVC tools) would contain all the required symbols.
Yes, what seems strange is that s_list and s_signal were defined in the shipped pd.def but not in pd.lib...
otoh, i do think that those global variables (`e.g. `s_float`) shouldn't be used in the first place: use the `gensym()` equivalents.
Why? I used these variable because I assumed that they are more efficient than using `gensym()` (and as they are defined EXTERN I also assumed that they can be used). But yes perhaps a better solution would be to generate and store the symbols in the new method of the object using `gensym()` (and it will be the same but for the sustainability of old codes, these symbols must be included).
Thanks
2018-05-23 11:38 GMT+02:00 IOhannes m zmoelnig <zmoelnig@iem.at[mailto: zmoelnig@iem.at]>:On 2018-05-23 11:29, Pierre Guillot wrote:
But there are missing symbols: on Windows 64bit I can't use s_list and s_signal for example. I solved the issue by creating my own pd.lib and pd.def from pd.dll. So if you encounter the
same
issue, you can simply do
dumpbin /EXPORTS pd.dll > pd.exports lib /def:pd.def /out:pd.lib
the problem with this is that it requires MSVC tools now, the target audience are MSVC-users (who else needs that pd.lib...), so they already have it. however, it would be nice if the shipped pd.lib (which uses the MinGW toolchain and doesn't have the MSVC tools) would contain all the required symbols.
otoh, i do think that those global variables (`e.g. `s_float`) shouldn't be used in the first place: use the `gensym()` equivalents.
gasdmr IOhannes
I hope it could help some of you. Perhaps we could add a documentation somewhere about it... (I don't know if it useful...) I can help if
needed.
Pd-dev mailing list Pd-dev@lists.iem.at[mailto:Pd-dev@lists.iem.at] https://lists.puredata.info/listinfo/pd-dev _______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/ listinfo/pd-dev[https://lists.puredata.info/listinfo/pd-dev]
doh, I missed the part about 64bit Pd. my test was with 32bit Pd. but I don't know why the 64bit version wouldn't export the same symbols...
I assumed that **_WIN32** must be defined (isn't it?)
it should be defined by MSVC, see https://msdn.microsoft.com/en-us/library/b0084kay.aspx.
"_WIN32 Defined as 1 when the compilation target is 32-bit ARM, 64-bit ARM, x86, or x64. Otherwise, undefined. _WIN64 Defined as 1 when the compilation target is 64-bit ARM or x64. Otherwise, undefined."
and so **PD_INTERNAL** must also be used if we want to export properly the function `setup_class()` using **EXTERN**.
yes, if you compile Pd with MSVC, but MinGW will automatically export all symbols.
I'll now try again with the 64-bit Pd.
Gesendet: Mittwoch, 23. Mai 2018 um 14:09 Uhr Von: "Pierre Guillot" guillotpierre6@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: pd-dev pd-dev@lists.iem.at Betreff: Re: Re: [PD-dev] pd.lib & msvc - missing symbols
Hi Christof, I'm not a specialist of Windows so I can miss something important. How do you specify the target machine? Are you sure you compiled against the 64bit version of pd.lib? Because I didn't check the symbols of the 32 bit distribution, perhaps they are available. Another question: I assumed that **_WIN32** must be defined (isn't it?) and so **PD_INTERNAL** must also be used if we want to export properly the function `setup_class()` using **EXTERN**. I see that you don't define any of these constants, are they useless in your case? And why? 2018-05-23 13:40 GMT+02:00 Christof Ressi <christof.ressi@gmx.at[mailto:christof.ressi@gmx.at]>:this is odd. I made a simple Pd external which uses s_list and s_signal with MSVC in two versions: one links against Miller's pd.lib, the other links against the pd.lib I get when building from source with MinGW and autotools. Both versions compile, link and load just fine with either Pd version.
I'm using the Developer command prompt, these are my commands:
cl /W3 /DNT /DPD /nologo /I. /IPDSOURCEPATH /c testobj.c link /dll /export:testobj_setup testobj.obj oldnames.lib kernel32.lib PDBINPATH\pd.lib
Christof
Gesendet: Mittwoch, 23. Mai 2018 um 12:01 Uhr Von: "Pierre Guillot" <guillotpierre6@gmail.com[mailto:guillotpierre6@gmail.com]> An: "IOhannes m zmoelnig" <zmoelnig@iem.at[mailto:zmoelnig@iem.at]> Cc: pd-dev <pd-dev@lists.iem.at[mailto:pd-dev@lists.iem.at]> Betreff: Re: [PD-dev] pd.lib & msvc - missing symbols
however, it would be nice if the shipped pd.lib (which uses the MinGW toolchain and doesn't have the MSVC tools) would contain all the required symbols.
Yes, what seems strange is that s_list and s_signal were defined in the shipped pd.def but not in pd.lib...
otoh, i do think that those global variables (`e.g. `s_float`) shouldn't be used in the first place: use the `gensym()` equivalents.
Why? I used these variable because I assumed that they are more efficient than using `gensym()` (and as they are defined EXTERN I also assumed that they can be used). But yes perhaps a better solution would be to generate and store the symbols in the new method of the object using `gensym()` (and it will be the same but for the sustainability of old codes, these symbols must be included). Thanks 2018-05-23 11:38 GMT+02:00 IOhannes m zmoelnig <zmoelnig@iem.at[mailto:zmoelnig@iem.at][mailto:zmoelnig@iem.at[mailto:zmoelnig@iem.at]]>:On 2018-05-23 11:29, Pierre Guillot wrote:
But there are missing symbols: on Windows 64bit I can't use s_list and s_signal for example. I solved the issue by creating my own pd.lib and pd.def from pd.dll. So if you encounter the same issue, you can simply do
dumpbin /EXPORTS pd.dll > pd.exports lib /def:pd.def /out:pd.lib
the problem with this is that it requires MSVC tools now, the target audience are MSVC-users (who else needs that pd.lib...), so they already have it. however, it would be nice if the shipped pd.lib (which uses the MinGW toolchain and doesn't have the MSVC tools) would contain all the required symbols.
otoh, i do think that those global variables (`e.g. `s_float`) shouldn't be used in the first place: use the `gensym()` equivalents.
gasdmr IOhannes
I hope it could help some of you. Perhaps we could add a documentation somewhere about it... (I don't know if it useful...) I can help if needed.
_______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at[mailto:Pd-dev@lists.iem.at][mailto:Pd-dev@lists.iem.at[mailto:Pd-dev@lists.iem.at]] https://lists.puredata.info/listinfo/pd-dev%5Bhttps://lists.puredata.info/li...] _______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at[mailto:Pd-dev@lists.iem.at] https://lists.puredata.info/listinfo/pd-dev%5Bhttps://lists.puredata.info/li...]
just tested again with Miller's 64-bit build and it works fine for me. to build an 64-bit external from the command line, the only thing you have to do is to run
vcvarsall.bat amd64
before compiling. this will set the necessary environment variables.
see: https://msdn.microsoft.com/en-us/library/x4d2c09s.aspx
Christof
Gesendet: Mittwoch, 23. Mai 2018 um 14:48 Uhr Von: "Christof Ressi" christof.ressi@gmx.at An: "Pierre Guillot" guillotpierre6@gmail.com Cc: pd-dev pd-dev@lists.iem.at Betreff: Re: [PD-dev] pd.lib & msvc - missing symbols
doh, I missed the part about 64bit Pd. my test was with 32bit Pd. but I don't know why the 64bit version wouldn't export the same symbols...
I assumed that **_WIN32** must be defined (isn't it?)
it should be defined by MSVC, see https://msdn.microsoft.com/en-us/library/b0084kay.aspx.
"_WIN32 Defined as 1 when the compilation target is 32-bit ARM, 64-bit ARM, x86, or x64. Otherwise, undefined. _WIN64 Defined as 1 when the compilation target is 64-bit ARM or x64. Otherwise, undefined."
and so **PD_INTERNAL** must also be used if we want to export properly the function `setup_class()` using **EXTERN**.
yes, if you compile Pd with MSVC, but MinGW will automatically export all symbols.
I'll now try again with the 64-bit Pd.
Gesendet: Mittwoch, 23. Mai 2018 um 14:09 Uhr Von: "Pierre Guillot" guillotpierre6@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: pd-dev pd-dev@lists.iem.at Betreff: Re: Re: [PD-dev] pd.lib & msvc - missing symbols
Hi Christof, I'm not a specialist of Windows so I can miss something important. How do you specify the target machine? Are you sure you compiled against the 64bit version of pd.lib? Because I didn't check the symbols of the 32 bit distribution, perhaps they are available. Another question: I assumed that **_WIN32** must be defined (isn't it?) and so **PD_INTERNAL** must also be used if we want to export properly the function `setup_class()` using **EXTERN**. I see that you don't define any of these constants, are they useless in your case? And why? 2018-05-23 13:40 GMT+02:00 Christof Ressi <christof.ressi@gmx.at[mailto:christof.ressi@gmx.at]>:this is odd. I made a simple Pd external which uses s_list and s_signal with MSVC in two versions: one links against Miller's pd.lib, the other links against the pd.lib I get when building from source with MinGW and autotools. Both versions compile, link and load just fine with either Pd version.
I'm using the Developer command prompt, these are my commands:
cl /W3 /DNT /DPD /nologo /I. /IPDSOURCEPATH /c testobj.c link /dll /export:testobj_setup testobj.obj oldnames.lib kernel32.lib PDBINPATH\pd.lib
Christof
Gesendet: Mittwoch, 23. Mai 2018 um 12:01 Uhr Von: "Pierre Guillot" <guillotpierre6@gmail.com[mailto:guillotpierre6@gmail.com]> An: "IOhannes m zmoelnig" <zmoelnig@iem.at[mailto:zmoelnig@iem.at]> Cc: pd-dev <pd-dev@lists.iem.at[mailto:pd-dev@lists.iem.at]> Betreff: Re: [PD-dev] pd.lib & msvc - missing symbols
however, it would be nice if the shipped pd.lib (which uses the MinGW toolchain and doesn't have the MSVC tools) would contain all the required symbols.
Yes, what seems strange is that s_list and s_signal were defined in the shipped pd.def but not in pd.lib...
otoh, i do think that those global variables (`e.g. `s_float`) shouldn't be used in the first place: use the `gensym()` equivalents.
Why? I used these variable because I assumed that they are more efficient than using `gensym()` (and as they are defined EXTERN I also assumed that they can be used). But yes perhaps a better solution would be to generate and store the symbols in the new method of the object using `gensym()` (and it will be the same but for the sustainability of old codes, these symbols must be included). Thanks 2018-05-23 11:38 GMT+02:00 IOhannes m zmoelnig <zmoelnig@iem.at[mailto:zmoelnig@iem.at][mailto:zmoelnig@iem.at[mailto:zmoelnig@iem.at]]>:On 2018-05-23 11:29, Pierre Guillot wrote:
But there are missing symbols: on Windows 64bit I can't use s_list and s_signal for example. I solved the issue by creating my own pd.lib and pd.def from pd.dll. So if you encounter the same issue, you can simply do
dumpbin /EXPORTS pd.dll > pd.exports lib /def:pd.def /out:pd.lib
the problem with this is that it requires MSVC tools now, the target audience are MSVC-users (who else needs that pd.lib...), so they already have it. however, it would be nice if the shipped pd.lib (which uses the MinGW toolchain and doesn't have the MSVC tools) would contain all the required symbols.
otoh, i do think that those global variables (`e.g. `s_float`) shouldn't be used in the first place: use the `gensym()` equivalents.
gasdmr IOhannes
I hope it could help some of you. Perhaps we could add a documentation somewhere about it... (I don't know if it useful...) I can help if needed.
_______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at[mailto:Pd-dev@lists.iem.at][mailto:Pd-dev@lists.iem.at[mailto:Pd-dev@lists.iem.at]] https://lists.puredata.info/listinfo/pd-dev%5Bhttps://lists.puredata.info/li...] _______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at[mailto:Pd-dev@lists.iem.at] https://lists.puredata.info/listinfo/pd-dev%5Bhttps://lists.puredata.info/li...]
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
and so **PD_INTERNAL** must also be used if we want to export properly the function `setup_class()` using **EXTERN**.
with 'setup_class()' you mean the setup function of your external? it is exported with the /export:testobj_setup option to the linker.
when you build an external, PD_INTERNAL must *not* be defined because you want to *import* the API functions from Pd.
otoh, PD_INTERNAL must be defined if you build the pd.dll with MSVC, because there you want to *export* the API functions.
Gesendet: Mittwoch, 23. Mai 2018 um 14:09 Uhr Von: "Pierre Guillot" guillotpierre6@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: pd-dev pd-dev@lists.iem.at Betreff: Re: Re: [PD-dev] pd.lib & msvc - missing symbols
Hi Christof, I'm not a specialist of Windows so I can miss something important. How do you specify the target machine? Are you sure you compiled against the 64bit version of pd.lib? Because I didn't check the symbols of the 32 bit distribution, perhaps they are available. Another question: I assumed that **_WIN32** must be defined (isn't it?) and so **PD_INTERNAL** must also be used if we want to export properly the function `setup_class()` using **EXTERN**. I see that you don't define any of these constants, are they useless in your case? And why? 2018-05-23 13:40 GMT+02:00 Christof Ressi <christof.ressi@gmx.at[mailto:christof.ressi@gmx.at]>:this is odd. I made a simple Pd external which uses s_list and s_signal with MSVC in two versions: one links against Miller's pd.lib, the other links against the pd.lib I get when building from source with MinGW and autotools. Both versions compile, link and load just fine with either Pd version.
I'm using the Developer command prompt, these are my commands:
cl /W3 /DNT /DPD /nologo /I. /IPDSOURCEPATH /c testobj.c link /dll /export:testobj_setup testobj.obj oldnames.lib kernel32.lib PDBINPATH\pd.lib
Christof
Gesendet: Mittwoch, 23. Mai 2018 um 12:01 Uhr Von: "Pierre Guillot" <guillotpierre6@gmail.com[mailto:guillotpierre6@gmail.com]> An: "IOhannes m zmoelnig" <zmoelnig@iem.at[mailto:zmoelnig@iem.at]> Cc: pd-dev <pd-dev@lists.iem.at[mailto:pd-dev@lists.iem.at]> Betreff: Re: [PD-dev] pd.lib & msvc - missing symbols
however, it would be nice if the shipped pd.lib (which uses the MinGW toolchain and doesn't have the MSVC tools) would contain all the required symbols.
Yes, what seems strange is that s_list and s_signal were defined in the shipped pd.def but not in pd.lib...
otoh, i do think that those global variables (`e.g. `s_float`) shouldn't be used in the first place: use the `gensym()` equivalents.
Why? I used these variable because I assumed that they are more efficient than using `gensym()` (and as they are defined EXTERN I also assumed that they can be used). But yes perhaps a better solution would be to generate and store the symbols in the new method of the object using `gensym()` (and it will be the same but for the sustainability of old codes, these symbols must be included). Thanks 2018-05-23 11:38 GMT+02:00 IOhannes m zmoelnig <zmoelnig@iem.at[mailto:zmoelnig@iem.at][mailto:zmoelnig@iem.at[mailto:zmoelnig@iem.at]]>:On 2018-05-23 11:29, Pierre Guillot wrote:
But there are missing symbols: on Windows 64bit I can't use s_list and s_signal for example. I solved the issue by creating my own pd.lib and pd.def from pd.dll. So if you encounter the same issue, you can simply do
dumpbin /EXPORTS pd.dll > pd.exports lib /def:pd.def /out:pd.lib
the problem with this is that it requires MSVC tools now, the target audience are MSVC-users (who else needs that pd.lib...), so they already have it. however, it would be nice if the shipped pd.lib (which uses the MinGW toolchain and doesn't have the MSVC tools) would contain all the required symbols.
otoh, i do think that those global variables (`e.g. `s_float`) shouldn't be used in the first place: use the `gensym()` equivalents.
gasdmr IOhannes
I hope it could help some of you. Perhaps we could add a documentation somewhere about it... (I don't know if it useful...) I can help if needed.
_______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at[mailto:Pd-dev@lists.iem.at][mailto:Pd-dev@lists.iem.at[mailto:Pd-dev@lists.iem.at]] https://lists.puredata.info/listinfo/pd-dev%5Bhttps://lists.puredata.info/li...] _______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at[mailto:Pd-dev@lists.iem.at] https://lists.puredata.info/listinfo/pd-dev%5Bhttps://lists.puredata.info/li...]
so I hope you're not putting EXTERN in front of your external's setup function and defining PD_INTERNAL yourself... that wouldn't be a good idea :-)
Gesendet: Mittwoch, 23. Mai 2018 um 15:15 Uhr Von: "Christof Ressi" christof.ressi@gmx.at An: "Pierre Guillot" guillotpierre6@gmail.com Cc: pd-dev pd-dev@lists.iem.at Betreff: Re: [PD-dev] pd.lib & msvc - missing symbols
and so **PD_INTERNAL** must also be used if we want to export properly the function `setup_class()` using **EXTERN**.
with 'setup_class()' you mean the setup function of your external? it is exported with the /export:testobj_setup option to the linker.
when you build an external, PD_INTERNAL must *not* be defined because you want to *import* the API functions from Pd.
otoh, PD_INTERNAL must be defined if you build the pd.dll with MSVC, because there you want to *export* the API functions.
Gesendet: Mittwoch, 23. Mai 2018 um 14:09 Uhr Von: "Pierre Guillot" guillotpierre6@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: pd-dev pd-dev@lists.iem.at Betreff: Re: Re: [PD-dev] pd.lib & msvc - missing symbols
Hi Christof, I'm not a specialist of Windows so I can miss something important. How do you specify the target machine? Are you sure you compiled against the 64bit version of pd.lib? Because I didn't check the symbols of the 32 bit distribution, perhaps they are available. Another question: I assumed that **_WIN32** must be defined (isn't it?) and so **PD_INTERNAL** must also be used if we want to export properly the function `setup_class()` using **EXTERN**. I see that you don't define any of these constants, are they useless in your case? And why? 2018-05-23 13:40 GMT+02:00 Christof Ressi <christof.ressi@gmx.at[mailto:christof.ressi@gmx.at]>:this is odd. I made a simple Pd external which uses s_list and s_signal with MSVC in two versions: one links against Miller's pd.lib, the other links against the pd.lib I get when building from source with MinGW and autotools. Both versions compile, link and load just fine with either Pd version.
I'm using the Developer command prompt, these are my commands:
cl /W3 /DNT /DPD /nologo /I. /IPDSOURCEPATH /c testobj.c link /dll /export:testobj_setup testobj.obj oldnames.lib kernel32.lib PDBINPATH\pd.lib
Christof
Gesendet: Mittwoch, 23. Mai 2018 um 12:01 Uhr Von: "Pierre Guillot" <guillotpierre6@gmail.com[mailto:guillotpierre6@gmail.com]> An: "IOhannes m zmoelnig" <zmoelnig@iem.at[mailto:zmoelnig@iem.at]> Cc: pd-dev <pd-dev@lists.iem.at[mailto:pd-dev@lists.iem.at]> Betreff: Re: [PD-dev] pd.lib & msvc - missing symbols
however, it would be nice if the shipped pd.lib (which uses the MinGW toolchain and doesn't have the MSVC tools) would contain all the required symbols.
Yes, what seems strange is that s_list and s_signal were defined in the shipped pd.def but not in pd.lib...
otoh, i do think that those global variables (`e.g. `s_float`) shouldn't be used in the first place: use the `gensym()` equivalents.
Why? I used these variable because I assumed that they are more efficient than using `gensym()` (and as they are defined EXTERN I also assumed that they can be used). But yes perhaps a better solution would be to generate and store the symbols in the new method of the object using `gensym()` (and it will be the same but for the sustainability of old codes, these symbols must be included). Thanks 2018-05-23 11:38 GMT+02:00 IOhannes m zmoelnig <zmoelnig@iem.at[mailto:zmoelnig@iem.at][mailto:zmoelnig@iem.at[mailto:zmoelnig@iem.at]]>:On 2018-05-23 11:29, Pierre Guillot wrote:
But there are missing symbols: on Windows 64bit I can't use s_list and s_signal for example. I solved the issue by creating my own pd.lib and pd.def from pd.dll. So if you encounter the same issue, you can simply do
dumpbin /EXPORTS pd.dll > pd.exports lib /def:pd.def /out:pd.lib
the problem with this is that it requires MSVC tools now, the target audience are MSVC-users (who else needs that pd.lib...), so they already have it. however, it would be nice if the shipped pd.lib (which uses the MinGW toolchain and doesn't have the MSVC tools) would contain all the required symbols.
otoh, i do think that those global variables (`e.g. `s_float`) shouldn't be used in the first place: use the `gensym()` equivalents.
gasdmr IOhannes
I hope it could help some of you. Perhaps we could add a documentation somewhere about it... (I don't know if it useful...) I can help if needed.
_______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at[mailto:Pd-dev@lists.iem.at][mailto:Pd-dev@lists.iem.at[mailto:Pd-dev@lists.iem.at]] https://lists.puredata.info/listinfo/pd-dev%5Bhttps://lists.puredata.info/li...] _______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at[mailto:Pd-dev@lists.iem.at] https://lists.puredata.info/listinfo/pd-dev%5Bhttps://lists.puredata.info/li...]
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Arf... Indeed that was my problem. I didn't define the exported function manually at linking time (using /export with the cl) but directly in the C file using PD_INTERNAL because the approach is similar to the one presented in the MSCV documentation to create dll ( https://msdn.microsoft.com/en-us/library/ms235636.aspx) and it worked pretty well until now...
So to solve my problem, I have two solution: using my own EXPORT definition or generating dynamically the name of the function to export with CMake. Thanks a lot! PS: I still don't understand why it worked for some symbols but not for other...
Thanks a lot !
2018-05-23 15:24 GMT+02:00 Christof Ressi christof.ressi@gmx.at:
so I hope you're not putting EXTERN in front of your external's setup function and defining PD_INTERNAL yourself... that wouldn't be a good idea :-)
Gesendet: Mittwoch, 23. Mai 2018 um 15:15 Uhr Von: "Christof Ressi" christof.ressi@gmx.at An: "Pierre Guillot" guillotpierre6@gmail.com Cc: pd-dev pd-dev@lists.iem.at Betreff: Re: [PD-dev] pd.lib & msvc - missing symbols
and so **PD_INTERNAL** must also be used if we want to export properly
the function `setup_class()` using **EXTERN**.
with 'setup_class()' you mean the setup function of your external? it is
exported with the /export:testobj_setup option to the linker.
when you build an external, PD_INTERNAL must *not* be defined because
you want to *import* the API functions from Pd.
otoh, PD_INTERNAL must be defined if you build the pd.dll with MSVC,
because there you want to *export* the API functions.
Gesendet: Mittwoch, 23. Mai 2018 um 14:09 Uhr Von: "Pierre Guillot" guillotpierre6@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: pd-dev pd-dev@lists.iem.at Betreff: Re: Re: [PD-dev] pd.lib & msvc - missing symbols
Hi Christof,
I'm not a specialist of Windows so I can miss something important. How do you specify the target machine? Are you sure you compiled against
the 64bit version of pd.lib?
Because I didn't check the symbols of the 32 bit distribution, perhaps
they are available.
Another question: I assumed that **_WIN32** must be defined (isn't it?)
and so **PD_INTERNAL** must also be used if we want to export properly the function `setup_class()` using **EXTERN**.
I see that you don't define any of these constants, are they useless in
your case? And why?
2018-05-23 13:40 GMT+02:00 Christof Ressi <christof.ressi@gmx.at[mailto:
christof.ressi@gmx.at]>:this is odd. I made a simple Pd external which uses s_list and s_signal with MSVC in two versions:
one links against Miller's pd.lib, the other links against the pd.lib I
get when building from source with MinGW and autotools.
Both versions compile, link and load just fine with either Pd version.
I'm using the Developer command prompt, these are my commands:
cl /W3 /DNT /DPD /nologo /I. /IPDSOURCEPATH /c testobj.c link /dll /export:testobj_setup testobj.obj oldnames.lib kernel32.lib
PDBINPATH\pd.lib
Christof
Gesendet: Mittwoch, 23. Mai 2018 um 12:01 Uhr Von: "Pierre Guillot" <guillotpierre6@gmail.com[mailto:
guillotpierre6@gmail.com]>
An: "IOhannes m zmoelnig" <zmoelnig@iem.at[mailto:zmoelnig@iem.at]> Cc: pd-dev <pd-dev@lists.iem.at[mailto:pd-dev@lists.iem.at]> Betreff: Re: [PD-dev] pd.lib & msvc - missing symbols
however, it would be nice if the shipped pd.lib (which uses the MinGW toolchain and doesn't have the MSVC tools) would contain all the required symbols.
Yes, what seems strange is that s_list and s_signal were defined in the
shipped pd.def but not in pd.lib...
otoh, i do think that those global variables (`e.g. `s_float`)
shouldn't
be used in the first place: use the `gensym()` equivalents.
Why? I used these variable because I assumed that they are more efficient
than using `gensym()` (and as they are defined EXTERN I also assumed that they can be used).
But yes perhaps a better solution would be to generate and store the
symbols in the new method of the object using `gensym()` (and it will be the same but for the sustainability of old codes, these symbols must be included).
Thanks
2018-05-23 11:38 GMT+02:00 IOhannes m zmoelnig <zmoelnig@iem.at[mailto:
zmoelnig@iem.at][mailto:zmoelnig@iem.at[mailto:zmoelnig@iem.at]]>:On 2018-05-23 11:29, Pierre Guillot wrote:
But there are missing symbols: on Windows 64bit I can't use s_list and s_signal for example. I solved the issue
by
creating my own pd.lib and pd.def from pd.dll. So if you encounter the
same
issue, you can simply do
dumpbin /EXPORTS pd.dll > pd.exports lib /def:pd.def /out:pd.lib
the problem with this is that it requires MSVC tools now, the target audience are MSVC-users (who else needs that pd.lib...), so they already have it. however, it would be nice if the shipped pd.lib (which uses the MinGW toolchain and doesn't have the MSVC tools) would contain all the required symbols.
otoh, i do think that those global variables (`e.g. `s_float`) shouldn't be used in the first place: use the `gensym()` equivalents.
gasdmr IOhannes
I hope it could help some of you. Perhaps we could add a documentation somewhere about it... (I don't know if it useful...) I can help if
needed.
Pd-dev mailing list Pd-dev@lists.iem.at[mailto:Pd-dev@lists.iem.at][mailto:Pd-
dev@lists.iem.at[mailto:Pd-dev@lists.iem.at]]
https://lists.puredata.info/listinfo/pd-dev%5Bhttps://lists.
puredata.info/listinfo/pd-dev]
_______________________________________________ Pd-dev mailing list
Pd-dev@lists.iem.at[mailto:Pd-dev@lists.iem.at] https://lists.puredata.info/listinfo/pd-dev%5Bhttps://lists. puredata.info/listinfo/pd-dev]
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
-
Christof Ressi -
IOhannes m zmoelnig -
Pierre Guillot