In a last attempt I've written
extern "C" __declspec(dllexport) void readanysf_tilde_setup(void)
and now pd can load the external
I've attached the dll if someone (matteo?) wants to try
I've tried an mp3 file it crashed but it could read audio from a mov file
----- "Patrice Colet" colet.patrice@free.fr a écrit :
I even tried to put manually:
__declspec(dllexport) void readanysf_tilde_setup(void)
but still same error pd can't read it, there is nothing else I can do, someone with better knowledge of makefile should look at it.
attached is attempt to rewrite a makefile that compiles on mingw, and that would be easy to adapt for linux and osx, it's inspired from gridflow/Makefile
----- "august" august@alien.mur.at a écrit :
I did notice that in externals/frankenstein/Makefile, it does this for Visual Studio:
link /dll /export:$*_setup $*.obj common.obj $(PDNTLIB)
Are extra linking directives necessary for mingw externals?
As for C++ files and the template Makefile, you might be able to
just
set "CC=cpp" somewhere before it starts the compile
Would be great to FINALLY get this thing going in windows. :)
still doesn't recognize readanysf_tilde_setup even with
-Wl,--enable-auto-import
by defining -DMSW in CFLAGS the compiler should read this macro
in
m_pd.h:
#define EXTERN __declspec(dllimport) extern
but it doesn't
is there a more explicit template makefile for cpp sources?
the only working example that work I can get is from gridflow but
it's so tricky,
sources are processed with ruby before being compiled by g++
----- "august" august@alien.mur.at a écrit :
Patrice,
Here is a new Makefile that I made looking at the template
base.
I think this should take care of exporting the tilde_setup
symbol.
again, doing it blindly...so there may be errors.
-august.
After resolving two dozens undefined references I finally
have
readanysf compiled.
Curiously gmerlin_avdec needs a prepended link of each used
library.
The link flags must be at the end, like in attached file.
I had to copy missing dll's into pd/bin along with other libs
provided py pd-extended and gridflow,
libdca-0.dll libgavl-1.dll libiconv-2.dll libintl-8.dll
libtheora-0.dll lib-tiff-3.dll
it seems it's still not the good way to compile because pd
complains:
load_object: Symbol "readanysf_tilde_setup" not found
----- "august" august@alien.mur.at a écrit :
Yeah perhaps it will be easier with the pd-extended
makefiles.
I
really have no idea how windows handles linking and I also don't
have
experience with pd-extended builds.
One problem you might have with my makefile that I didn't
see
before
is that I test to see if the system is linux. If so, I set
appropriate
flags. If not, I assume you have a mac and set other
flags.
I've attached a Makefile.win that might work for you. I
made
it
blindly since I don't have a windows setup.
You should only need to edit these two lines: GAVLPREFIX=/usr/local PD_INCLUDES=/usr/include
Maybe something else is needed, but I can't say. It should
be
simple
enough to build from.
best -august.
> I've tried to hack the makefile but have pain to get it
compiling
the dll because of linking problems... > I guess it would be easier by using pd-extended externals
Makefile
for resolving differences between os > > ----- "august" august@alien.mur.at a écrit : > > > well, if you already have gavl and gmerlin-avdecoder,
you
should
only > > need to download and compile readanysf~ > > > > the Makefile is there already. If I am not mistaken,
you
would
only > > need to copy and modify the pd_linux target so that it
creates
a
> > readanysf~.dll instead of a readanysf~.pd_linux > > > > ...and then package it in a bundle so that it is usable
for
windows > > users. ...that will be the hard part I imagine. > > > > > > > Hello, I've applied this patch then gmerlin-avdecoder
compiles
fine > > on mingw > > > > > > > >
http://www.mail-archive.com/gmerlin-general@lists.sourceforge.net/msg00322.h...
> > > > > > now we need the makefile ;) > > > > > > ----- "Hans-Christoph Steiner" hans@at.or.at a
écrit
:
> > > > > > > We just need someone to get all of the required
libraries
building > > on > > > > Windows/MinGW. gmerlin-avdecoder is required, then
the
more
> > codec > > > > libs, > > > > the better, but it'll work without any of them, it
just
won't
open > > as > > > > many files. Once we have that, making a Windows
build
of
> > > > [readanysf~] > > > > will be easy. > > > > > > > > .hc > > > > > > > > On Wed, 27 Apr 2011 13:56 +0200, "matteo sisti
sette"
> > > > matteosistisette@gmail.com wrote: > > > > > Hi, > > > > > > > > > > Is there anything similar to readanysf~ available
for
Windows? > > I > > > > would > > > > > like to be able to read the audio from mov video
files.
> > > > > > > > > > I've found some very old threads about failed
attempts
to
port > > > > > readanysf~ to windows. > > > > > Has there been any success since then? Anybody
that
has
been > > able > > > > to > > > > > compile it for windows and could share the
compiled
binary?
> > > > > > > > > > Or any similar external? > > > > > > > > > > thanks > > > > > m. > > > > > > > > > > -- > > > > > Matteo Sisti Sette > > > > > matteosistisette@gmail.com > > > > > http://www.matteosistisette.com > > > > > > > > > > _______________________________________________ > > > > > Pd-list@iem.at mailing list > > > > > UNSUBSCRIBE and account-management -> > > > > > http://lists.puredata.info/listinfo/pd-list > > > > > > > > > > > > > _______________________________________________ > > > > Pd-list@iem.at mailing list > > > > UNSUBSCRIBE and account-management -> > > > > http://lists.puredata.info/listinfo/pd-list > > > > > > -- > > > Patrice Colet > > > > > > _______________________________________________ > > > Pd-list@iem.at mailing list > > > UNSUBSCRIBE and account-management -> > > http://lists.puredata.info/listinfo/pd-list > > > > -- > > ------------------- > > http://aug.ment.org > > -- > Patrice Colet > > _______________________________________________ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
--
-- Patrice Colet
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
--
-- Patrice Colet
--
-- Patrice Colet
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
sorry for the OT noise but... Patrice, it looks like your mail reader does not follow the 'reply-to topic' rule, i.e. each of your message appears as a new thread, which is pretty boring with long threads like this one in a decent mail reader.
cheers, _y
Thank you for telling me, but I don't now how to fix this, sometimes it follow the thread, sometimes not, let me try out how this one will be displayed on the archive... It's boring indeed when mails don't follow the thread.
----- "yvan volochine" yvan.pd@gmail.com a écrit :
sorry for the OT noise but... Patrice, it looks like your mail reader does not follow the 'reply-to
topic' rule, i.e. each of your message appears as a new thread, which is pretty boring with long threads like this one in a decent mail reader.
cheers, _y
On 04/28/2011 11:15 PM, Patrice Colet wrote:
Thank you for telling me, but I don't now how to fix this, sometimes it follow the thread, sometimes not, let me try out how this one will be displayed on the archive... It's boring indeed when mails don't follow the thread.
yeah this one worked =)
again sorry for the OT..
cheers, _y
Ah yes, its C++, so you need the 'extern "C"' stuff to expose the
symbols to C.
.hc
On Apr 28, 2011, at 1:07 PM, Patrice Colet wrote:
In a last attempt I've written
extern "C" __declspec(dllexport) void readanysf_tilde_setup(void)
and now pd can load the external
I've attached the dll if someone (matteo?) wants to try
I've tried an mp3 file it crashed but it could read audio from a mov
file----- "Patrice Colet" colet.patrice@free.fr a écrit :
I even tried to put manually:
__declspec(dllexport) void readanysf_tilde_setup(void)
but still same error pd can't read it, there is nothing else I can do, someone with better knowledge of makefile should look at it.
attached is attempt to rewrite a makefile that compiles on mingw, and that would be easy to adapt for linux and osx, it's inspired from gridflow/Makefile
----- "august" august@alien.mur.at a écrit :
I did notice that in externals/frankenstein/Makefile, it does this for Visual Studio:
link /dll /export:$*_setup $*.obj common.obj $(PDNTLIB)
Are extra linking directives necessary for mingw externals?
As for C++ files and the template Makefile, you might be able to
just
set "CC=cpp" somewhere before it starts the compile
Would be great to FINALLY get this thing going in windows. :)
still doesn't recognize readanysf_tilde_setup even with
-Wl,--enable-auto-import
by defining -DMSW in CFLAGS the compiler should read this macro
in
m_pd.h:
#define EXTERN __declspec(dllimport) extern
but it doesn't
is there a more explicit template makefile for cpp sources?
the only working example that work I can get is from gridflow but
it's so tricky,
sources are processed with ruby before being compiled by g++
----- "august" august@alien.mur.at a écrit :
Patrice,
Here is a new Makefile that I made looking at the template
base.
I think this should take care of exporting the tilde_setup
symbol.
again, doing it blindly...so there may be errors.
-august.
After resolving two dozens undefined references I finally
have
readanysf compiled.
Curiously gmerlin_avdec needs a prepended link of each used
library.
The link flags must be at the end, like in attached file.
I had to copy missing dll's into pd/bin along with other libs
provided py pd-extended and gridflow,
libdca-0.dll libgavl-1.dll libiconv-2.dll libintl-8.dll
libtheora-0.dll lib-tiff-3.dll
it seems it's still not the good way to compile because pd
complains:
load_object: Symbol "readanysf_tilde_setup" not found
----- "august" august@alien.mur.at a écrit :
> Yeah perhaps it will be easier with the pd-extended
makefiles.
I
> really > have no idea how windows handles linking and I also don't
have
> experience with pd-extended builds. > > > One problem you might have with my makefile that I didn't
see
before
> is > that I test to see if the system is linux. If so, I set
appropriate
> flags. If not, I assume you have a mac and set other
flags.
> > > I've attached a Makefile.win that might work for you. I
made
it
> blindly > since I don't have a windows setup. > > You should only need to edit these two lines: > GAVLPREFIX=/usr/local > PD_INCLUDES=/usr/include > > Maybe something else is needed, but I can't say. It should
be
simple
> enough to build from. > > best -august. > > > >> I've tried to hack the makefile but have pain to get it
compiling
> the dll because of linking problems... >> I guess it would be easier by using pd-extended externals
Makefile
> for resolving differences between os >> >> ----- "august" august@alien.mur.at a écrit : >> >>> well, if you already have gavl and gmerlin-avdecoder,
you
should
> only >>> need to download and compile readanysf~ >>> >>> the Makefile is there already. If I am not mistaken,
you
would
> only >>> need to copy and modify the pd_linux target so that it
creates
a
>>> readanysf~.dll instead of a readanysf~.pd_linux >>> >>> ...and then package it in a bundle so that it is usable
for
> windows >>> users. ...that will be the hard part I imagine. >>> >>> >>>> Hello, I've applied this patch then gmerlin-avdecoder
compiles
> fine >>> on mingw >>>> >>>> >>> >
http://www.mail-archive.com/gmerlin-general@lists.sourceforge.net/msg00322.h...
>>>> >>>> now we need the makefile ;) >>>> >>>> ----- "Hans-Christoph Steiner" hans@at.or.at a
écrit
:
>>>> >>>>> We just need someone to get all of the required
libraries
> building >>> on >>>>> Windows/MinGW. gmerlin-avdecoder is required, then
the
more
>>> codec >>>>> libs, >>>>> the better, but it'll work without any of them, it
just
won't
> open >>> as >>>>> many files. Once we have that, making a Windows
build
of
>>>>> [readanysf~] >>>>> will be easy. >>>>> >>>>> .hc >>>>> >>>>> On Wed, 27 Apr 2011 13:56 +0200, "matteo sisti
sette"
>>>>> matteosistisette@gmail.com wrote: >>>>>> Hi, >>>>>> >>>>>> Is there anything similar to readanysf~ available
for
> Windows? >>> I >>>>> would >>>>>> like to be able to read the audio from mov video
files.
>>>>>> >>>>>> I've found some very old threads about failed
attempts
to
> port >>>>>> readanysf~ to windows. >>>>>> Has there been any success since then? Anybody
that
has
> been >>> able >>>>> to >>>>>> compile it for windows and could share the
compiled
binary?
>>>>>> >>>>>> Or any similar external? >>>>>> >>>>>> thanks >>>>>> m. >>>>>> >>>>>> -- >>>>>> Matteo Sisti Sette >>>>>> matteosistisette@gmail.com >>>>>> http://www.matteosistisette.com >>>>>> >>>>>> _______________________________________________ >>>>>> Pd-list@iem.at mailing list >>>>>> UNSUBSCRIBE and account-management -> >>>>>> http://lists.puredata.info/listinfo/pd-list >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Pd-list@iem.at mailing list >>>>> UNSUBSCRIBE and account-management -> >>>>> http://lists.puredata.info/listinfo/pd-list >>>> >>>> -- >>>> Patrice Colet >>>> >>>> _______________________________________________ >>>> Pd-list@iem.at mailing list >>>> UNSUBSCRIBE and account-management -> >>> http://lists.puredata.info/listinfo/pd-list >>> >>> -- >>> ------------------- >>> http://aug.ment.org >> >> -- >> Patrice Colet >> >> _______________________________________________ >> Pd-list@iem.at mailing list >> UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > > -- > ------------------- > http://aug.ment.org
-- Patrice Colet
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
--
-- Patrice Colet
--
-- Patrice Colet
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-- Patrice Colet <readanysf~.zip>
Looking at things from a more basic level, you can come up with a more
direct solution... It may sound small in theory, but it in practice,
it can change entire economies. - Amy Smith
When I try to create it, it tells me it is missing libdca-0.dll. I am trying it in Pd Vanilla but I can't find libdca-0.dll anywhere in my hard drive even if I have Pd Extended installed.
I thought I could easily find it with Google but I couldn't, I guess there will be more missing dlls... does anybody know where I could get them?
thanks m.
2011/4/29 matteo sisti sette matteosistisette@gmail.com:
I've attached the dll if someone (matteo?) wants to try
Wow great! Of course I will try it and even stress it a little bit :)
Ok sorry I'm finding the dll's one by one, I just hadn't googled hard enough.
On the other hand, I'm seing that I have to put them in the pd/bin directory: putting them in the patch directory won't do. Is that normal? Shouldn't Pd look for dll's also in the patch directory just as it does when it looks for an external? That way, when you have a patch that needs some external, which in turn depends on some dll's, you would be able to pack all the dependencies in the patch directory
- that is altready possible with externals that don't, in turn, depend
on other dll's.
2011/4/29 matteo sisti sette matteosistisette@gmail.com:
When I try to create it, it tells me it is missing libdca-0.dll. I am trying it in Pd Vanilla but I can't find libdca-0.dll anywhere in my hard drive even if I have Pd Extended installed.
I thought I could easily find it with Google but I couldn't, I guess there will be more missing dlls... does anybody know where I could get them?
thanks m.
2011/4/29 matteo sisti sette matteosistisette@gmail.com:
I've attached the dll if someone (matteo?) wants to try
Wow great! Of course I will try it and even stress it a little bit :)
-- Matteo Sisti Sette matteosistisette@gmail.com http://www.matteosistisette.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/29/2011 11:35 AM, matteo sisti sette wrote:
normal? Shouldn't Pd look for dll's also in the patch directory just as it does when it looks for an external? That way, when you have a
those dll's are dependencies of readanysf~.dll. Pd doesn't know anything about them; Pd only finds readanysf~.dll and tells W32 to load this library. the w32 dynamic linker will then check which additional libraries are needed for readanysf~.dll to work and try to open them. the linker will look for those dlls in some standard places (like "%WINDOWS%\System32", probably the entire %PATH%), and "near" the calling application (path\to\pd.exe). afaik, it will also search for the libraries in the same directory as the readanysf.dll lives (which is not necessarily the same as the "patch directory").
the dynamic linker of w32 will definitely ignore your Pd-search paths.
so all in all, it is not Pd that is (not) finding those dlls, but your operating system.
gmasdr IOhannes
those dll's are dependencies of readanysf~.dll. Pd doesn't know anything about them; Pd only finds readanysf~.dll and tells W32 to load this library.
Of course. But I thought readanysf~ coud do something to tell the operating system to search also the current path...
afaik, it will also search for the libraries in the same directory as the readanysf.dll lives (which is not necessarily the same as the "patch directory").
Apparently it doesn't. I had put the dll's in the same folder where I put readanysf~.dll but it didn't find them
so all in all, it is not Pd that is (not) finding those dlls, but your operating system.
Ok, I thought the external could give some hint to the operating system...
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/29/2011 12:23 PM, matteo sisti sette wrote:
Apparently it doesn't. I had put the dll's in the same folder where I put readanysf~.dll but it didn't find them
weird. i'm pretty sure this is the way it is supposed to work (but i'm no w32 expert)
so all in all, it is not Pd that is (not) finding those dlls, but your operating system.
Ok, I thought the external could give some hint to the operating system...
that's a bootstrapping problem, as the external cannot run any code before all it's dependencies are resolved. maybe there is some magic linker flag to do that though.
fgmadsr IOhannes
On Apr 29, 2011, at 3:40 AM, IOhannes m zmölnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/29/2011 12:23 PM, matteo sisti sette wrote:
Apparently it doesn't. I had put the dll's in the same folder where I put readanysf~.dll but it didn't find them
weird. i'm pretty sure this is the way it is supposed to work (but i'm no w32 expert)
Windows and Mac OS X both use the path of the executable for finding
other dlls, but not the path of each dll that is loaded (that could be
a lot of paths). I think GNU/Linux might do the same, I don't
remember off the top of my head, but you so rarely encounter this on
GNU/Linux since you're almost always installing dlls in the path (/usr/
lib, /usr/local/lib).
With the Mac version of readanysf~, the libraries are loaded from a
statically defined path (/Library/Pd/readanysf~). So to make an
easily deployable readanysf~ for Windows, this issue will have to be
sorted out.
.hc
so all in all, it is not Pd that is (not) finding those dlls, but
your operating system.Ok, I thought the external could give some hint to the operating
system...that's a bootstrapping problem, as the external cannot run any code before all it's dependencies are resolved. maybe there is some magic linker flag to do that though.
fgmadsr IOhannes
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk26lawACgkQkX2Xpv6ydvSu9ACfeEbjCZ3vqh2BYeDX1/hFYeYk cVwAnRio1Le+UpStOvUV52ujDkV5on9c =s5K3 -----END PGP SIGNATURE-----
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
"[T]he greatest purveyor of violence in the world today [is] my own
government." - Martin Luther King, Jr.
Windows and Mac OS X both use the path of the executable for finding other dlls, but not the path of each dll that is loaded (that could be a lot of paths). I think GNU/Linux might do the same, I don't remember off the top of my head, but you so rarely encounter this on GNU/Linux since you're almost always installing dlls in the path (/usr/lib, /usr/local/lib).
With the Mac version of readanysf~, the libraries are loaded from a statically defined path (/Library/Pd/readanysf~). So to make an easily deployable readanysf~ for Windows, this issue will have to be sorted out.
Any suggestion on how to do that Hans? Is there a way to make it so that it tightly integrates with Pd-extended?
On Apr 29, 2011, at 9:02 AM, august wrote:
Windows and Mac OS X both use the path of the executable for finding other dlls, but not the path of each dll that is loaded (that could be a lot of paths). I think GNU/Linux might do the same, I don't remember off the top of my head, but you so rarely encounter this on GNU/Linux since you're almost always installing dlls in the path (/usr/lib, /usr/local/lib).
With the Mac version of readanysf~, the libraries are loaded from a statically defined path (/Library/Pd/readanysf~). So to make an easily deployable readanysf~ for Windows, this issue will have to be sorted out.
Any suggestion on how to do that Hans? Is there a way to make it so that it tightly integrates with Pd-extended?
That part of Windows linking I don't know, so the thing to do is to
find whether there is a way to add to the DLL load path, then make
readanysf~ do that. That's probably a single function call.
Otherwise, people will need to install the DLLs into pd\bin or \Windows
\system32.
.hc
As we enjoy great advantages from inventions of others, we should be
glad of an opportunity to serve others by any invention of ours; and
this we should do freely and generously. - Benjamin Franklin
Windows and Mac OS X both use the path of the executable for finding other dlls, but not the path of each dll that is loaded (that could be a lot of paths). I think GNU/Linux might do the same, I don't remember off the top of my head, but you so rarely encounter this on GNU/Linux since you're almost always installing dlls in the path (/usr/lib, /usr/local/lib).
With the Mac version of readanysf~, the libraries are loaded from a statically defined path (/Library/Pd/readanysf~). So to make an easily deployable readanysf~ for Windows, this issue will have to be sorted out.
Any suggestion on how to do that Hans? Is there a way to make it so that it tightly integrates with Pd-extended?
That part of Windows linking I don't know, so the thing to do is to find whether there is a way to add to the DLL load path, then make readanysf~ do that. That's probably a single function call. Otherwise, people will need to install the DLLs into pd\bin or \Windows\system32.
.hc
I guess what I am asking, is that now that it exists for all platforms, what in your opinion is the best strategy for including it in pd-extended? Or, is it already included?
Are there any other externals that package .dll's and .so files in pd-extended? Maybe we can look at this tomorrow in LA (if I make it).
On Apr 29, 2011, at 10:04 AM, august wrote:
Windows and Mac OS X both use the path of the executable for
finding other dlls, but not the path of each dll that is loaded (that could be a lot of paths). I think GNU/Linux might do the same, I don't remember off the top of my head, but you so rarely encounter this
on GNU/Linux since you're almost always installing dlls in the path (/usr/lib, /usr/local/lib).With the Mac version of readanysf~, the libraries are loaded from a statically defined path (/Library/Pd/readanysf~). So to make an easily deployable readanysf~ for Windows, this issue will have to
be sorted out.Any suggestion on how to do that Hans? Is there a way to make it so that it tightly integrates with Pd-extended?
That part of Windows linking I don't know, so the thing to do is to find whether there is a way to add to the DLL load path, then make readanysf~ do that. That's probably a single function call. Otherwise, people will need to install the DLLs into pd\bin or \Windows\system32.
.hc
I guess what I am asking, is that now that it exists for all
platforms, what in your opinion is the best strategy for including it in pd-extended? Or, is it already included?Are there any other externals that package .dll's and .so files in pd-extended? Maybe we can look at this tomorrow in LA (if I make it).
It would be good to first get out some standalone builds and work out
the kinks. Then you'll have a way to make standalone builds on your
own release schedule. Once its in Pd-extended, your release schedule
will be entirely tied to Pd-extended's release schedule. From what
I've seen, that only really works for very active devs or rarely
changing libraries. I can't take on any more maintenance, I'm already
well overloaded with what I've got.
.hc
I have always wished for my computer to be as easy to use as my
telephone; my wish has come true because I can no longer figure out
how to use my telephone." --Bjarne Stroustrup (creator of C++)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-04-29 17:54, Hans-Christoph Steiner wrote:
On Apr 29, 2011, at 3:40 AM, IOhannes m zmölnig wrote:
On 04/29/2011 12:23 PM, matteo sisti sette wrote:
Apparently it doesn't. I had put the dll's in the same folder where I put readanysf~.dll but it didn't find them
weird. i'm pretty sure this is the way it is supposed to work (but i'm no w32 expert)
Windows and Mac OS X both use the path of the executable for finding other dlls, but not the path of each dll that is loaded (that could be a lot of paths)
no of course; i meant the path that the currently-being-resolved dll lives in. this would be an extra path for each dll.
I think GNU/Linux might do the same, I don't remember
no it does not. you need to modify the DL_SEARCH_PATH if you want that.
also w32 discovered [1], that their standard search paths might have security implications....
a simple approach would be to modify the system's search paths before dlopen()ing the externals from within Pd to include the path of the currently loaded external (and revert this path to the original after loading)
fgmasdr IOhannes
[1] http://msdn.microsoft.com/en-us/library/ms972822.aspx
I've attached the dll if someone (matteo?) wants to try
Wow great! Of course I will try it and even stress it a little bit :)
yes, please stress it extensively.
Patrice, was it just one .mp3 file that couldn't play or do no mp3 files play at all? If not, maybe you are missing libmad.
Also, it shouldn't crash even if the library is missing. Any way you can run it through gdb and see where it did crash?
On Apr 29, 2011, at 10:07 AM, august wrote:
I've attached the dll if someone (matteo?) wants to try
Wow great! Of course I will try it and even stress it a little bit :)
yes, please stress it extensively.
Patrice, was it just one .mp3 file that couldn't play or do no mp3 files play at all? If not, maybe you are missing libmad.
Also, it shouldn't crash even if the library is missing. Any way you can run it through gdb and see where it did crash?
The Mac OS X version includes a lot of libraries to support all of the
codecs. readanysf~ will work without all of them, it just won't be
able to read the codecs that are missing. Here's the Mac OS X list:
libFLAC.8.dylib liba52.0.dylib libamrnb.0.dylib libavcodec.51.dylib libavformat.52.dylib libavutil.49.dylib libcdio.7.dylib libdca.0.dylib libdvdread.3.dylib libfaac.0.dylib libfaad.0.dylib libgavl.1.dylib libgmerlin_avdec.1.dylib libiconv.2.dylib libintl.3.dylib libjpeg.62.dylib libmad.0.dylib libmp3lame.0.dylib libmpcdec.5.dylib libogg.0.dylib liboil-0.3.0.dylib libopenjpeg.2.dylib libpng12.0.dylib libpostproc.51.dylib libschroedinger-1.0.0.dylib libspeex.1.dylib libswscale.0.dylib libtheora.0.dylib libtiff.3.dylib libvorbis.0.dylib libvorbisenc.2.dylib libx264.57.dylib libxvidcore.4.dylib
I hate it when they say, "He gave his life for his country." Nobody
gives their life for anything. We steal the lives of these kids. -
Admiral Gene LeRocque
----- "august" august@alien.mur.at a écrit :
I've attached the dll if someone (matteo?) wants to try
Wow great! Of course I will try it and even stress it a little bit
:)
yes, please stress it extensively.
Patrice, was it just one .mp3 file that couldn't play or do no mp3 files play at all? If not, maybe you are missing libmad.
Also, it shouldn't crash even if the library is missing. Any way you can run it through gdb and see where it did crash?
any mp3 crashes
here is the message I get when it crashes:
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 7728.0x154c] 0x039760f3 in libiconv () from c:\MinGW\bin\libiconv-2.dll (gdb) BFD: C:\Windows\SysWOW64\AUDIOKSE.dll: Warning: Ignoring section flag IMAGE_SCN_MEM_NOT_PAGE
do you want an archive containing all needed DLL's?
I couldn't get a linker option that would ignore missing ones
Patrice Colet
any mp3 crashes
here is the message I get when it crashes:
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 7728.0x154c] 0x039760f3 in libiconv () from c:\MinGW\bin\libiconv-2.dll (gdb) BFD: C:\Windows\SysWOW64\AUDIOKSE.dll: Warning: Ignoring section flag IMAGE_SCN_MEM_NOT_PAGE
hmm. what does libiconv do?
do you want an archive containing all needed DLL's?
yes, please.
I couldn't get a linker option that would ignore missing ones
this will be the difficult part, I imagine....to fully understand how mingw and windows development works. And, then to package all the dll's in a usable format.
On Apr 29, 2011, at 11:12 AM, Patrice Colet wrote:
----- "august" august@alien.mur.at a écrit :
I've attached the dll if someone (matteo?) wants to try
Wow great! Of course I will try it and even stress it a little bit
:)
yes, please stress it extensively.
Patrice, was it just one .mp3 file that couldn't play or do no mp3 files play at all? If not, maybe you are missing libmad.
Also, it shouldn't crash even if the library is missing. Any way you can run it through gdb and see where it did crash?
any mp3 crashes
here is the message I get when it crashes:
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 7728.0x154c] 0x039760f3 in libiconv () from c:\MinGW\bin\libiconv-2.dll (gdb) BFD: C:\Windows\SysWOW64\AUDIOKSE.dll: Warning: Ignoring
section flag IMAGE_SCN_MEM_NOT_PAGEdo you want an archive containing all needed DLL's?
I couldn't get a linker option that would ignore missing ones
Patrice Colet
Sounds like SetDllDirectory() is the function needed here, it works
starting with XP SP1:
http://msdn.microsoft.com/en-us/library/ms686203(v=vs.85).aspx
This thing about DLL search order is useful too: http://msdn.microsoft.com/en-us/library/ms682586(v=vs.85).aspx
.hc
News is what people want to keep hidden and everything else is
publicity. - Bill Moyers
-
august -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
matteo sisti sette -
Patrice Colet -
yvan volochine