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 its ok if they are both in the same dir. And it will say that it cant 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: 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... 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