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.re...@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.re...@gmx.at> > > An: "Pierre Guillot" <guillotpier...@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" <guillotpier...@gmail.com> > > An: "Christof Ressi" <christof.re...@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.re...@gmx.at[mailto: > christof.re...@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" <guillotpier...@gmail.com[mailto: > guillotpier...@gmail.com]> > > An: "IOhannes m zmoelnig" <zmoel...@iem.at[mailto:zmoel...@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 <zmoel...@iem.at[mailto: > zmoel...@iem.at][mailto:zmoel...@iem.at[mailto:zmoel...@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- > d...@lists.iem.at[mailto:Pd-dev@lists.iem.at]] > > https://lists.puredata.info/listinfo/pd-dev[https://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[https://lists. > puredata.info/listinfo/pd-dev] > > > > _______________________________________________ > > Pd-dev mailing list > > 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