Thank you Curt--and thanks for writing the Raku LibCurl module!! I'll update my module to (Raku) LibCurl:ver<1.1> and see if that fixes everything. I'll report what I see on the Github issue you created.
Thanks again, Bill. W. Michels, Ph.D. On Mon, Jul 13, 2020 at 8:21 AM Curt Tilmes <c...@tilmes.org> wrote: > > Sorry things broke for you. > > I filed an issue on GitHub > (https://github.com/CurtTilmes/raku-libcurl/issues/16) and copied the > emails there. > > I published a new version 1.1 that will hopefully fix this. Please > let me know (either in that issue, or file new issues) for anything > broken. > > Curt > > On Sat, Jul 11, 2020 at 7:04 PM William Michels via perl6-users > <perl6-us...@perl.org> wrote: > > > > 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: > > > > https://github.com/CurtTilmes/raku-libcurl/commit/6de3338a50cbc43d185c408d965dc2984bcfeaee#diff-7298ce0db5e8b9c63122e5dd725a8d24 > > > > 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. > > > > > > > > > > > > > > On Sat, Jul 11, 2020 at 2:21 PM Vadim Belman <vr...@lflat.org> wrote: > > > > > > 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. > > > > > > >
