[squeak-dev] FFI and mpfr calls in squeak

Tobias Pape Das.Linux at gmx.de
Fri Aug 14 06:39:59 UTC 2020


> On 14.08.2020, at 00:10, LawsonEnglish <LEnglish5 at cox.net> wrote:
> 
> You are correct and i figured out my problem. The mpfr dylib has hard-coded references to the libgmp.dylib that was in the original directory that macports compiled  the mpfr.dylib into. I’ll need to do craig latta’s solution of allowing that library to work, OR redirect macports to compile into the Resources directory.
> 
> This is going to make using Macports installed stuff rather difficult to use,m at least on Mac OS.
> 
> Unless it is possible to tweak the dylib to redirect to the Resourses directory…

Yes, its called
	
	install_name_tool(1) change dynamic shared library install names


> 
> And the answer is: not easily: http://lessons.livecode.com/m/4071/l/15029-linking-an-osx-external-bundle-with-a-dylib-library
> 
> I’d have to figure out to manually compile the code and specify the build options at levels that aren’t exaclty relevent to my vision of a hello world implementation.
> 
> (so much for sticking my toe in the water while recovering from a 5 year, near-fatal illness).


(Sorry, If you mean that literally, all the best for your recovery)

> 
> Thanks for your advice, and you were spot on in what you thought was going on. Macports hardcodes the mpfr dylib to only work in that directory, and only look for the external gmp dylib in the same directory.
> 
> libmpfr.6.dylib:
> 	/opt/local/lib/libmpfr.6.dylib (compatibility version 7.0.0, current version 7.2.0)
> 	/opt/local/lib/libgmp.10.dylib (compatibility version 15.0.0, current version 15.0.0)
> 	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.100.1)

That's how most dylibs work :/
-t

> 
> L
> 
> 
>> On Aug 13, 2020, at 4:21 AM, Marcel Taeumel <marcel.taeumel at hpi.de> wrote:
>> 
>> Hi Lawson.
>> 
>> >  I think: the mpfr library uses the gmp library. So how does one do THAT with squeak?
>> 
>> You don't. Your operating system does that for you. Well, the same lookup rules for that dependent library apply, I suppose. Do you have the gmp library installed in your system?
>> 
>> Yes, not having all dependent libraries does raise that "external module not found" error, too. It can be confusing.
>> 
>> Working with FFI requires knowledge about working with shared libraries in your operating system. It's one of those "leaky abstractions" where Squeak is -- understandably -- not able to hold your hand for all kinds of configurations out there. :-)
>> 
>> You can try using a debug-build VM, which produces a more descriptive error log.
>> 
>> Best,
>> Marcel
>>> Am 13.08.2020 12:11:53 schrieb LawsonEnglish <lenglish5 at cox.net>:
>>> 
>>> So I tested a simple mandelbrot set rendering algorithm using the ArbitraryPrecisionFloat package and it works just fine, but terribly slowly.
>>> 
>>> So I had the idea of using mpfr via FFI and find that I can’t even begin.
>>> 
>>> I’m getting the dreaded External module not found error and just can’t get rid of it.
>>> 
>>> I thought I was taking the easy route and simply copying the mpfr library into the Squeak all-in-one Resources directory but no matter what I try, that error pops up.
>>> 
>>> 
>>> initPrecision: aDefaultPrecision
>>> “initialize default precision"
>>> 
>>> 
>>> ^self externalCallFailed 
>>> 
>>> This is roughly the “hello world” of using mpfr, I thought, but can’t even do that.
>>> 
>>> Now, waiting in the wings is a bigger problem, I think: the mpfr library uses the gmp library. So how does one do THAT with squeak? Compile both libraries into a single target? (yikes!).
>>> 
>>> That might be an issue later on, but the impression I’m getting is that squeak simply can’t find libmpfr.6.dylib, so errors that result from calling a second library from the first haven’t even popped up yet.
>>> 
>>> 
>>> Squeak5.3-19435-64bit, Mac OS X 10.15.6
>>> 
>>> 
>>> Thanks 
>>> 
>>> 
>>> Lawson
>>> 
>> 
> 
> 




More information about the Squeak-dev mailing list