I am writing an extern that uses a 3rd party shared object library. I keep getting a "cannot open shared object file: No such file or directory" posted to the Pd console when I load the extern. The library is linking properly in my makefile (as far as I can tell) and the .so file that I want the extern to load is in the same folder as the extern. I have also put the path to the unfound library in Pd's path list.
I have also compiled a different, plain old dylib/shared object/dll using this very same library for use in python and it works perfectly. I've also written C and C++ programs that link to this library at run time and they work perfectly too. Does anybody have any idea why Pd hates it?
I have also done dynamic loading successfully in a Pd extern using the sphinx library. The only difference there was that there the sphinx libraries were installed in a standard library directory (ie /usr/lib or something like that) . I can't try to do this right now because I don't have su rights on the computer I am using. My understanding, though, is that linux should be searching for dynamic libraries in the directory that the parent application is in. So I also tried putting my unfound library in pd-0-whatever/bin. No joy.
I have tried compiling using gcc and g++ on linux. I've also tried to link with those compilers as well as ld (which is called by those compilers if you link with them). I haven't tried any other OSs yet.
Thanks in advance, David
I think you need to use Pd's c_externdir method to determine the extern's path. This is basicaly how I opened a .so in an external:
void *my_extern_tilde_new(t_symbol *s, int argc, t_atom *argv) { // creates the object t_my_extern *x = (t_my_extern *)pd_new(my_extern_class);
// using Pd's open_via_path to find myextern, and from there my_other_lib.so char *externdir = myextern_class->c_externdir->s_name; x->my_other_lib = dlopen(externdir, RTLD_NOW | RTLD_LOCAL); ...
Joel
On 01/09/2015 03:34 PM, David Medine wrote:
I am writing an extern that uses a 3rd party shared object library. I keep getting a "cannot open shared object file: No such file or directory" posted to the Pd console when I load the extern. The library is linking properly in my makefile (as far as I can tell) and the .so file that I want the extern to load is in the same folder as the extern. I have also put the path to the unfound library in Pd's path list.
I have also compiled a different, plain old dylib/shared object/dll using this very same library for use in python and it works perfectly. I've also written C and C++ programs that link to this library at run time and they work perfectly too. Does anybody have any idea why Pd hates it?
I have also done dynamic loading successfully in a Pd extern using the sphinx library. The only difference there was that there the sphinx libraries were installed in a standard library directory (ie /usr/lib or something like that) . I can't try to do this right now because I don't have su rights on the computer I am using. My understanding, though, is that linux should be searching for dynamic libraries in the directory that the parent application is in. So I also tried putting my unfound library in pd-0-whatever/bin. No joy.
I have tried compiling using gcc and g++ on linux. I've also tried to link with those compilers as well as ld (which is called by those compilers if you link with them). I haven't tried any other OSs yet.
Thanks in advance, David
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 09/01/15 21:34, David Medine wrote:
I am writing an extern that uses a 3rd party shared object library. I keep getting a "cannot open shared object file: No such file or directory"
Maybe set the LD_LIBRARY_PATH environment variable to the directory containing your 3rd party .so before starting Pd.
Or rewrite your extern to use dlopen() dlsym() etc (which would be a pain if your .so has a lot of symbols you need to reference).
posted to the Pd console when I load the extern. The library is linking properly in my makefile (as far as I can tell) and the .so file that I want the extern to load is in the same folder as the extern.
Claude
Thanks for this.
Yeah, I forgot to mention that I also set the LD_LIBRARY_PATH variable to the correct directory. I hope not to have to use dynamic loading in the code, particularly since I want this to work on Windows eventually as well.
On 1/9/2015 2:12 PM, Claude Heiland-Allen wrote:
On 09/01/15 21:34, David Medine wrote:
I am writing an extern that uses a 3rd party shared object library. I keep getting a "cannot open shared object file: No such file or directory"
Maybe set the LD_LIBRARY_PATH environment variable to the directory containing your 3rd party .so before starting Pd.
Or rewrite your extern to use dlopen() dlsym() etc (which would be a pain if your .so has a lot of symbols you need to reference).
posted to the Pd console when I load the extern. The library is linking properly in my makefile (as far as I can tell) and the .so file that I want the extern to load is in the same folder as the extern.
Claude
Indeed, the ldl methods seem to work, but this is a horrible pain. It means sprintf-ing together function calls, and it will mean no little #ifdef _WIN32 statements. Blech!
Maybe somewhere on stackoverflow there is an answer to this problem. It does seem to be Pd specific, though. Cheers, David
On 1/9/2015 3:04 PM, David Medine wrote:
Thanks for this.
Yeah, I forgot to mention that I also set the LD_LIBRARY_PATH variable to the correct directory. I hope not to have to use dynamic loading in the code, particularly since I want this to work on Windows eventually as well.
On 1/9/2015 2:12 PM, Claude Heiland-Allen wrote:
On 09/01/15 21:34, David Medine wrote:
I am writing an extern that uses a 3rd party shared object library. I keep getting a "cannot open shared object file: No such file or directory"
Maybe set the LD_LIBRARY_PATH environment variable to the directory containing your 3rd party .so before starting Pd.
Or rewrite your extern to use dlopen() dlsym() etc (which would be a pain if your .so has a lot of symbols you need to reference).
posted to the Pd console when I load the extern. The library is linking properly in my makefile (as far as I can tell) and the .so file that I want the extern to load is in the same folder as the extern.
Claude
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Have a look at the aubio external; that uses an external lib and is cross-platform. Looks like it uses waf instead of a makefile though.
http://puredata.info/downloads/aubio/
Joel
On 01/09/2015 05:52 PM, David Medine wrote:
Indeed, the ldl methods seem to work, but this is a horrible pain. It means sprintf-ing together function calls, and it will mean no little #ifdef _WIN32 statements. Blech!
Maybe somewhere on stackoverflow there is an answer to this problem. It does seem to be Pd specific, though. Cheers, David
On 1/9/2015 3:04 PM, David Medine wrote:
Thanks for this.
Yeah, I forgot to mention that I also set the LD_LIBRARY_PATH variable to the correct directory. I hope not to have to use dynamic loading in the code, particularly since I want this to work on Windows eventually as well.
On 1/9/2015 2:12 PM, Claude Heiland-Allen wrote:
On 09/01/15 21:34, David Medine wrote:
I am writing an extern that uses a 3rd party shared object library. I keep getting a "cannot open shared object file: No such file or directory"
Maybe set the LD_LIBRARY_PATH environment variable to the directory containing your 3rd party .so before starting Pd.
Or rewrite your extern to use dlopen() dlsym() etc (which would be a pain if your .so has a lot of symbols you need to reference).
posted to the Pd console when I load the extern. The library is linking properly in my makefile (as far as I can tell) and the .so file that I want the extern to load is in the same folder as the extern.
Claude
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Thanks to everyone for all the help. I solved my problem. It turned out to be an environment variable typo that was biting me all along. -David
On 1/9/15 7:32 PM, Joel Matthys wrote:
Have a look at the aubio external; that uses an external lib and is cross-platform. Looks like it uses waf instead of a makefile though.
http://puredata.info/downloads/aubio/
Joel
On 01/09/2015 05:52 PM, David Medine wrote:
Indeed, the ldl methods seem to work, but this is a horrible pain. It means sprintf-ing together function calls, and it will mean no little #ifdef _WIN32 statements. Blech!
Maybe somewhere on stackoverflow there is an answer to this problem. It does seem to be Pd specific, though. Cheers, David
On 1/9/2015 3:04 PM, David Medine wrote:
Thanks for this.
Yeah, I forgot to mention that I also set the LD_LIBRARY_PATH variable to the correct directory. I hope not to have to use dynamic loading in the code, particularly since I want this to work on Windows eventually as well.
On 1/9/2015 2:12 PM, Claude Heiland-Allen wrote:
On 09/01/15 21:34, David Medine wrote:
I am writing an extern that uses a 3rd party shared object library. I keep getting a "cannot open shared object file: No such file or directory"
Maybe set the LD_LIBRARY_PATH environment variable to the directory containing your 3rd party .so before starting Pd.
Or rewrite your extern to use dlopen() dlsym() etc (which would be a pain if your .so has a lot of symbols you need to reference).
posted to the Pd console when I load the extern. The library is linking properly in my makefile (as far as I can tell) and the .so file that I want the extern to load is in the same folder as the extern.
Claude
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Claude Heiland-Allen -
David Medine -
david medine
-
Joel Matthys