The compiler builds for the current system by default. You have to set the min deployment target when building.
Add this flag to you makefile: --mmacosx-version-min=10.6
The current version for Pd is 10.6 which is the first version that supported i386 (ie. Intel processors).
On Mar 19, 2018, at 12:00 PM, pd-dev-request@lists.iem.at wrote:
From: Miller Puckette <msp@ucsd.edu mailto:msp@ucsd.edu> To: Alex <x37v.alex@gmail.com mailto:x37v.alex@gmail.com> Cc: pd-dev <pd-dev@lists.iem.at mailto:pd-dev@lists.iem.at> Subject: Re: [PD-dev] Mac SDK version for externals Message-ID: <20180319015755.GY7620@elroy.localdomain mailto:20180319015755.GY7620@elroy.localdomain> Content-Type: text/plain; charset=us-ascii
This is a very interesting and useful question.
At the outset of PD I only worried about having it run on the "current" platforms: Redhat 5.2, Windows 95, and when it arrived, MacOS 10.2. Older platforms weren't important.
Since then I've tried to keep back compatibility to whatever those bleeding-edge OSes were, because I assume people can't always afford machine upgrades. But I haven't tried to extend Pd (Or "extra" objects) backward past the original dates.
At the moment I can only compile back to OSX 10.5 (PPC) and Windows XP; I don't have real or virtual machines that go back further.
So my suggestion would be: make it work on today's OSes, and try to keep it alive on them, but don't worry too hard about older ones. I don't think I'm ever going to be tempted to compile Pd for Windows 3.1.
cheers Miller
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Also, if you're targeting C++11, I think you'll have to use a min of at least 10.7 (from https://stackoverflow.com/questions/7482026/can-i-use-the-latest-features-of... https://stackoverflow.com/questions/7482026/can-i-use-the-latest-features-of-c11-in-xcode-4-or-osx-lion).
One thing we've noticed is that Pd builds on my machine running 10.13 don't seems to work on 10.6-10.7 systems, so the deployment target is really a suggestion at best. You'll have to do some testing but it's hard to hit *everyone* and honestly the vast majority of users fall within the newest to maybe 3 versions before anyway (ie. 10.10 - 10.13 now).
For plain C/C++, you can have a relatively old deployment target. It's really more important for macOS app development using the Apple frameworks ie. stuff like the changes from QT to AVFoundation, etc.
On Mar 19, 2018, at 10:07 PM, Dan Wilcox danomatika@gmail.com wrote:
The compiler builds for the current system by default. You have to set the min deployment target when building.
Add this flag to you makefile: --mmacosx-version-min=10.6
The current version for Pd is 10.6 which is the first version that supported i386 (ie. Intel processors).
On Mar 19, 2018, at 12:00 PM, pd-dev-request@lists.iem.at mailto:pd-dev-request@lists.iem.at wrote:
From: Miller Puckette <msp@ucsd.edu mailto:msp@ucsd.edu> To: Alex <x37v.alex@gmail.com mailto:x37v.alex@gmail.com> Cc: pd-dev <pd-dev@lists.iem.at mailto:pd-dev@lists.iem.at> Subject: Re: [PD-dev] Mac SDK version for externals Message-ID: <20180319015755.GY7620@elroy.localdomain mailto:20180319015755.GY7620@elroy.localdomain> Content-Type: text/plain; charset=us-ascii
This is a very interesting and useful question.
At the outset of PD I only worried about having it run on the "current" platforms: Redhat 5.2, Windows 95, and when it arrived, MacOS 10.2. Older platforms weren't important.
Since then I've tried to keep back compatibility to whatever those bleeding-edge OSes were, because I assume people can't always afford machine upgrades. But I haven't tried to extend Pd (Or "extra" objects) backward past the original dates.
At the moment I can only compile back to OSX 10.5 (PPC) and Windows XP; I don't have real or virtual machines that go back further.
So my suggestion would be: make it work on today's OSes, and try to keep it alive on them, but don't worry too hard about older ones. I don't think I'm ever going to be tempted to compile Pd for Windows 3.1.
cheers Miller
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
using my cmake setup in the jit_expr project I was able to build just now for 10.9 but no lower, going below 10.9 didn't allow it to find the std::shared_ptr maybe I can get lower somehow? Either way, this should be more useful for more people :)
Thanks for the info Dan!
On Mon, Mar 19, 2018 at 2:15 PM, Dan Wilcox danomatika@gmail.com wrote:
Also, if you're targeting C++11, I think you'll have to use a min of at least 10.7 (from https://stackoverflow.com/questions/7482026/can-i- use-the-latest-features-of-c11-in-xcode-4-or-osx-lion).
One thing we've noticed is that Pd builds on my machine running 10.13 don't seems to work on 10.6-10.7 systems, so the deployment target is really a suggestion at best. You'll have to do some testing but it's hard to hit *everyone* and honestly the vast majority of users fall within the newest to maybe 3 versions before anyway (ie. 10.10 - 10.13 now).
For plain C/C++, you can have a relatively old deployment target. It's really more important for macOS app development using the Apple frameworks ie. stuff like the changes from QT to AVFoundation, etc.
On Mar 19, 2018, at 10:07 PM, Dan Wilcox danomatika@gmail.com wrote:
The compiler builds for the current system by default. You have to set the min deployment target when building.
Add this flag to you makefile: --mmacosx-version-min=10.6
The current version for Pd is 10.6 which is the first version that supported i386 (ie. Intel processors).
On Mar 19, 2018, at 12:00 PM, pd-dev-request@lists.iem.at wrote:
From: Miller Puckette msp@ucsd.edu To: Alex x37v.alex@gmail.com Cc: pd-dev pd-dev@lists.iem.at Subject: Re: [PD-dev] Mac SDK version for externals Message-ID: 20180319015755.GY7620@elroy.localdomain Content-Type: text/plain; charset=us-ascii
This is a very interesting and useful question.
At the outset of PD I only worried about having it run on the "current" platforms: Redhat 5.2, Windows 95, and when it arrived, MacOS 10.2. Older platforms weren't important.
Since then I've tried to keep back compatibility to whatever those bleeding-edge OSes were, because I assume people can't always afford machine upgrades. But I haven't tried to extend Pd (Or "extra" objects) backward past the original dates.
At the moment I can only compile back to OSX 10.5 (PPC) and Windows XP; I don't have real or virtual machines that go back further.
So my suggestion would be: make it work on today's OSes, and try to keep it alive on them, but don't worry too hard about older ones. I don't think I'm ever going to be tempted to compile Pd for Windows 3.1.
cheers Miller
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com robotcowboy.com
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com robotcowboy.com
I believe the new feature C++11 namespace before it was finalized to std:: was something like tr1::. You could check the C++ version and set/typdef the namespace as required. Look in the OpenFrameworks ofConstants.h header.
On Mar 19, 2018, at 10:49 PM, Alex x37v.alex@gmail.com wrote:
using my cmake setup in the jit_expr project I was able to build just now for 10.9 but no lower, going below 10.9 didn't allow it to find the std::shared_ptr maybe I can get lower somehow? Either way, this should be more useful for more people :)
Thanks for the info Dan!
On Mon, Mar 19, 2018 at 2:15 PM, Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com> wrote: Also, if you're targeting C++11, I think you'll have to use a min of at least 10.7 (from https://stackoverflow.com/questions/7482026/can-i-use-the-latest-features-of... https://stackoverflow.com/questions/7482026/can-i-use-the-latest-features-of-c11-in-xcode-4-or-osx-lion).
One thing we've noticed is that Pd builds on my machine running 10.13 don't seems to work on 10.6-10.7 systems, so the deployment target is really a suggestion at best. You'll have to do some testing but it's hard to hit *everyone* and honestly the vast majority of users fall within the newest to maybe 3 versions before anyway (ie. 10.10 - 10.13 now).
For plain C/C++, you can have a relatively old deployment target. It's really more important for macOS app development using the Apple frameworks ie. stuff like the changes from QT to AVFoundation, etc.
On Mar 19, 2018, at 10:07 PM, Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com> wrote:
The compiler builds for the current system by default. You have to set the min deployment target when building.
Add this flag to you makefile: --mmacosx-version-min=10.6
The current version for Pd is 10.6 which is the first version that supported i386 (ie. Intel processors).
On Mar 19, 2018, at 12:00 PM, pd-dev-request@lists.iem.at mailto:pd-dev-request@lists.iem.at wrote:
From: Miller Puckette <msp@ucsd.edu mailto:msp@ucsd.edu> To: Alex <x37v.alex@gmail.com mailto:x37v.alex@gmail.com> Cc: pd-dev <pd-dev@lists.iem.at mailto:pd-dev@lists.iem.at> Subject: Re: [PD-dev] Mac SDK version for externals Message-ID: <20180319015755.GY7620@elroy.localdomain mailto:20180319015755.GY7620@elroy.localdomain> Content-Type: text/plain; charset=us-ascii
This is a very interesting and useful question.
At the outset of PD I only worried about having it run on the "current" platforms: Redhat 5.2, Windows 95, and when it arrived, MacOS 10.2. Older platforms weren't important.
Since then I've tried to keep back compatibility to whatever those bleeding-edge OSes were, because I assume people can't always afford machine upgrades. But I haven't tried to extend Pd (Or "extra" objects) backward past the original dates.
At the moment I can only compile back to OSX 10.5 (PPC) and Windows XP; I don't have real or virtual machines that go back further.
So my suggestion would be: make it work on today's OSes, and try to keep it alive on them, but don't worry too hard about older ones. I don't think I'm ever going to be tempted to compile Pd for Windows 3.1.
cheers Miller
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
ahh yes, i'm using tr1 now in a branch, have to get make_shared going.. moving along!
On Mon, Mar 19, 2018 at 2:57 PM, Dan Wilcox danomatika@gmail.com wrote:
I believe the new feature C++11 namespace before it was finalized to std:: was something like tr1::. You could check the C++ version and set/typdef the namespace as required. Look in the OpenFrameworks ofConstants.h header.
On Mar 19, 2018, at 10:49 PM, Alex x37v.alex@gmail.com wrote:
using my cmake setup in the jit_expr project I was able to build just now for 10.9 but no lower, going below 10.9 didn't allow it to find the std::shared_ptr maybe I can get lower somehow? Either way, this should be more useful for more people :)
Thanks for the info Dan!
On Mon, Mar 19, 2018 at 2:15 PM, Dan Wilcox danomatika@gmail.com wrote:
Also, if you're targeting C++11, I think you'll have to use a min of at least 10.7 (from https://stackoverflow.com/questions/7482026/can-i-use- the-latest-features-of-c11-in-xcode-4-or-osx-lion).
One thing we've noticed is that Pd builds on my machine running 10.13 don't seems to work on 10.6-10.7 systems, so the deployment target is really a suggestion at best. You'll have to do some testing but it's hard to hit *everyone* and honestly the vast majority of users fall within the newest to maybe 3 versions before anyway (ie. 10.10 - 10.13 now).
For plain C/C++, you can have a relatively old deployment target. It's really more important for macOS app development using the Apple frameworks ie. stuff like the changes from QT to AVFoundation, etc.
On Mar 19, 2018, at 10:07 PM, Dan Wilcox danomatika@gmail.com wrote:
The compiler builds for the current system by default. You have to set the min deployment target when building.
Add this flag to you makefile: --mmacosx-version-min=10.6
The current version for Pd is 10.6 which is the first version that supported i386 (ie. Intel processors).
On Mar 19, 2018, at 12:00 PM, pd-dev-request@lists.iem.at wrote:
From: Miller Puckette msp@ucsd.edu To: Alex x37v.alex@gmail.com Cc: pd-dev pd-dev@lists.iem.at Subject: Re: [PD-dev] Mac SDK version for externals Message-ID: 20180319015755.GY7620@elroy.localdomain Content-Type: text/plain; charset=us-ascii
This is a very interesting and useful question.
At the outset of PD I only worried about having it run on the "current" platforms: Redhat 5.2, Windows 95, and when it arrived, MacOS 10.2. Older platforms weren't important.
Since then I've tried to keep back compatibility to whatever those bleeding-edge OSes were, because I assume people can't always afford machine upgrades. But I haven't tried to extend Pd (Or "extra" objects) backward past the original dates.
At the moment I can only compile back to OSX 10.5 (PPC) and Windows XP; I don't have real or virtual machines that go back further.
So my suggestion would be: make it work on today's OSes, and try to keep it alive on them, but don't worry too hard about older ones. I don't think I'm ever going to be tempted to compile Pd for Windows 3.1.
cheers Miller
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com robotcowboy.com
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com robotcowboy.com
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com robotcowboy.com
Hi Alex,
If you really want to compile for < 10.9, you can check at compile time if the function is available (using the c++ version __cplusplus or the deployment target) and if not you can fall back to the classic new() approach with something like **pseudo code**: template<class T> shared_ptr<T> std::make_shared(args...) { return shared_ptr<T>(new T(args...)); }
Even this approach seems equivalent, make_shared is a bit different see this http://en.cppreference.com/w/cpp/memory/shared_ptr/make_shared so if your dependency want it I guess there is a reason and you should just assume that the minimum target is 10.9.
Moreover you won't be able to use such kind of tricks for ever and if one day you use a dependency with c++14 features you will have similar/harder problems to compile for 10.9 or inferior versions. I used these kind of trick many times, and now I think it doesn't worth the price (but it's my opinion).
And think that 10.9 is already more than 4 years old and thanks to Apple, the machines that use this version will die in 1 or 2 years due to planned obsolescence... best ever rhetoric ;)
Cheers,
Pierre
2018-03-19 23:00 GMT+01:00 Alex x37v.alex@gmail.com:
ahh yes, i'm using tr1 now in a branch, have to get make_shared going.. moving along!
On Mon, Mar 19, 2018 at 2:57 PM, Dan Wilcox danomatika@gmail.com wrote:
I believe the new feature C++11 namespace before it was finalized to std:: was something like tr1::. You could check the C++ version and set/typdef the namespace as required. Look in the OpenFrameworks ofConstants.h header.
On Mar 19, 2018, at 10:49 PM, Alex x37v.alex@gmail.com wrote:
using my cmake setup in the jit_expr project I was able to build just now for 10.9 but no lower, going below 10.9 didn't allow it to find the std::shared_ptr maybe I can get lower somehow? Either way, this should be more useful for more people :)
Thanks for the info Dan!
On Mon, Mar 19, 2018 at 2:15 PM, Dan Wilcox danomatika@gmail.com wrote:
Also, if you're targeting C++11, I think you'll have to use a min of at least 10.7 (from https://stackoverflow.com/questions/7482026/can-i-use- the-latest-features-of-c11-in-xcode-4-or-osx-lion).
One thing we've noticed is that Pd builds on my machine running 10.13 don't seems to work on 10.6-10.7 systems, so the deployment target is really a suggestion at best. You'll have to do some testing but it's hard to hit *everyone* and honestly the vast majority of users fall within the newest to maybe 3 versions before anyway (ie. 10.10 - 10.13 now).
For plain C/C++, you can have a relatively old deployment target. It's really more important for macOS app development using the Apple frameworks ie. stuff like the changes from QT to AVFoundation, etc.
On Mar 19, 2018, at 10:07 PM, Dan Wilcox danomatika@gmail.com wrote:
The compiler builds for the current system by default. You have to set the min deployment target when building.
Add this flag to you makefile: --mmacosx-version-min=10.6
The current version for Pd is 10.6 which is the first version that supported i386 (ie. Intel processors).
On Mar 19, 2018, at 12:00 PM, pd-dev-request@lists.iem.at wrote:
From: Miller Puckette msp@ucsd.edu To: Alex x37v.alex@gmail.com Cc: pd-dev pd-dev@lists.iem.at Subject: Re: [PD-dev] Mac SDK version for externals Message-ID: 20180319015755.GY7620@elroy.localdomain Content-Type: text/plain; charset=us-ascii
This is a very interesting and useful question.
At the outset of PD I only worried about having it run on the "current" platforms: Redhat 5.2, Windows 95, and when it arrived, MacOS 10.2. Older platforms weren't important.
Since then I've tried to keep back compatibility to whatever those bleeding-edge OSes were, because I assume people can't always afford machine upgrades. But I haven't tried to extend Pd (Or "extra" objects) backward past the original dates.
At the moment I can only compile back to OSX 10.5 (PPC) and Windows XP; I don't have real or virtual machines that go back further.
So my suggestion would be: make it work on today's OSes, and try to keep it alive on them, but don't worry too hard about older ones. I don't think I'm ever going to be tempted to compile Pd for Windows 3.1.
cheers Miller
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com robotcowboy.com
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com robotcowboy.com
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com robotcowboy.com
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Hey Pierre,
Yeah, that was my plan, though in the mean time someone from the list has provided a version built and working on 10.10. I built one on my 10.13 machine targeted for min sdk of 10.9 but built against the 10.13 sdk, not sure how that all works. It built and ran just fine on my device but still failed to resolve some symbols on a 10.10 machine. I'll see about linking against the earlier SDK once I get some time.
Thanks for the advice!
-Alex
On Tue, Mar 20, 2018 at 3:14 AM, Pierre Guillot guillotpierre6@gmail.com wrote:
Hi Alex,
If you really want to compile for < 10.9, you can check at compile time if the function is available (using the c++ version __cplusplus or the deployment target) and if not you can fall back to the classic new() approach with something like **pseudo code**: template<class T> shared_ptr<T> std::make_shared(args...) { return shared_ptr<T>(new T(args...)); }
Even this approach seems equivalent, make_shared is a bit different see this http://en.cppreference.com/w/cpp/memory/shared_ptr/make_shared so if your dependency want it I guess there is a reason and you should just assume that the minimum target is 10.9.
Moreover you won't be able to use such kind of tricks for ever and if one day you use a dependency with c++14 features you will have similar/harder problems to compile for 10.9 or inferior versions. I used these kind of trick many times, and now I think it doesn't worth the price (but it's my opinion).
And think that 10.9 is already more than 4 years old and thanks to Apple, the machines that use this version will die in 1 or 2 years due to planned obsolescence... best ever rhetoric ;)
Cheers,
Pierre
2018-03-19 23:00 GMT+01:00 Alex x37v.alex@gmail.com:
ahh yes, i'm using tr1 now in a branch, have to get make_shared going.. moving along!
On Mon, Mar 19, 2018 at 2:57 PM, Dan Wilcox danomatika@gmail.com wrote:
I believe the new feature C++11 namespace before it was finalized to std:: was something like tr1::. You could check the C++ version and set/typdef the namespace as required. Look in the OpenFrameworks ofConstants.h header.
On Mar 19, 2018, at 10:49 PM, Alex x37v.alex@gmail.com wrote:
using my cmake setup in the jit_expr project I was able to build just now for 10.9 but no lower, going below 10.9 didn't allow it to find the std::shared_ptr maybe I can get lower somehow? Either way, this should be more useful for more people :)
Thanks for the info Dan!
On Mon, Mar 19, 2018 at 2:15 PM, Dan Wilcox danomatika@gmail.com wrote:
Also, if you're targeting C++11, I think you'll have to use a min of at least 10.7 (from https://stackoverflow.com/questions/7482026/can-i-use- the-latest-features-of-c11-in-xcode-4-or-osx-lion).
One thing we've noticed is that Pd builds on my machine running 10.13 don't seems to work on 10.6-10.7 systems, so the deployment target is really a suggestion at best. You'll have to do some testing but it's hard to hit *everyone* and honestly the vast majority of users fall within the newest to maybe 3 versions before anyway (ie. 10.10 - 10.13 now).
For plain C/C++, you can have a relatively old deployment target. It's really more important for macOS app development using the Apple frameworks ie. stuff like the changes from QT to AVFoundation, etc.
On Mar 19, 2018, at 10:07 PM, Dan Wilcox danomatika@gmail.com wrote:
The compiler builds for the current system by default. You have to set the min deployment target when building.
Add this flag to you makefile: --mmacosx-version-min=10.6
The current version for Pd is 10.6 which is the first version that supported i386 (ie. Intel processors).
On Mar 19, 2018, at 12:00 PM, pd-dev-request@lists.iem.at wrote:
From: Miller Puckette msp@ucsd.edu To: Alex x37v.alex@gmail.com Cc: pd-dev pd-dev@lists.iem.at Subject: Re: [PD-dev] Mac SDK version for externals Message-ID: 20180319015755.GY7620@elroy.localdomain Content-Type: text/plain; charset=us-ascii
This is a very interesting and useful question.
At the outset of PD I only worried about having it run on the "current" platforms: Redhat 5.2, Windows 95, and when it arrived, MacOS 10.2. Older platforms weren't important.
Since then I've tried to keep back compatibility to whatever those bleeding-edge OSes were, because I assume people can't always afford machine upgrades. But I haven't tried to extend Pd (Or "extra" objects) backward past the original dates.
At the moment I can only compile back to OSX 10.5 (PPC) and Windows XP; I don't have real or virtual machines that go back further.
So my suggestion would be: make it work on today's OSes, and try to keep it alive on them, but don't worry too hard about older ones. I don't think I'm ever going to be tempted to compile Pd for Windows 3.1.
cheers Miller
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com robotcowboy.com
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com robotcowboy.com
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com robotcowboy.com
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Oliver and I did some tests on compiling Pd for windows.
We found that the current master branch can't load Gem.
We can load it with Miller's build or with self builds from "pure-data-mingw-autotools2" branch from January 9, 2018.
We are sure this is not an "msvcr71.dll" issue or a "-lib" issue.
We get:
C:\Users\Lucarda\Documents\Pd\externals\gem\gem.dll: couldn't load
What could have changed in Pd code since 0.48.1 release?
PS: I can load other -lib s with no problem (cyclone, iemlib, ofelia)
Mensaje telepatico asistido por maquinas.
On 2018-03-20 05:48, Lucas Cordiviola wrote:
Oliver and I did some tests on compiling Pd for windows.
We found that the current master branch can't load Gem.
We can load it with Miller's build or with self builds from "pure-data-mingw-autotools2" branch from January 9, 2018.
We are sure this is not an "msvcr71.dll" issue or a "-lib" issue.
We get:
C:\Users\Lucarda\Documents\Pd\externals\gem\gem.dll: couldn't load
ouch. good catch. do you have the failing binaries available?
since i'm not a w32 guy, any help is much appreciated.
fgmasdr IOhannes
Here --> http://lucarda.com.ar/x/Gem-not-loading-w32.zip
--
Mensaje telepatico asistido por maquinas.
On 3/20/2018 5:50 AM, IOhannes m zmoelnig wrote:
On 2018-03-20 05:48, Lucas Cordiviola wrote:
Oliver and I did some tests on compiling Pd for windows.
We found that the current master branch can't load Gem.
We can load it with Miller's build or with self builds from "pure-data-mingw-autotools2" branch from January 9, 2018.
We are sure this is not an "msvcr71.dll" issue or a "-lib" issue.
We get:
C:\Users\Lucarda\Documents\Pd\externals\gem\gem.dll: couldn't load
ouch. good catch. do you have the failing binaries available?
since i'm not a w32 guy, any help is much appreciated.
fgmasdr IOhannes
_______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.atmailto:Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
On 3/20/2018 5:50 AM, IOhannes m zmoelnig wrote:
since i'm not a w32 guy, any help is much appreciated.
If you want to set a branch for testing I will compile and test ASAP.
May be Oliver is also willing to test?
I'm not sure if Oliver is here in the dev-list but it is included in this message.
:)
Mensaje telepatico asistido por maquinas.
I did some tests and research:
This has changed since 0.48.1:
https://github.com/pure-data/pure-data/commit/fee700b3b35caddab2ab4a48a726a6...
For some unknown reason Gem.dll fails to load but other old dlls loads fine.
So I tried to compile Gem to see what happened. It turned that my compiled Gem.dll loads fine on my compiled >0.48.1 Pd.
To compile gem I use the current git master branch and did on Msys2:
./autogen.sh ./configure --with-pd=C:/pd-sources/32 --prefix=E:/win10onexthd/gem-test/Gem-master/out-luc --without-ftgl
I get:
*****************************************************************
Result: Target : Gem.dll Objects : default window : gemw32window
Configuration: Compiler : g++ CXXFLAGS : -g -O2 -freg-struct-return -mms-bitfields -O3 -falign-loops -falign-functions -falign-jumps -funroll-loops -ffast-math -mmmx : DEFINES :
LIBS : -lgdi32 -lws2_32 -lmsvcrt -lz -lm : -lvfw32 LDFLAGS : :
Install path : E:/win10onexthd/gem-test/Gem-master/out-luc
RTE (Pure Data): external-extension : dll CFLAGS : -DPD -IC:/pd-sources/32/src LIBS : -LC:/pd-sources/32/bin -Xlinker -l:pd.dll
used optional libraries:
font-rendering : default font :
image-support use ImageMagick : no use QuickTime : no use AVFoundation : no use TIFF : no use JPEG : no moviefile-support use PLUGINS : yes use mpeg : no use mpeg-3 : no use QuickTime : no use AVFoundation : use aviplay : no use gmerlin : no capture-support use PLUGINS : yes use v4l : no use v4l2 : no use ieee1394 : no use DV : no use Unicap : yes use Video-for-WinDOS : yes use QuickTime : no use AVFoundation : no
*************************************************************
It took 2hs to compile and Gem.dll is 81.9 MB
I copied "libwinpthread-1.dll" & "libstdc++-6.dll" from the compiler to the Gem folder.
Gem loads but can't create the [gemwin].
--
Mensaje telepatico asistido por maquinas.
On 3/20/2018 5:50 AM, IOhannes m zmoelnig wrote:
On 2018-03-20 05:48, Lucas Cordiviola wrote:
Oliver and I did some tests on compiling Pd for windows.
We found that the current master branch can't load Gem.
We can load it with Miller's build or with self builds from "pure-data-mingw-autotools2" branch from January 9, 2018.
We are sure this is not an "msvcr71.dll" issue or a "-lib" issue.
We get:
C:\Users\Lucarda\Documents\Pd\externals\gem\gem.dll: couldn't load
ouch. good catch. do you have the failing binaries available?
since i'm not a w32 guy, any help is much appreciated.
fgmasdr IOhannes
_______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.atmailto:Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
did you add GEM to your path? in recent GEM, [gemwin] is an abstraction.
Gesendet: Montag, 26. März 2018 um 00:55 Uhr Von: "Lucas Cordiviola" lucarda27@hotmail.com An: "IOhannes m zmoelnig" zmoelnig@iem.at, "pd-dev@lists.iem.at" pd-dev@lists.iem.at Betreff: Re: [PD-dev] Current GIT master builds are unable to load Gem on Windows
I did some tests and research:
This has changed since 0.48.1:
https://github.com/pure-data/pure-data/commit/fee700b3b35caddab2ab4a48a726a6...
For some unknown reason Gem.dll fails to load but other old dlls loads fine.
So I tried to compile Gem to see what happened. It turned that my compiled Gem.dll loads fine on my compiled >0.48.1 Pd.
To compile gem I use the current git master branch and did on Msys2:
./autogen.sh ./configure --with-pd=C:/pd-sources/32 --prefix=E:/win10onexthd/gem-test/Gem-master/out-luc --without-ftgl
I get:
*****************************************************************
Result: Target : Gem.dll Objects : default window : gemw32window
Configuration: Compiler : g++ CXXFLAGS : -g -O2 -freg-struct-return -mms-bitfields -O3 -falign-loops -falign-functions -falign-jumps -funroll-loops -ffast-math -mmmx : DEFINES :
LIBS : -lgdi32 -lws2_32 -lmsvcrt -lz -lm : -lvfw32 LDFLAGS : :
Install path : E:/win10onexthd/gem-test/Gem-master/out-luc
RTE (Pure Data): external-extension : dll CFLAGS : -DPD -IC:/pd-sources/32/src LIBS : -LC:/pd-sources/32/bin -Xlinker -l:pd.dll
used optional libraries:
font-rendering : default font :
image-support use ImageMagick : no use QuickTime : no use AVFoundation : no use TIFF : no use JPEG : no moviefile-support use PLUGINS : yes use mpeg : no use mpeg-3 : no use QuickTime : no use AVFoundation : use aviplay : no use gmerlin : no capture-support use PLUGINS : yes use v4l : no use v4l2 : no use ieee1394 : no use DV : no use Unicap : yes use Video-for-WinDOS : yes use QuickTime : no use AVFoundation : no *************************************************************
It took 2hs to compile and Gem.dll is 81.9 MB
I copied "libwinpthread-1.dll" & "libstdc++-6.dll" from the compiler to the Gem folder.
Gem loads but can't create the [gemwin]. -- Mensaje telepatico asistido por maquinas.
On 3/20/2018 5:50 AM, IOhannes m zmoelnig wrote: On 2018-03-20 05:48, Lucas Cordiviola wrote: Oliver and I did some tests on compiling Pd for windows.
We found that the current master branch can't load Gem.
We can load it with Miller's build or with self builds from "pure-data-mingw-autotools2" branch from January 9, 2018.
We are sure this is not an "msvcr71.dll" issue or a "-lib" issue.
We get:
C:\Users\Lucarda\Documents\Pd\externals\gem\gem.dll: couldn't load ouch. good catch. do you have the failing binaries available?
since i'm not a w32 guy, any help is much appreciated.
fgmasdr IOhannes
_______________________________________________ Pd-dev mailing listPd-dev@lists.iem.at[mailto:Pd-dev@lists.iem.at]https://lists.puredata.info/listinfo/pd-dev _______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev%5Bhttps://lists.puredata.info/li...]
I'm starting pd with
pd -noprefs -font 12 -path C:\Users\Lucarda\Documents\Pd\externals\Gem -lib Gem
I get the warning in the console:
*******************
GEM: Graphics Environment for Multimedia GEM: ver: 0.93. GEM: compiled on Mar 24 2018 GEM: maintained by IOhannes m zmoelnig GEM: Authors : Mark Danks (original version) GEM: Chris Clepper GEM: Cyrille Henry GEM: IOhannes m zmoelnig GEM: with help by Guenter Geiger, Daniel Heckenberg, James Tittle, Hans-Christoph Steiner, et al. GEM: found a bug? miss a feature? please report it: GEM: homepage https://gem.iem.at/ GEM: bug-tracker https://bugs.gem.iem.at/ GEM: mailing-list https://lists.puredata.info/listinfo/gem-dev/
---> GEM: please manually add Gem path 'C:/Users/Lucarda/Documents/Pd/externals/Gem' to Pd's search path
GEM: compiled for MMX architecture GEM: using MMX optimization GEM: detected 4 CPUs GEM: image loading support: SGI GEM: image saving support: SGI
***************
But when I go to add it is already there because of the "-path C:\Users\Lucarda\Documents\Pd\externals\Gem"
On the mail below there is output from the config:
default window : gemw32window
--
Mensaje telepatico asistido por maquinas.
On 3/25/2018 8:29 PM, Christof Ressi wrote:
did you add GEM to your path? in recent GEM, [gemwin] is an abstraction.
Gesendet: Montag, 26. März 2018 um 00:55 Uhr Von: "Lucas Cordiviola" lucarda27@hotmail.com An: "IOhannes m zmoelnig" zmoelnig@iem.at, "pd-dev@lists.iem.at" pd-dev@lists.iem.at Betreff: Re: [PD-dev] Current GIT master builds are unable to load Gem on Windows
I did some tests and research:
This has changed since 0.48.1:
https://github.com/pure-data/pure-data/commit/fee700b3b35caddab2ab4a48a726a6...
For some unknown reason Gem.dll fails to load but other old dlls loads fine.
So I tried to compile Gem to see what happened. It turned that my compiled Gem.dll loads fine on my compiled >0.48.1 Pd.
To compile gem I use the current git master branch and did on Msys2:
./autogen.sh ./configure --with-pd=C:/pd-sources/32 --prefix=E:/win10onexthd/gem-test/Gem-master/out-luc --without-ftgl
I get:
Result: Target : Gem.dll Objects : default window : gemw32window
Configuration: Compiler : g++ CXXFLAGS : -g -O2 -freg-struct-return -mms-bitfields -O3 -falign-loops -falign-functions -falign-jumps -funroll-loops -ffast-math -mmmx : DEFINES :
LIBS : -lgdi32 -lws2_32 -lmsvcrt -lz -lm : -lvfw32 LDFLAGS : :
Install path : E:/win10onexthd/gem-test/Gem-master/out-luc
RTE (Pure Data): external-extension : dll CFLAGS : -DPD -IC:/pd-sources/32/src LIBS : -LC:/pd-sources/32/bin -Xlinker -l:pd.dll
used optional libraries:
font-rendering : default font :
image-support use ImageMagick : no use QuickTime : no use AVFoundation : no use TIFF : no use JPEG : no moviefile-support use PLUGINS : yes use mpeg : no use mpeg-3 : no use QuickTime : no use AVFoundation : use aviplay : no use gmerlin : no capture-support use PLUGINS : yes use v4l : no use v4l2 : no use ieee1394 : no use DV : no use Unicap : yes use Video-for-WinDOS : yes use QuickTime : no use AVFoundation : no
It took 2hs to compile and Gem.dll is 81.9 MB
I copied "libwinpthread-1.dll" & "libstdc++-6.dll" from the compiler to the Gem folder.
Gem loads but can't create the [gemwin].
-- Mensaje telepatico asistido por maquinas.
On 3/20/2018 5:50 AM, IOhannes m zmoelnig wrote: On 2018-03-20 05:48, Lucas Cordiviola wrote: Oliver and I did some tests on compiling Pd for windows.
We found that the current master branch can't load Gem.
We can load it with Miller's build or with self builds from "pure-data-mingw-autotools2" branch from January 9, 2018.
We are sure this is not an "msvcr71.dll" issue or a "-lib" issue.
We get:
C:\Users\Lucarda\Documents\Pd\externals\gem\gem.dll: couldn't load ouch. good catch. do you have the failing binaries available?
since i'm not a w32 guy, any help is much appreciated.
fgmasdr IOhannes
Pd-dev mailing listPd-dev@lists.iem.at[mailto:Pd-dev@lists.iem.at]https://lists.puredata.info/listinfo/pd-dev _______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev%5Bhttps://lists.puredata.info/li...]
@Christof
For some reason I didn't had the gemwin.pd. I copied it and now it works.
:)
Mensaje telepatico asistido por maquinas.
On 3/25/2018 8:59 PM, Lucas Cordiviola wrote:
I'm starting pd with
pd -noprefs -font 12 -path C:\Users\Lucarda\Documents\Pd\externals\Gem -lib Gem
I get the warning in the console:
GEM: Graphics Environment for Multimedia GEM: ver: 0.93. GEM: compiled on Mar 24 2018 GEM: maintained by IOhannes m zmoelnig GEM: Authors : Mark Danks (original version) GEM: Chris Clepper GEM: Cyrille Henry GEM: IOhannes m zmoelnig GEM: with help by Guenter Geiger, Daniel Heckenberg, James Tittle, Hans-Christoph Steiner, et al. GEM: found a bug? miss a feature? please report it: GEM: homepage https://gem.iem.at/ GEM: bug-tracker https://bugs.gem.iem.at/ GEM: mailing-list https://lists.puredata.info/listinfo/gem-dev/
---> GEM: please manually add Gem path 'C:/Users/Lucarda/Documents/Pd/externals/Gem' to Pd's search path
GEM: compiled for MMX architecture GEM: using MMX optimization GEM: detected 4 CPUs GEM: image loading support: SGI GEM: image saving support: SGI
But when I go to add it is already there because of the "-path C:\Users\Lucarda\Documents\Pd\externals\Gem"
On the mail below there is output from the config:
default window : gemw32window
--
Mensaje telepatico asistido por maquinas.
On 3/25/2018 8:29 PM, Christof Ressi wrote:
did you add GEM to your path? in recent GEM, [gemwin] is an abstraction.
Gesendet: Montag, 26. März 2018 um 00:55 Uhr Von: "Lucas Cordiviola" lucarda27@hotmail.com An: "IOhannes m zmoelnig" zmoelnig@iem.at, "pd-dev@lists.iem.at" pd-dev@lists.iem.at Betreff: Re: [PD-dev] Current GIT master builds are unable to load Gem on Windows
I did some tests and research:
This has changed since 0.48.1:
https://github.com/pure-data/pure-data/commit/fee700b3b35caddab2ab4a48a726a6...
For some unknown reason Gem.dll fails to load but other old dlls loads fine.
So I tried to compile Gem to see what happened. It turned that my compiled Gem.dll loads fine on my compiled >0.48.1 Pd.
To compile gem I use the current git master branch and did on Msys2:
./autogen.sh ./configure --with-pd=C:/pd-sources/32 --prefix=E:/win10onexthd/gem-test/Gem-master/out-luc --without-ftgl
I get:
Result: Target : Gem.dll Objects : default window : gemw32window
Configuration: Compiler : g++ CXXFLAGS : -g -O2 -freg-struct-return -mms-bitfields -O3 -falign-loops -falign-functions -falign-jumps -funroll-loops -ffast-math -mmmx : DEFINES :
LIBS : -lgdi32 -lws2_32 -lmsvcrt -lz -lm : -lvfw32 LDFLAGS : :
Install path : E:/win10onexthd/gem-test/Gem-master/out-luc
RTE (Pure Data): external-extension : dll CFLAGS : -DPD -IC:/pd-sources/32/src LIBS : -LC:/pd-sources/32/bin -Xlinker -l:pd.dll
used optional libraries:
font-rendering : default font :
image-support use ImageMagick : no use QuickTime : no use AVFoundation : no use TIFF : no use JPEG : no moviefile-support use PLUGINS : yes use mpeg : no use mpeg-3 : no use QuickTime : no use AVFoundation : use aviplay : no use gmerlin : no capture-support use PLUGINS : yes use v4l : no use v4l2 : no use ieee1394 : no use DV : no use Unicap : yes use Video-for-WinDOS : yes use QuickTime : no use AVFoundation : no
It took 2hs to compile and Gem.dll is 81.9 MB
I copied "libwinpthread-1.dll" & "libstdc++-6.dll" from the compiler to the Gem folder.
Gem loads but can't create the [gemwin].
-- Mensaje telepatico asistido por maquinas.
On 3/20/2018 5:50 AM, IOhannes m zmoelnig wrote: On 2018-03-20 05:48, Lucas Cordiviola wrote: Oliver and I did some tests on compiling Pd for windows.
We found that the current master branch can't load Gem.
We can load it with Miller's build or with self builds from "pure-data-mingw-autotools2" branch from January 9, 2018.
We are sure this is not an "msvcr71.dll" issue or a "-lib" issue.
We get:
C:\Users\Lucarda\Documents\Pd\externals\gem\gem.dll: couldn't load ouch. good catch. do you have the failing binaries available?
since i'm not a w32 guy, any help is much appreciated.
fgmasdr IOhannes
Pd-dev mailing listPd-dev@lists.iem.at[mailto:Pd-dev@lists.iem.at]https://lists.puredata.info/listinfo/pd-dev _______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev%5Bhttps://lists.puredata.info/li...]
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev