Sorry I repost that on pd list, I've posted that on the dev list 3h ago but it seems stuck somewhere and I need a quick solution on that if possible...
Thanks in advance, Best,
n
-------- Message original -------- Sujet: libmp3lame.0 not the good version embedded in pd-extended 0.43.4 / osx intel Date : Wed, 13 Feb 2013 13:04:27 +0100 De : Nicolas Montgermont nicolas_montgermont@yahoo.fr Pour : pd-dev@iem.at
Hello dev and Hans,
It seems to me that the version of libmp3lame embedded in pd-extended 0.43.4 is not the good one. For example if I try to use unauthorized/mp3amp~ it crashes, but if I replace the library in the Pd-extended.app/Contents/lib folder by the one I have with Fink it works. Here are the two files, Pd-extended-0.43.4 stable on puredata.info Mac OS X intel 10.6.8 Best,
n
I've never used it, mp3amp~ has always crashed for me. Try readanysf~. If you know a way to make it stop crashing, I'm happy to try to incorporate that in Pd-extended nightly builds.
.hc
On 02/13/2013 09:55 AM, Nicolas Montgermont wrote:
Sorry I repost that on pd list, I've posted that on the dev list 3h ago but it seems stuck somewhere and I need a quick solution on that if possible...
Thanks in advance, Best,
n
-------- Message original -------- Sujet: libmp3lame.0 not the good version embedded in pd-extended 0.43.4 / osx intel Date : Wed, 13 Feb 2013 13:04:27 +0100 De : Nicolas Montgermont nicolas_montgermont@yahoo.fr Pour : pd-dev@iem.at
Hello dev and Hans,
It seems to me that the version of libmp3lame embedded in pd-extended 0.43.4 is not the good one. For example if I try to use unauthorized/mp3amp~ it crashes, but if I replace the library in the Pd-extended.app/Contents/lib folder by the one I have with Fink it works. Here are the two files, Pd-extended-0.43.4 stable on puredata.info Mac OS X intel 10.6.8 Best,
n
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I know I may be one of the latest users of mp3amp but unfortunately I can't use reandanysf~ for that project... What I'm saying is there is a difference between the libmp3lame embedded in the release of pd-extended and the libmp3lame in fink, and I think this is making mp3amp crashing.
Two examples: here, mp3amp crash in pd-extended 0.43-4 but
- If I use the unauthorized lib contained in the "artefact" build on
jenkins and put it in ~/Library/Pd, it ask me for libmp3lame in /sw/lib/, then if I download the lib with fink, it doesn"t crash anymore.
- or if I overwrite the libmp3lame contained inside the pd-extended
release with the one in fink, it doesn't crash neither.
So what I'm pointing is there may be an error on the libmp3lame file that is embedded with pd-extended. But I don't know the embedding process, so I can't describe more.
I have a solution for myself, but I am searching for a long time universal solution, and I think Pd-extended is a good option.
I hope this is clear? Thanks for your help. Best, n
ps: sorry if this mail come twice, I have mail software trouble.
Le 13/02/13 22:43, Hans-Christoph Steiner a écrit :
I've never used it, mp3amp~ has always crashed for me. Try readanysf~. If you know a way to make it stop crashing, I'm happy to try to incorporate that in Pd-extended nightly builds.
.hc
On 02/13/2013 09:55 AM, Nicolas Montgermont wrote:
Sorry I repost that on pd list, I've posted that on the dev list 3h ago but it seems stuck somewhere and I need a quick solution on that if possible...
Thanks in advance, Best,
n
-------- Message original -------- Sujet: libmp3lame.0 not the good version embedded in pd-extended 0.43.4 / osx intel Date : Wed, 13 Feb 2013 13:04:27 +0100 De : Nicolas Montgermont nicolas_montgermont@yahoo.fr Pour : pd-dev@iem.at
Hello dev and Hans,
It seems to me that the version of libmp3lame embedded in pd-extended 0.43.4 is not the good one. For example if I try to use unauthorized/mp3amp~ it crashes, but if I replace the library in the Pd-extended.app/Contents/lib folder by the one I have with Fink it works. Here are the two files, Pd-extended-0.43.4 stable on puredata.info Mac OS X intel 10.6.8 Best,
n
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
The first thing I would check is what library the external expects to find. run "dyldinfo" on your mp3amp~.pd_darwin file (it would be "ldd" in linux)
That will tell you what libraries it expects to see and if libmp3lame isn't in a typical system location or in the library search path, it says "not found"
Do the libraries have different names/versions or the is it the same?
On Wed, Feb 13, 2013 at 6:43 PM, Nicolas Montgermont < nicolas_montgermont@yahoo.fr> wrote:
I know I may be one of the latest users of mp3amp but unfortunately I can't use reandanysf~ for that project... What I'm saying is there is a difference between the libmp3lame embedded in the release of pd-extended and the libmp3lame in fink, and I think this is making mp3amp crashing.
Two examples: here, mp3amp crash in pd-extended 0.43-4 but
- If I use the unauthorized lib contained in the "artefact" build on
jenkins and put it in ~/Library/Pd, it ask me for libmp3lame in /sw/lib/, then if I download the lib with fink, it doesn"t crash anymore.
- or if I overwrite the libmp3lame contained inside the pd-extended
release with the one in fink, it doesn't crash neither.
So what I'm pointing is there may be an error on the libmp3lame file that is embedded with pd-extended. But I don't know the embedding process, so I can't describe more.
I have a solution for myself, but I am searching for a long time universal solution, and I think Pd-extended is a good option.
I hope this is clear? Thanks for your help. Best, n
ps: sorry if this mail come twice, I have mail software trouble.
Le 13/02/13 22:43, Hans-Christoph Steiner a écrit :
I've never used it, mp3amp~ has always crashed for me. Try readanysf~.
If you know a way to make it stop crashing, I'm happy to try to incorporate that in Pd-extended nightly builds.
.hc
On 02/13/2013 09:55 AM, Nicolas Montgermont wrote:
Sorry I repost that on pd list, I've posted that on the dev list 3h ago but it seems stuck somewhere and I need a quick solution on that if possible...
Thanks in advance, Best,
n
-------- Message original -------- Sujet: libmp3lame.0 not the good version embedded in pd-extended 0.43.4 / osx intel Date : Wed, 13 Feb 2013 13:04:27 +0100 De : Nicolas Montgermont nicolas_montgermont@yahoo.fr Pour : pd-dev@iem.at
Hello dev and Hans,
It seems to me that the version of libmp3lame embedded in pd-extended 0.43.4 is not the good one. For example if I try to use unauthorized/mp3amp~ it crashes, but if I replace the library in the Pd-extended.app/Contents/lib folder by the one I have with Fink it works. Here are the two files, Pd-extended-0.43.4 stable on puredata.info Mac OS X intel 10.6.8 Best,
n
______________________________**_________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/** listinfo/pd-list http://lists.puredata.info/listinfo/pd-list
______________________________**_________________
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/** listinfo/pd-list http://lists.puredata.info/listinfo/pd-list
______________________________**_________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/** listinfo/pd-list http://lists.puredata.info/listinfo/pd-list
Le 14/02/13 02:28, Charles Z Henry a écrit :
The first thing I would check is what library the external expects to find. run "dyldinfo" on your mp3amp~.pd_darwin file (it would be "ldd" in linux)
I don't really understand the dyldinfo option, but I've tested with otool on the two versions of mp3amp~.pd_darwin. Loading path are as expected :mp3amp with pd-extended search for the one in pd-extended and mp3amp in template-libraries build search for no one (i think it must be using standard path search). But once again both versions of mp3amp works if they load the good libmp3lame.
That will tell you what libraries it expects to see and if libmp3lame isn't in a typical system location or in the library search path, it says "not found"
it is embedded in Pd-extended in Contents/lib
Do the libraries have different names/versions or the is it the same?
pd-extended's is : libmp3lame.0.dylib fink's is : libmp3lame.0.0.0.dylib with a symbolic link they look the same with otool -L but they have different sizes...
n
On 02/14/2013 06:26 AM, Nicolas Montgermont wrote:
Le 14/02/13 02:28, Charles Z Henry a écrit :
The first thing I would check is what library the external expects to find. run "dyldinfo" on your mp3amp~.pd_darwin file (it would be "ldd" in linux)
I don't really understand the dyldinfo option, but I've tested with otool on the two versions of mp3amp~.pd_darwin. Loading path are as expected :mp3amp with pd-extended search for the one in pd-extended and mp3amp in template-libraries build search for no one (i think it must be using standard path search). But once again both versions of mp3amp works if they load the good libmp3lame.
That will tell you what libraries it expects to see and if libmp3lame isn't in a typical system location or in the library search path, it says "not found"
it is embedded in Pd-extended in Contents/lib
Do the libraries have different names/versions or the is it the same?
pd-extended's is : libmp3lame.0.dylib fink's is : libmp3lame.0.0.0.dylib with a symbolic link they look the same with otool -L but they have different sizes...
n
Can you tell me the exact steps that you take in order to swap in your build of libmp3lame into Pd-extended to make it work?
.hc
Le 14/02/13 19:09, Hans-Christoph Steiner a écrit :
Can you tell me the exact steps that you take in order to swap in your build of libmp3lame into Pd-extended to make it work?
.hc
Sure I just replace the lib:
sudo rm /Applications/Pd-extended.app/Contents/lib/libmp3lame.0.dylib sudo cp /sw/lib/libmp3lame.0.0.0.dylib /Applications/Pd-extended.app/Contents/lib/ sudo ln -s /Applications/Pd-extended.app/Contents/lib/libmp3lame.0.0.0.dylib /Applications/Pd-extended.app/Contents/lib/libmp3lame.0.dylib
n
On 02/15/2013 05:22 PM, Nicolas Montgermont wrote:
Le 14/02/13 19:09, Hans-Christoph Steiner a écrit :
Can you tell me the exact steps that you take in order to swap in your build of libmp3lame into Pd-extended to make it work?
.hc
Sure I just replace the lib:
since the PdX installer essentially does the same, i guess it is more interesting to know which version of libmp3lame you are using (as compared to PdX)
there is certainly an easy way to get the package version of a library, e.g. $ fink show libmp3lame
gmdsr IOhannes
On 02/15/2013 11:38 AM, IOhannes zmölnig wrote:
On 02/15/2013 05:22 PM, Nicolas Montgermont wrote:
Le 14/02/13 19:09, Hans-Christoph Steiner a écrit :
Can you tell me the exact steps that you take in order to swap in your build of libmp3lame into Pd-extended to make it work?
.hc
Sure I just replace the lib:
since the PdX installer essentially does the same, i guess it is more interesting to know which version of libmp3lame you are using (as compared to PdX)
there is certainly an easy way to get the package version of a library, e.g. $ fink show libmp3lame
Indeed. Also, is this is 32-bit i386 build or the 64-bit x86_64 build of Pd-extended?
.hc
Le 15/02/13 18:03, Hans-Christoph Steiner a écrit :
since the PdX installer essentially does the same, i guess it is more interesting to know which version of libmp3lame you are using (as compared to PdX)
there is certainly an easy way to get the package version of a library, e.g. $ fink show libmp3lame
fink describe lame-shlibs shows it is version 3.98.4-1
Indeed. Also, is this is 32-bit i386 build or the 64-bit x86_64 build of Pd-extended?
32 bits i386.
n
On 02/15/2013 01:02 PM, Nicolas Montgermont wrote:
Le 15/02/13 18:03, Hans-Christoph Steiner a écrit :
since the PdX installer essentially does the same, i guess it is more interesting to know which version of libmp3lame you are using (as compared to PdX)
there is certainly an easy way to get the package version of a library, e.g. $ fink show libmp3lame
fink describe lame-shlibs shows it is version 3.98.4-1
Indeed. Also, is this is 32-bit i386 build or the 64-bit x86_64 build of Pd-extended?
32 bits i386.
The Mac OS X build servers have 3.99.5-2 installed on them and Pd-extended 0.43.4 shipped with 3.99.5. Ubuntu as of 12.10/quantal has 3.99.5 also. I'm on 12.04/precise, which has 3.99.3 and mp3amp~ doesn't crash on load but I also can't get it to playback a stream.
I still don't really know what the cause of the issue is. If the library version is the issue, then sounds like mp3amp~ needs to be fixed to work with 3.99.5 since all the distros are moving to that.
I just rebuilt the lame package from scratch on the Mac OS X 10.5 i386 32-bit machine. Could you test tomorrow's nightly build and see if it still has the problem?
.hc
Le 15/02/13 21:14, Hans-Christoph Steiner a écrit :
On 02/15/2013 01:02 PM, Nicolas Montgermont wrote:
Le 15/02/13 18:03, Hans-Christoph Steiner a écrit :
since the PdX installer essentially does the same, i guess it is more interesting to know which version of libmp3lame you are using (as compared to PdX)
there is certainly an easy way to get the package version of a library, e.g. $ fink show libmp3lame
fink describe lame-shlibs shows it is version 3.98.4-1
Indeed. Also, is this is 32-bit i386 build or the 64-bit x86_64 build of Pd-extended?
32 bits i386.
The Mac OS X build servers have 3.99.5-2 installed on them and Pd-extended 0.43.4 shipped with 3.99.5. Ubuntu as of 12.10/quantal has 3.99.5 also. I'm on 12.04/precise, which has 3.99.3 and mp3amp~ doesn't crash on load but I also can't get it to playback a stream.
Yes it's not on the loading of the object but when a stream is played. From what i see in the svn, a problem may be that mp3amp compiles against local headers located in the unauthorized folder: mpg123.h, mpglib.h and interface.h maybe those headers are not compatible with 3.99 version, they are from lame 3.92
I still don't really know what the cause of the issue is. If the library version is the issue, then sounds like mp3amp~ needs to be fixed to work with 3.99.5 since all the distros are moving to that.
I tried to debug the problem a bit but can't manage to use gdb, it says me "no stack" when i try to backtrace.
I just rebuilt the lame package from scratch on the Mac OS X 10.5 i386 32-bit machine. Could you test tomorrow's nightly build and see if it still has the problem?
I didn't found any fresh 0.43-4 build so tried with the 0.44.0 build and it still have the problem. thx n
On 02/17/2013 06:34 AM, Nicolas Montgermont wrote:
Le 15/02/13 21:14, Hans-Christoph Steiner a écrit :
On 02/15/2013 01:02 PM, Nicolas Montgermont wrote:
Le 15/02/13 18:03, Hans-Christoph Steiner a écrit :
since the PdX installer essentially does the same, i guess it is more interesting to know which version of libmp3lame you are using (as compared to PdX)
there is certainly an easy way to get the package version of a library, e.g. $ fink show libmp3lame
fink describe lame-shlibs shows it is version 3.98.4-1
Indeed. Also, is this is 32-bit i386 build or the 64-bit x86_64 build of Pd-extended?
32 bits i386.
The Mac OS X build servers have 3.99.5-2 installed on them and Pd-extended 0.43.4 shipped with 3.99.5. Ubuntu as of 12.10/quantal has 3.99.5 also. I'm on 12.04/precise, which has 3.99.3 and mp3amp~ doesn't crash on load but I also can't get it to playback a stream.
Yes it's not on the loading of the object but when a stream is played. From what i see in the svn, a problem may be that mp3amp compiles against local headers located in the unauthorized folder: mpg123.h, mpglib.h and interface.h maybe those headers are not compatible with 3.99 version, they are from lame 3.92
Yeah, that sounds like a bad situation. Try building without those headers. I can't reproduce this problem. If you send me a patch that reproduces it, I'll try building without the headers myself.
.hc
I still don't really know what the cause of the issue is. If the library version is the issue, then sounds like mp3amp~ needs to be fixed to work with 3.99.5 since all the distros are moving to that.
I tried to debug the problem a bit but can't manage to use gdb, it says me "no stack" when i try to backtrace.
I just rebuilt the lame package from scratch on the Mac OS X 10.5 i386 32-bit machine. Could you test tomorrow's nightly build and see if it still has the problem?
I didn't found any fresh 0.43-4 build so tried with the 0.44.0 build and it still have the problem. thx n
-
Charles Z Henry -
Hans-Christoph Steiner -
IOhannes zmölnig -
Nicolas Montgermont