Mac error loading lib

[CurtTilmes]

From: William Michels

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.

[CurtTilmes]

From: Vadim Belman

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

[CurtTilmes]

From: William Michels

Thank you, Vadim, for your kind reply. I wondered if a recent commit
to Raku-LibCurl may have improved installation/loading on Linux
machines, while simultaneously breaking installation/loading on MacOS:

...

As for the rest of my installation, I believe the Perl6-Users mailing
list is the best place to hash out these issues. We have a number of
Mac users who frequent this list, and would be able to discuss Mac
file extensions (e.g. the ".dylib" vs ".so" issue). Thank you for
confirming that in your opinion, Raku LibCurl version 1.0 may be
failing to install on MacOS because the installer is looking for
'libcurl.so.4'.

I certainly understand symlinking if necessary but as I stated
previously, call-outs to native LibCurl worked fine under Rakudo
2020.02.1, and presently call-outs to native LibCurl work just fine
under Rakudo 2020.06 (specifically using Raku LibCurl:ver<0.9>). I'll
know if I have real problems if other Mac users are getting Raku
LibCurl:ver<1.0> to work--while I cannot.

Anyone knowledgeable want to help out and craft a PR for the module's author?

Best Regards. Bill.

W. Michels, Ph.D.

[jubilatious1]

Thanks to Curt's recent commit I was able to update to Raku LibCurl:ver<1.1> (although the default now is to skip release tests--thus no tests were run):

userB@mbook:~$ zef upgrade LibCurl --verbose    
===> Searching for: LibCurl    
===> Updating cpan mirror: https://raw.githubusercontent.com/ugexe/Perl6-ecosystems/master/cpan1.json    
===> Updating p6c mirror: https://raw.githubusercontent.com/ugexe/Perl6-ecosystems/master/p6c1.json    
===> Updated p6c mirror: https://raw.githubusercontent.com/ugexe/Perl6-ecosystems/master/p6c1.json    
===> Updated cpan mirror: https://raw.githubusercontent.com/ugexe/Perl6-ecosystems/master/cpan1.json    
===> Found: LibCurl:ver<1.1>:auth<github:CurtTilmes>:api<1> [via Zef::Repository::Ecosystems<cpan>]    
The following distributions will be upgraded: LibCurl:ver<1.1>:auth<github:CurtTilmes>:api<1>    
===> Updating: LibCurl:ver<1.1>:auth<github:CurtTilmes>:api<1>    
===> Fetching [OK]: http://www.cpan.org/authors/id/C/CT/CTILMES/Perl6/LibCurl-1.1.tar.gz to /Users/userB/.zef/tmp/1594661501.56793.6675.198392106874/LibCurl-1.1.tar.gz    
===> Extraction [OK]: http://www.cpan.org/authors/id/C/CT/CTILMES/Perl6/LibCurl-1.1.tar.gz to /Users/userB/.zef/store/LibCurl-1.1.tar.gz    
===> Testing: LibCurl:ver<1.1>:auth<github:CurtTilmes>:api<1>    
[LibCurl] t/00-meta.t ..... skipped: test: To enable author tests, set AUTHOR_TESTING env var    
[LibCurl] t/01-load.t ..... ok    
[LibCurl] t/02-basic.t .... skipped: test: To enable release tests, set RELEASE_TESTING env var    
[LibCurl] t/03-http.t ..... skipped: test: To enable release tests, set RELEASE_TESTING env var    
[LibCurl] t/04-form.t ..... skipped: test: To enable release tests, set RELEASE_TESTING env var    
[LibCurl] t/05-WWW.t ...... skipped: test: To enable release tests, set RELEASE_TESTING env var    
[LibCurl] t/06-content.t .. skipped: test: To enable release tests, set RELEASE_TESTING env var    
[LibCurl] t/07-mime.t ..... skipped: test: To enable release tests, set RELEASE_TESTING env var    
[LibCurl] All tests successful.    
[LibCurl] Files=8, Tests=5, 21 wallclock secs ( 0.03 usr  0.02 sys + 24.48 cusr  1.39 csys = 25.92 CPU)    
[LibCurl] Result: PASS    
===> Testing [OK] for LibCurl:ver<1.1>:auth<github:CurtTilmes>:api<1>    
===> Installing: LibCurl:ver<1.1>:auth<github:CurtTilmes>:api<1>    
===> Install [OK] for LibCurl:ver<1.1>:auth<github:CurtTilmes>:api<1>    
userB@mbook:~$

After installing LibCurl:ver<1.1> I ran a script entitled "libcurl-example.pl6" from the Github repo entitled "learn-raku-by-examples". The script worked perfectly. So I believe this issue is fixed, at least for older MacOS versions (MacOSX ~Version 10.10 or so).

Reference: https://github.com/ohmycloud/learn-raku-by-examples

@fecundf
@doomvox
@ohmycloud

https://github.com/ohmycloud/learn-raku-by-examples

[ugexe]

➜  rakudo git:(master) raku -e 'say $*VM.platform-library-name("curl".IO, :version(v4)).basename'
libcurl.4.dylib

@CurtTilmes I think the above will solve your issue in a more generic way