To jump in …
I have a similar issue with pd where compiling explicitly i386 32 bit only still cannot load a gem binary that is 32 bit ppc & i386. I have another build of gem that is also i386 only and it doesn’t load either, but I was thinking that’s due to all the build fiddling I’ve been doing in the autotools_udpate branch. Other i386 only externals are working fine.
-------- Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On May 3, 2016, at 4:00 AM, gem-dev-request@lists.iem.at wrote:
From: j-p k <jptrkz@gmail.com mailto:jptrkz@gmail.com> Subject: Re: [GEM-dev] Gem Build Errors Date: May 3, 2016 at 2:02:01 AM MDT Cc: gem-dev@lists.iem.at mailto:gem-dev@lists.iem.at
compiled against version & running version = 0.47 (keeping everything 32 bit)
output:
/Applications/Pd-0.47-0test2.app/Contents/Resources/bin/pd: Mach-O universal binary with 2 architectures
/Applications/Pd-0.47-0test2.app/Contents/Resources/bin/pd (for architecture i386): Mach-O executable i386
/Applications/Pd-0.47-0test2.app/Contents/Resources/bin/pd (for architecture ppc7400): Mach-O executable ppc
pretty sure i got the same results with 0.45-4 but i'll try again tomorrow. 0.45-4 was working with git-Gem on another computer running osx10.6 at the point gemvertexbuffer hit the wall
thank you yes i have Pd-0.47-0test4-64bit working with 64bit Gem, so long as a path is made to Gem/abstractions
On Tue, May 3, 2016 at 3:56 PM, Dan Wilcox danomatika@gmail.com wrote:
To jump in …
I have a similar issue with pd where compiling explicitly i386 32 bit only still cannot load a gem binary that is 32 bit ppc & i386. I have another build of gem that is also i386 only and it doesn’t load either, but I was thinking that’s due to all the build fiddling I’ve been doing in the autotools_udpate branch. Other i386 only externals are working fine.
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com robotcowboy.com
On May 3, 2016, at 4:00 AM, gem-dev-request@lists.iem.at wrote:
*From: *j-p k jptrkz@gmail.com *Subject: **Re: [GEM-dev] Gem Build Errors* *Date: *May 3, 2016 at 2:02:01 AM MDT *Cc: *gem-dev@lists.iem.at
compiled against version & running version = 0.47 (keeping everything 32 bit)
output:
/Applications/Pd-0.47-0test2.app/Contents/Resources/bin/pd: Mach-O universal binary with 2 architectures
/Applications/Pd-0.47-0test2.app/Contents/Resources/bin/pd (for architecture i386): Mach-O executable i386
/Applications/Pd-0.47-0test2.app/Contents/Resources/bin/pd (for architecture ppc7400): Mach-O executable ppc
pretty sure i got the same results with 0.45-4 but i'll try again tomorrow. 0.45-4 was working with git-Gem on another computer running osx10.6 at the point gemvertexbuffer hit the wall
GEM-dev mailing list GEM-dev@lists.iem.at https://lists.puredata.info/listinfo/gem-dev
Doing some digging with the 3 arch GEM build listed in deken:
* just adding the path -> no GEM abstractions load * added Gem to the startup libraries list -> GEM abstractions load except for gemglutwindow, also gemcocoawindow & gemglfwwindow do not work either
-------- Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On May 3, 2016, at 1:56 PM, Dan Wilcox danomatika@gmail.com wrote:
To jump in …
I have a similar issue with pd where compiling explicitly i386 32 bit only still cannot load a gem binary that is 32 bit ppc & i386. I have another build of gem that is also i386 only and it doesn’t load either, but I was thinking that’s due to all the build fiddling I’ve been doing in the autotools_udpate branch. Other i386 only externals are working fine.
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On May 3, 2016, at 4:00 AM, gem-dev-request@lists.iem.at mailto:gem-dev-request@lists.iem.at wrote:
From: j-p k <jptrkz@gmail.com mailto:jptrkz@gmail.com> Subject: Re: [GEM-dev] Gem Build Errors Date: May 3, 2016 at 2:02:01 AM MDT Cc: gem-dev@lists.iem.at mailto:gem-dev@lists.iem.at
compiled against version & running version = 0.47 (keeping everything 32 bit)
output:
/Applications/Pd-0.47-0test2.app/Contents/Resources/bin/pd: Mach-O universal binary with 2 architectures
/Applications/Pd-0.47-0test2.app/Contents/Resources/bin/pd (for architecture i386): Mach-O executable i386
/Applications/Pd-0.47-0test2.app/Contents/Resources/bin/pd (for architecture ppc7400): Mach-O executable ppc
pretty sure i got the same results with 0.45-4 but i'll try again tomorrow. 0.45-4 was working with git-Gem on another computer running osx10.6 at the point gemvertexbuffer hit the wall
On 05/06/2016 08:57 AM, Dan Wilcox wrote:
- added Gem to the startup libraries list -> GEM abstractions load
except for gemglutwindow, also gemcocoawindow & gemglfwwindow do not work either
??? since these are just ordinary abstractions like any other that liv ein the Gem/ folder i wonder: - do these abstractions exist? - can they be loaded directly? (e.g. does instantiating [gemglutwindow] work?) - is the problem you are describing one of abstractions withing abstractions? (e.g. [gemglutwindow] cannot be instantiated inside the [gemwin] abstraction
fgdsamr IOhannes
On 05/06/2016 08:02 PM, IOhannes m zmölnig wrote:
since these are just ordinary abstractions like any other
well, they are externals, rather than abstractions. so do you have an idea why they cannot be loaded? (e.g. some unresolved symbols thing? which one??)
gfdmase IOhannes
continuing the architecture of ftgl question: i found the 1.5+ year old git-gem compiled against 0.45-4 and after running with this new computer received: (something-like) "libftgl.2.dylib mach-o but wrong architecture" then, in terminal: file libftgl.2.1.3.dylib: *"libftgl.2.1.3.dylib: Mach-O 64-bit dynamically linked shared library x86_64"*
..so i don't think it's enough (or even works at all) to use --32-bit or --universal for installing ftgl
after replacing libftgl.2.1.3(64-bit) with a libftgl.2(32-bit) in the /usr/local/Cellar/etc, i get no errors with git-Gem and 32bit pd-vanilla(all versions tried). what is the best way to obtain 32-bit ftgl?
On Fri, May 6, 2016 at 2:04 PM, IOhannes m zmölnig zmoelnig@iem.at wrote:
On 05/06/2016 08:02 PM, IOhannes m zmölnig wrote:
since these are just ordinary abstractions like any other
well, they are externals, rather than abstractions. so do you have an idea why they cannot be loaded? (e.g. some unresolved symbols thing? which one??)
gfdmase IOhannes
GEM-dev mailing list GEM-dev@lists.iem.at https://lists.puredata.info/listinfo/gem-dev
and by "no errors" i mean it loaded
On Fri, May 6, 2016 at 3:35 PM, j-p k jptrkz@gmail.com wrote:
continuing the architecture of ftgl question: i found the 1.5+ year old git-gem compiled against 0.45-4 and after running with this new computer received: (something-like) "libftgl.2.dylib mach-o but wrong architecture" then, in terminal: file libftgl.2.1.3.dylib: *"libftgl.2.1.3.dylib: Mach-O 64-bit dynamically linked shared library x86_64"*
..so i don't think it's enough (or even works at all) to use --32-bit or --universal for installing ftgl
after replacing libftgl.2.1.3(64-bit) with a libftgl.2(32-bit) in the /usr/local/Cellar/etc, i get no errors with git-Gem and 32bit pd-vanilla(all versions tried). what is the best way to obtain 32-bit ftgl?
On Fri, May 6, 2016 at 2:04 PM, IOhannes m zmölnig zmoelnig@iem.at wrote:
On 05/06/2016 08:02 PM, IOhannes m zmölnig wrote:
since these are just ordinary abstractions like any other
well, they are externals, rather than abstractions. so do you have an idea why they cannot be loaded? (e.g. some unresolved symbols thing? which one??)
gfdmase IOhannes
GEM-dev mailing list GEM-dev@lists.iem.at https://lists.puredata.info/listinfo/gem-dev
32 bit ftgl solution is here: https://github.com/Homebrew/legacy-homebrew/pull/18713/files ...which is editing the Library/Formula/ftgl.rb file
then, "brew install ftgl --universal"
terminal: file libftgl.2.1.3.dylib:
libftgl.2.1.3.dylib: Mach-O universal binary with 2 architectures
libftgl.2.1.3.dylib (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64
libftgl.2.1.3.dylib (for architecture i386): Mach-O dynamically linked shared library i386 *compiled latest-gem w/ 0.47-0test2 and it loads*
On Fri, May 6, 2016 at 3:37 PM, j-p k jptrkz@gmail.com wrote:
and by "no errors" i mean it loaded
On Fri, May 6, 2016 at 3:35 PM, j-p k jptrkz@gmail.com wrote:
continuing the architecture of ftgl question: i found the 1.5+ year old git-gem compiled against 0.45-4 and after running with this new computer received: (something-like) "libftgl.2.dylib mach-o but wrong architecture" then, in terminal: file libftgl.2.1.3.dylib: *"libftgl.2.1.3.dylib: Mach-O 64-bit dynamically linked shared library x86_64"*
..so i don't think it's enough (or even works at all) to use --32-bit or --universal for installing ftgl
after replacing libftgl.2.1.3(64-bit) with a libftgl.2(32-bit) in the /usr/local/Cellar/etc, i get no errors with git-Gem and 32bit pd-vanilla(all versions tried). what is the best way to obtain 32-bit ftgl?
On Fri, May 6, 2016 at 2:04 PM, IOhannes m zmölnig zmoelnig@iem.at wrote:
On 05/06/2016 08:02 PM, IOhannes m zmölnig wrote:
since these are just ordinary abstractions like any other
well, they are externals, rather than abstractions. so do you have an idea why they cannot be loaded? (e.g. some unresolved symbols thing? which one??)
gfdmase IOhannes
GEM-dev mailing list GEM-dev@lists.iem.at https://lists.puredata.info/listinfo/gem-dev