I would love for this to be an official upstream target! I think having folks who better understand the internals of Perl review the workflow I put together and can possibly identify bugs like issues 22924 would be a good starting place so we don't rely on my hackish patches. Then with some time, we can identify which native extensions are actually required, drop things that aren't from the build, and optimize for the smallest possible variant. The workflow could benefit from a means to specify any custom packages you want in the prefix at build time.
In the process of compiling it sometimes wasn't very clear why Perl was continuing to include things I disabled from the hintfile (like I_PWD and I_GROUP), but everything can be worked around. Thank you for reading!
As someone who has worked extensively with compiling Perl, I am very glad to see there is still interest and exploration in the area. I would love to discuss this with you further, is there some way we can communicate via Facebook or e-mail perhaps?
This was just user-error on my part. I was in the middle of porting an old 32-bit game from Windows when I picked this project up and my dev tooling was an absolute mess. Fresh install of macOS and everything builds fine.
Did you publish an npm package for that?, I think it could be very useful
No packages yet, but I just got things working in every WebAssembly runtime so pull request are welcome to get packages on NPM.
What would it take you think to get your proposal accepted.
In addition what if anything could be improved in Perl itself to make this job easier?
I would love for this to be an official upstream target! I think having folks who better understand the internals of Perl review the workflow I put together and can possibly identify bugs like issues 22924 would be a good starting place so we don't rely on my hackish patches. Then with some time, we can identify which native extensions are actually required, drop things that aren't from the build, and optimize for the smallest possible variant. The workflow could benefit from a means to specify any custom packages you want in the prefix at build time.
In the process of compiling it sometimes wasn't very clear why Perl was continuing to include things I disabled from the hintfile (like I_PWD and I_GROUP), but everything can be worked around. Thank you for reading!
Wow very impressive!
As someone who has worked extensively with compiling Perl, I am very glad to see there is still interest and exploration in the area. I would love to discuss this with you further, is there some way we can communicate via Facebook or e-mail perhaps?
https://www.facebook.com/wnbjr/
wbraswell_substack AT nym DOT hush DOT com
"After many hours, this was the magical incantation that finally produced a static build of Perl on Linux"
Again, it is simpler than what you are describing here. If you want to find docs I can point you to them.
If you are intetested in gettibg Perl compiled on MacOS warn me, it's quite doable (e.g., https://learn.perl.org/installing/osx.html).
This was just user-error on my part. I was in the middle of porting an old 32-bit game from Windows when I picked this project up and my dev tooling was an absolute mess. Fresh install of macOS and everything builds fine.
One other option, simple with Perl, is using Inline to support other languages within the perl code.
Creating a minimal perly container isn't hard either:
https://speakerdeck.com/lembark/thinking-inside-the-box-dockerizing-perl?slide=2
Perl has the bindings for exiftool, so you might find it simple enough to just bundle Perl and have a drop-in handler.