<div dir="ltr">Hi all, <div><br></div><div>I recently spent a bit of time tracking down why a patch wasn't loading a couple of externals in a windows application that embeds libpd.</div><div><br></div><div>The patch was using <i>vbap</i> [0] and <i>soundfile_info</i> from iemlib [1].</div><div><br></div><div>The issue I found was that the pre-built binaries that work in the window version of the Pd authoring environment were linking against <b>pd.dll</b> (I'm assuming from Pd/bin/) in order to correctly link against the plugin API methods exposed in <b>m_pd.h</b>.</div><div><br></div><div>The solution I recently came to, though admittedly a bit of a hack, was to generate a custom VS2017 dll project for both <i>vbap</i>, and <i>soundfile_info</i>, include the relevant source files, and link against the compiled version of libpd to resolve the missing symbols instead of the authoring libraries.</div><div><br></div><div>The downside of this approach is that the manually compiled externals will no longer run in the Pd authoring environment, and it's not really maintainable from a development perspective. </div><div><br></div><div>From my days of making externals for macos, I don't think I ever had to link against Pd, but just include <b>m_pd.h</b> and be done.</div><div><br></div><div>My question is whether this is usual behaviour when working with externals/libpd on Windows or if I'm missing something somewhere?<br></div><div><br></div><div>Any perspective would be much appreciated!</div><div><br></div><div>Thanks,</div><div>Joe</div><div><br></div><div>[0] <a href="https://puredata.info/downloads/vbap">https://puredata.info/downloads/vbap</a></div><div>[1] <a href="https://git.iem.at/pd/iemlib">https://git.iem.at/pd/iemlib</a></div></div>