[PD] Using externals with libpd on Windows

Fri May 25 18:37:25 CEST 2018

As an update for any potential future Pd-nauts...

The issue: Why don't my 3rd party externals load in libpd within my Windows
application?

The cause: It's due to pre-compiled dlls for Windows implictly linking
against Pd/bin/pd.dll. The external dll get's unloaded when it's pd.dll
dependency can not be found.

The solution:  Modify the libpd MINGW makefile so that the library output
is pd.dll instead of libpd.dll

Many thanks to the help from @Chrisof, who also kindly submitted a PR with
some more discussion here: https://github.com/libpd/libpd/pull/241

Thanks,
Joe

On 21 May 2018 at 11:38, Christof Ressi <christof.ressi at gmx.at> wrote:

> hmmm, I might try it myself in the next few days.
>
> BTW,
>
> > also using the windows .lib to statically import the symbols.
>
> the import library (.lib) is only necessary if you work with MSVC, GCC can
> directly link to a DLL
>
>
>
> Gesendet: Montag, 21. Mai 2018 um 12:10 Uhr
> Von: "Joe White" <white.joe4 at gmail.com>
> An: "Christof Ressi" <christof.ressi at gmx.at>
> Cc: Pd-list <pd-list at lists.iem.at>
> Betreff: Re: Re: [PD] Using externals with libpd on Windows
>
> I'm linking against libpd dynamically, also using the windows .lib to
> statically import the symbols.
>
> On 18 May 2018 at 19:35, Christof Ressi <christof.ressi at gmx.at[mailto:
> christof.ressi at gmx.at]> wrote:just to be sure: are you using a static or
> dynamic version of libpd in your program?
>
> Gesendet: Freitag, 18. Mai 2018 um 17:38 Uhr
> Von: "Joe White" <white.joe4 at gmail.com[mailto:white.joe4 at gmail.com]>
> An: "Christof Ressi" <christof.ressi at gmx.at[mailto:christof.ressi at gmx.at]>
> Cc: Pd-list <pd-list at lists.iem.at[mailto:pd-list at lists.iem.at]>
> Betreff: Re: [PD] Using externals with libpd on Windows
>
> Thanks for the info Christof!
>
> It seems to me that compiling libpd via the makefile [0] in mingw already
> exports all the symbols correctly.
>
>
> Seems like the solution in your link [1] suggests to export the symbols in
> the exe, and also update the plugins to load the functions via
> GetProcAddress. I'm trying to avoid touching the 3rd party externals if
> possible as I can already re-link them against the libpd.dll but don't feel
> that is very maintainable.
>
> Has anyone managed to successfully load pre-compiled externals in a
> libpd-embedded Windows application?
>
> I'm currently trying to see if it's possible to point the externals to the
> find the pd symbols elsewhere as they get loaded, but my hopes aren't high!
>
> Thanks,
> Joe
>
> [0] https://github.com/libpd/libpd/blob/master/Makefile#
> L23[https://github.com/libpd/libpd/blob/master/Makefile#L23]
> [1] http://forums.codeguru.com/showthread.php?536343-
> RESOLVED-accessing-symbols-in-appllication-from-within-
> dynamic-library-MinGW[http://forums.codeguru.com/showthread.php?536343-
> RESOLVED-accessing-symbols-in-appllication-from-within-
> dynamic-library-MinGW][http://forums.codeguru.com/showthread.php?536343-
> RESOLVED-accessing-symbols-in-appllication-from-within-
> dynamic-library-MinGW[http://forums.codeguru.com/showthread.php?536343-
> RESOLVED-accessing-symbols-in-appllication-from-within-
> dynamic-library-MinGW]]
>
> On 11 May 2018 at 20:04, Christof Ressi <christof.ressi at gmx.at[mailto:
> christof.ressi at gmx.at][mailto:christof.ressi at gmx.at[mailto:c
> hristof.ressi at gmx.at]]> wrote:yes, this is a limitation on windows where
> a DLL can't automatically import symbols from the executable where it was
> loaded (what you get on Linux with --export-dynamic). for Pd the solution
> is to make the app itself a thin wrapper around a DLL (pd.dll) which
> plugins can link to.
>
> I found this link which might be helpful:
>
> http://forums.codeguru.com/showthread.php?536343-
> RESOLVED-accessing-symbols-in-appllication-from-within-
> dynamic-library-MinGW[http://forums.codeguru.com/showthread.php?536343-
> RESOLVED-accessing-symbols-in-appllication-from-within-
> dynamic-library-MinGW][http://forums.codeguru.com/showthread.php?536343-
> RESOLVED-accessing-symbols-in-appllication-from-within-
> dynamic-library-MinGW[http://forums.codeguru.com/showthread.php?536343-
> RESOLVED-accessing-symbols-in-appllication-from-within-
> dynamic-library-MinGW]]
>
> I guess if you compile libpd as a DLL (with "--export-all-symbols")
> existing externals should load.
>
>
>
> Gesendet: Freitag, 11. Mai 2018 um 19:21 Uhr
> Von: "Joe White" <white.joe4 at gmail.com[mailto:white.joe4 at gmail.com
> ][mailto:white.joe4 at gmail.com[mailto:white.joe4 at gmail.com]]>
> An: Pd-list <pd-list at lists.iem.at[mailto:pd-list at lists.iem.at][mailto:pd
> -list at lists.iem.at[mailto:pd-list at lists.iem.at]]>
> Betreff: [PD] Using externals with libpd on Windows
>
> Hi all,
>
> 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.
>
> The patch was using vbap [0] and soundfile_info from iemlib [1].
>
> The issue I found was that the pre-built binaries that work in the window
> version of the Pd authoring environment were linking against pd.dll (I'm
> assuming from Pd/bin/) in order to correctly link against the plugin API
> methods exposed in m_pd.h.
>
> The solution I recently came to, though admittedly a bit of a hack, was to
> generate a custom VS2017 dll project for both vbap, and soundfile_info,
> include the relevant source files, and link against the compiled version of
> libpd to resolve the missing symbols instead of the authoring libraries.
>
> 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.
>
> From my days of making externals for macos, I don't think I ever had to
> link against Pd, but just include m_pd.h and be done.
>
> My question is whether this is usual behaviour when working with
> externals/libpd on Windows or if I'm missing something somewhere?
>
> Any perspective would be much appreciated!
>
> Thanks,
> Joe
>
> [0] https://puredata.info/downloads/vbap[https://
> puredata.info/downloads/vbap][1][https://puredata.info/
> downloads/vbap[https://puredata.info/downloads/vbap][1]]
> https://git.iem.at/pd/iemlib[https://git.iem.at/pd/
> iemlib]_______________________________________________[
> https://git.iem.at/pd/iemlib[https://git.iem.at/pd/iemlib]_
> ______________________________________________][https://git.
> iem.at/pd/iemlib[https://git.iem.at/pd/iemlib]_____________
> __________________________________[https://git.iem.at/pd/
> iemlib[https://git.iem.at/pd/iemlib]_______________________
> ________________________]] Pd-list at lists.iem.at[mailto:Pd
> -list at lists.iem.at][mailto:Pd-list at lists.iem.at[mailto:Pd-
> list at lists.iem.at]] mailing list UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list[https://
> lists.puredata.info/listinfo/pd-list][https://lists.
> puredata.info/listinfo/pd-list[https://lists.puredata.
> info/listinfo/pd-list]][https://lists.puredata.info/
> listinfo/pd-list[https://lists.puredata.info/listinfo/
> pd-list][https://lists.puredata.info/listinfo/pd-
> list[https://lists.puredata.info/listinfo/pd-list]]]
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20180525/6a860a3b/attachment.html>