Closed MagaTailor closed 8 years ago
BTW, I remember remarking about ARM vs x86 binary size a few months ago - why is it so much bigger now on ARM even without git support?
884456 Oct 2 03:16 /home/odroid/exa
674512 Nov 3 20:24 /usr/local/bin/exa
2734920 Feb 11 15:04 /home/odroid/exa-20160211
Hmmm, I'm not sure. I've been adding more and more libraries to exa, and some of them (zoneinfo-data, for example) can get pretty big. I need to make some of them optional again.
Thanks for the backtrace. It checks /etc/localtime
to try to determine the time zone; do you have this file?
Wait a minute, I thought I wrote that function to print out an error if it can't figure out which time zone to use, but I guess expect
doesn't print out the error case. Let me fix...
Yes, my system is set to local time but it seems the file contains some garbage! Probably the result of power outage and writeback
journalling.
OK, I make sure we print out the error (in ogham/exa@252eba484476369bb966fb1af7f739732b968fc0) when it can't determine what the time zone is.
The file in /etc/garbage
is a compiled binary file. exa tests if it's a symlink and tries to work out the time zone that way; otherwise, it tries to parse the file; otherwise, it fails with that error.
Ah, ok! Let me try the patch. I'll close if everything is fine again.
:+1:
What's the situation on the LFS front?
Large File Support? There's current a pull request for it that trades struct fields for accessors that should fix the file size problem.
Wow, a mere 16 hours ago ;)
Did you forget to push the updated crate to crates.io
? It looks like it.
Argh
Pushed. What are the odds I'll forget for the next version too? Place your bets now.
One in an i64
? ;)
I've managed to compile exa on ARM using rust
1.5
and--no-default-features
but first had to fix this by casting toi64
:only to find
-l
option doesn't work:Is it related or maybe
1.5
is already too old?