You have so many things messed up in a single mail, it's hard to choose the one 
to start with. By attempting to install the module myself I suddenly spotted it 
at once: the module is buggy and need fixing. macOS doesn't support .so format. 
Instead, it's using own .dylib. It's hard to tell what exactly wrong about the 
module, but the first guess would be about it using explicit full file name 
when loading a native lib where it should use just 'libcurl'.

With regard to other matters, the most crucial one which may affect you in the 
future, is a security feature of macOS which only allows loading of dynamic 
libraries either from system paths like /lib/ or /usr/lib/; or from lib/ dir 
located in the same subdirectory where the program executable is located. I.e. 
whatever is installed in /opt/local/bin have access to dynamic libraries in 
/opt/local/lib. If your rakudo executable is installed somewhere else 
(~/raku/bin for me) it wouldn't see nothing in /opt/local/lib. This can be 
fixed by symlinking the files of libs into a location where they're available 
to raku. I think rakubrew does it automatically for a user; or at least the 
feature was planned. Another way is to link the files into ~/lib which is also 
considered by macOS for executables under user's home dir.

Best regards,
Vadim Belman

> On Jul 10, 2020, at 10:00 PM, William Michels via perl6-users 
> <perl6-us...@perl.org> wrote:
> 
> Hello,
> 
> I just updated to Rakudo-2020.06, and while updating many of my
> modules to their latest versions I saw an error installing/updating
> (Raku) LibCurl. Below, the first few lines of the error seen with
> LibCurl::Easy (and EasyHandle):
> 
> ===> Testing: LibCurl:ver<1.0>:auth<github:CurtTilmes>:api<1>
> [LibCurl] # Failed test 'LibCurl::EasyHandle module can be use-d ok'
> [LibCurl] # at t/01-load.t line 6
> [LibCurl] # Cannot load native library 'libcurl.so.4'
> [LibCurl] # Failed test 'LibCurl::Easy module can be use-d ok'
> [LibCurl] # at t/01-load.t line 8
> [LibCurl] # ===SORRY!=== Error while compiling
> /Users/myuseraccount/.zef/store/raku-libcurl.git/random_40-character-alphanumeric/lib/LibCurl/Easy.rakumod
> (LibCurl::Easy)
> [LibCurl] # Cannot load native library 'libcurl.so.4'
> [LibCurl] # at 
> /Users/myuseraccount/.zef/store/raku-libcurl.git/random_40-character-alphanumeric/lib/LibCurl/Easy.rakumod
> (LibCurl::Easy):2
> 
> So one caveat is that this install is on an OS which many would
> consider to be "MacOS.10.ancient" [I'm posting here and not on Github
> because we seem to have a number of Mac users on this mailing-list].
> But the fact of the matter is Raku LibCurl:ver<0.9> worked just fine
> with Rakudo-2020.02.1. Furthermore, now that I've downgraded back to
> Raku LibCurl:ver<0.9>, LibCurl::Easy works once again on the latest
> Rakudo-2020.06. So I really feel the problem is with LibCurl:ver<1.0>
> on Macs, and not my particular install.
> 
> Questions for Mac-heads: Do newer versions of MacOS still install
> LibCurl as part of the OS? Where does that reside? I know I have
> libcurl in the following directories, however 'libcurl.so.4' is
> conspicuously absent:
> 
> /opt/local/lib/libcurl.4.dylib
> /opt/local/lib/libcurl.a
> /opt/local/lib/libcurl.dylib
> 
> Are Mac-users able to use (Raku) LibCurl:ver<1.0> on their (newer)
> systems? FYI, I've installed curl independently of MacOS via either
> MacBrew or MacPorts, and in fact MacBrew reports upon attempting to
> update: "Warning: curl 7.71.1 is already installed and up-to-date".
> 
> Any help appreciated, Thx, Bill.
> 

Reply via email to