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-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[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
