Ary Borenszweig

I think it's the same thing if you use the interpreter with the sample http server. I get the same thing. I think the link flags for openssl changed recently...

Is that on an M1? Now that I'm thinking about it, I might started getting that just on M1. There's also https://github.com/cl-plus-ssl/cl-plus-ssl/issues/114 (I didn't ready it yet)

This might also be the fix: https://github.com/cl-plus-ssl/cl-plus-ssl/pull/115

(but to be honest I'm not sure what's going on... it seems we need to use versioned libcrypto and libssl libraries, fake them because those files don't actually exist... but...

> Ehm, we just tell it which path we want? 🤔 via Loader#load_file. Sure! How do you do that from a `@[Link]` annotation?

@straight-shoota @beta-ziliani Note that if we launch the interpreter as experimental, particularly on Mac OS, then running an http server with the interpreter doesn't work because of this issue.

Here you go! ``` $ pkg-config --libs --silence-errors libcrypto -L/opt/homebrew/Cellar/[email protected]/1.1.1q/lib -lcrypto $ ls -l /opt/homebrew/Cellar/[email protected]/1.1.1q/lib/*crypto* -r--r--r-- 1 aryborenszweig admin 2192864 Jul 8 08:02 /opt/homebrew/Cellar/[email protected]/1.1.1q/lib/libcrypto.1.1.dylib -r--r--r-- 1 aryborenszweig admin 3850784 Jul...

I jus tried it. It didn't work. I added `p! path` to the above diff to see what paths are being checked. Here's what I got: ``` path # =>...

What's interesting is that neither of those files ("/usr/lib/libz.dylib" and "/usr/lib/libssl.dylib") exist on my machine.

Did you look at this? https://github.com/cl-plus-ssl/cl-plus-ssl/pull/115/files It seems linking to some magic numbered versions should do the trick, but I don't know.