Closed andinus closed 7 months ago
added libz:from<native>
to the meta, will release with v52
This is fixed in v52 (disabled until Raku AST), please upgrade and confirm
Hello, thanks for the fix. I was waiting for the release, I'll clone, test and get back in a while.
Hello, I installed the latest main but faced the same issue. You have mentioned Raku AST, do I have to install another version of Rakudo to test this? I'm currently running v2023.02.
Hello, I installed the latest main but faced the same issue. You have mentioned Raku AST, do I have to install another version of Rakudo to test this? I'm currently running v2023.02.
you shouldn't have to install newer rakudo. can you post the log of your fez upgrade?
@andinus you're right, the bit that fixes this wasn't merged and didn't make it into 52, i've just uploaded a fix that should resolve this problem
I upgraded to fez v53, it seems to be failing without the symlink, here are the logs:
andinus@cadmium ~/d/p/TemplateNestFast (main)> fez v
>>= fez version: 53
andinus@cadmium ~/d/p/TemplateNestFast (main)> fez upload | ts
Jun 27 10:44:35 >>= Bundle manifest:
Jun 27 10:44:35 INSTALL
Jun 27 10:44:35 lib/Template/Nest/Fast.rakumod
Jun 27 10:44:35 LICENSE
Jun 27 10:44:35 META6.json
Jun 27 10:44:35 README.md
Jun 27 10:44:35 README.org
Jun 27 10:44:35 sdist
Jun 27 10:44:35 t/00-basic.rakutest
Jun 27 10:44:35 t/01-render.rakutest
Jun 27 10:44:35 t/02-die-on-bad-params.rakutest
Jun 27 10:44:35 t/03-show-labels.rakutest
Jun 27 10:44:35 t/04-template-extension.rakutest
Jun 27 10:44:35 t/05-fixed-indent.rakutest
Jun 27 10:44:35 t/06-token-delims.rakutest
Jun 27 10:44:35 t/07-token-escape-char.rakutest
Jun 27 10:44:35 t/08-defaults.rakutest
Jun 27 10:44:35 t/09-advanced-indexing.rakutest
Jun 27 10:44:35 t/output/01-simple-page.html
Jun 27 10:44:35 t/output/02-complex-page.html
Jun 27 10:44:35 t/output/03-incomplete-page.html
Jun 27 10:44:35 t/output/04-simple-page-with-labels.html
Jun 27 10:44:35 t/output/05-simple-page-with-labels-alt-delims.html
.
.
.
Jun 27 10:44:35 t/templates/30-main.js
=<< ERROR: Cannot locate native library 'libz.so.1': Can't open file
in method setup at /usr/local/rakudo/share/perl6/core/sources/AB656B57E89844C20E64AD00D73B22D608606275 (NativeCall) line 319
in method setup at /usr/local/rakudo/share/perl6/core/sources/AB656B57E89844C20E64AD00D73B22D608606275 (NativeCall) line 366
in sub raku-nativecall at /usr/local/rakudo/share/perl6/core/sources/58D665973BEDAF2102D2549DF3EDEFF08C1436AA (NativeCall::Dispatcher) line 46
in sub cmprs at /home/andinus/.raku/sources/77E3AE759BE85E4975CBB6056FC7FB2EF632AFEB (Fez::Util::Zlib) line 33
in method bundle at /home/andinus/.raku/sources/9401531DDECD191EFA1420C76304E6A520DF8ABE (Fez::Util::Pkg) line 13
in sub bundle at /home/andinus/.raku/sources/B55A5B1B7EC13A3062F606169D51CD0450F3DE62 (Fez::Bundle) line 56
in block at /home/andinus/.raku/sources/25EDD0451E77FD0D53C7B66A004B7DEABDAA075A (Fez::CLI) line 500
in sub MAIN at /home/andinus/.raku/sources/25EDD0451E77FD0D53C7B66A004B7DEABDAA075A (Fez::CLI) line 489
in block <unit> at /home/andinus/.raku/resources/1C755270C5FC59FD97B703F2E903BDFE03F40FC4 line 4
in sub MAIN at /home/andinus/.raku/bin/fez line 3
in block <unit> at /home/andinus/.raku/bin/fez line 1
=<< FATAL: Bundling error: This exception is not resumable
Jun 27 10:44:37 >>= Resources ok
@andinus fez requires zlib-dev or your OS' equivalent, that should fix the issue you're seeing. i don't have a lot of control over the name/path of the file that is resolved when i do is native('z')
in raku
I see, I do have the shared object file but it's named libz.so.7.0
. According to https://www.openbsd.org/faq/ports/specialtopics.html#SharedLibs that seems like expected behavior. It seems like Raku docs have details on this issue: https://docs.raku.org/language/faq#Nativecall_can't_find_libfoo.so_and_I_only_have_libfoo.so.1.2!
Does creating a symlink seem like a better solution?
I think this is a fundamental issue about a theory vs reality mismatch.
In theory when using a library I'll always want to depend on a specific major version, as a wrong major version will potentially be incompatible with my software. So there should never be a is native('foo');
, but instead always a is native('foo',v1);
in released Raku modules.
I suspect in practice major versions of libraries often change without breaking the public API in such a way that the Raku module breaks. I haven't seen a single Raku module that depended on a specific major version. And I have not yet heard of a case where a Raku module became incompatible after a release of a new major version of a library.
Ideas:
is native('foo');
just pick the latest version there is. (This could be messy, as currently the resolution to a specific library file is not done by us.)is native('foo',(v4, v2, v1));
or is native('foo',v3..v1);
is native('foo');
@andinus i wonder if bundling libz so's would be a fix for this too, afaik it only requires building for ARM and x64 at the moment
I think that should do the trick. Also, I don't understand but this might be related to the changes made for this fix: https://github.com/tony-o/raku-fez/issues/103
Is there a way to specify vX+
? like we have for raku modules ("Cairo:ver<0.2.7+>"
).
The real fix here could just be writing a gzipper in pure raku and putting it in the repo, I just haven't had time to get one working/tested.
this fix is also part of #103
After this it works: