There was a bug in earlier versions of Pd (up to 0.43 I think), thatPd did not look in the same folder for a dependency.
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. Mensaje telepatico asistido por maquinas. > To: [email protected] > From: [email protected] > 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/ > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
