I was wrong on one point:
> the framework should be installed at the new location when you call 
> install_name_tool.
install_name_tool only checks for the names from the command line

anyway, I've replaced the package on Sourceforge with a more standard 
dependency. 
The tgz archive is now a dmg file (I got some problems updating and downloading 
the archive. In a first step, I though it was due to the format, but actually I 
think now it was a combination of a mess with sourceforge and my browser 
(safari, to not name it) :-)

--
Dominique


Le 7 oct. 2010 à 10:27, Dominique Fober a écrit :

> Hi Patrick,
> 
> You are supposed to put the GUIDOEngine.framework  in any standard location : 
>  
>       ~/Library/Frameworks
>       /Library/Frameworks
>       /System/Library/Frameworks
> then the system should find it, whatever location is given by otool.
> 
> However, when you want to change the location given by otool, using 
> install_name_tool, the syntax is:
> install_name_tool -change old new 
> where         old is the path given by otool -L 
>               and new is a path to a Mach-O binary e.g. 
> /Library/Frameworks/GUIDOEngine/Versions/B/GUIDOEngine
> the framework should be installed at the new location when you call 
> install_name_tool.
> 
> Does it solves the problem ?
> --
> Dominique
> 
> 
> 
> Le 6 oct. 2010 à 18:22, Patrick Boivin a écrit :
> 
>> Hi Dominique,
>> 
>> I can't get your external to load on mac osx:
>> 
>> 
>> /Users/pboivin/Downloads/guido-pd-mac-1.00/guido.pd_darwin: 
>> dlopen(/Users/pboivin/Downloads/guido-pd-mac-1.00/guido.pd_darwin, 10): no 
>> suitable image found.  Did find:
>>     /Users/pboivin/Downloads/guido-pd-mac-1.00/guido.pd_darwin: unknown 
>> required load command 0x80000022
>>  guido
>> ... couldn't create
>> 
>> 
>> otool tells me that the path for GUIDOEngine.framework hardcoded in 
>> guido.pd_darwin is wrong:
>> 
>> 
>> $ otool -L guido.pd_darwin 
>> guido.pd_darwin:
>>     guido.pd_darwin (compatibility version 0.0.0, current version 0.0.0)
>>     /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 
>> 7.9.0)
>>     /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 
>> 125.2.0)
>>     
>> /Users/fober/src/guido/svn/guidosf/branches/mapping/cmake/Release/GUIDOEngine.framework/Versions/B/GUIDOEngine
>>  (compatibility version 0.0.0, current version 1.40.0)
>> 
>> 
>> and when I try to change it, I get:
>> 
>> 
>> $ install_name_tool -change 
>> /Users/fober/src/guido/svn/guidosf/branches/mapping/cmake/Release/GUIDOEngine.framework/Versions/B/GUIDOEngine
>>  /Library/Frameworks/GUIDOEngine guido.pd_darwin 
>> install_name_tool: object: guido.pd_darwin malformed object (unknown load 
>> command 5)
>> 
>> 
>> osx 10.5.8, intel
>> pd-extended 42.5
>> 
>> 
>> Patrick
>> 
>> On Wed, Oct 6, 2010 at 2:37 AM, Dominique Fober <[email protected]> wrote:
>> Thanks, it solves my problem.
>> Thanks also to Hans-Christoph Steiner who helped with my "GUI external" 
>> question.
>> I have now a 'guido' pd external to display music scores based on the Guido 
>> Engine (http://guidolib.sourceforge.net) running on linux, mac os and 
>> windows. It works but could become very slow in drawing the music score, 
>> depending on the drawing area size and on your platform (windows seems not 
>> to be very efficient).
>> This is due to the way to give the score image to Tcl/Tk.
>> 
>> Now I have a 'newbie in externals dev' question: what is the best place to 
>> share that with Pd users? I can build binaries for Mac OS and windows but 
>> it's a little bit more complex for linux, or is there a main target platform 
>> to build binaries for (for example Ubuntu 10.04 32 or 64 bits).
>> 
>> Dominique
>> 
>> 
>> 
>> Le 4 oct. 2010 à 16:58, <[email protected]> 
>> <[email protected]> a écrit :
>> 
>> >
>> > I usually use the pd.lib from one of Miller's builds, as he uses MSVC:
>> > http://crca.ucsd.edu/~msp/Software/pd-0.42-5.msw.zip
>> > The c interface is different between MS and gcc; some things just crash, 
>> > for example opening a file in code linked with MSVCRT80 and accessing it 
>> > from code linked against libc.
>> >
>> > Martin
>> >
>> >
>> > Dominique wrote:
>> >>
>> >> I'm developing a GUI external that compiles on linux, mac os x... but not 
>> >> yet on windows.
>> >> I've tried to use the Visual C++ tools : due to the missing pd.lib file, 
>> >> the dll generation is forced at link time using the /FORCE:UNRESOLVED 
>> >> flag. My problem is that when I try to use this external, I get a missing 
>> >> MSVCRT80.dll error, and when I put this dll with my external, then I get 
>> >> the following error message "An application has made an attempt to load 
>> >> the C runtime incorrectly".
>> >> Note that since I'm not fond of the MS tools, I've first tried to use gcc 
>> >> (via MingW) to compile. However, then the trouble is with gdiplus since 
>> >> it isn't included in the mingw distribution (missing gdiplus.h and 
>> >> gdiplus.lib).
>> >> Does anybody know how to (quickly) solve this problem.
>> >> --
>> >> Dominique
>> >>
>> >>
>> >> _______________________________________________
>> >> Pd-dev mailing list
>> >> [email protected]
>> >> http://lists.puredata.info/listinfo/pd-dev
>> >
>> 
>> 
>> _______________________________________________
>> Pd-dev mailing list
>> [email protected]
>> http://lists.puredata.info/listinfo/pd-dev
>> 
> 
> _______________________________________________
> Pd-dev mailing list
> [email protected]
> http://lists.puredata.info/listinfo/pd-dev

_______________________________________________
Pd-dev mailing list
[email protected]
http://lists.puredata.info/listinfo/pd-dev

Reply via email to