Not sure what you mean.

If you make an external that needs another .dll, for example an mp3 player ext, and you use an 3th party lib like lib-somthing-mp3.dll.

Its a Windows fact that your compiled object “pdmp3.dll” will find “lib-somthing-mp3.dll” if it is in the same dir.

A proof for that is that if you check “pdmp3.dll” with http://www.dependencywalker.com/ it will say it`s ok if they are both in the same dir. And it will say that it can`t find it if its not there (same dir) or on system folders.

Other places that the system will search are for example pd/bin but that`s out of scope for  dependencywalker but you get the idea.

> To: pd-list@lists.iem.at
> From: thomas@residuum.org
> Date: Fri, 15 Jul 2016 14:10:28 +0200
> Subject: Re: [PD] w32 Deken package issues.
>
> On 15.07.2016 12:17, IOhannes m zmölnig wrote:
> > On 07/14/2016 08:17 PM, Thomas Mayer wrote:
> >> - I compile these dependencies (and their dependencies) in the
> >> resulting dlls, because there is no user-friendly way to tell
> >> users to download the dlls.
> >
> > hmm. i'm not sure i can follow here. i guess you meant "I link
> > these dependencies statically into the resulting dlls" when you
> > wrote "I compile these dependencies into the resulting dlls", as
> > there is no way to "compile" two binaries together. however, the
> > really unclear thing is whether you actually meant static linking
> > (or not).
>
> Yes, I meant staic linking.
>
> > also, what is wrong with just putting the dependency dlls *besides*
> > the external (as has been suggested).
>
> There was a bug in earlier versions of Pd (up to 0.43 I think), that
> Pd did not look in the same folder for a dependency. Before that, I
> had a shared library, but have removed it. But that can now safely be
> reverted, as I make new packages available from deken, and deken is
> bundled with Pd 0.47.
>
> >> - I do not know how to do it in Mac OS X, but as far as I can
> >> tell from pull requests that I have merged, it is more like on
> >> Windows than on Linux.
> >
> > i don't know about your pull requests, but OSX uses the unix way
> > to resolve dependencies (just like linux): the resulting binary
> > (your external) has a notion of where to look for a given
> > dependency, and if that fails it will search the system paths.
>
> The external has two shell scripts for embedding:
> https://github.com/residuum/PuRestJson/blob/master/embed-MacOSX-dependencies.sh
> https://github.com/residuum/PuRestJson/blob/master/embed-osx-dep-homebrew.sh
>
> I am not sure, if these are needed.
>
> I hope, I could make my thoughts clearer,
> Thomas
> --
> "Chaney was aware that anything, however small, can get the eye of the
> media if it's repulsive enough." (Robert Anton Wilson - The Universe
> Next Door)
> http://www.residuum.org/
>
> _______________________________________________
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list