Alexander E. Patrakov wrote:
DJ Lucas wrote:
Hopefully this is a little more informative than 'This didn't work but
this did." :-) Does anyone have any additional concerns or objections?
Yes. Benchmarks (time unzip -t bigfile.zip >/dev/null). They show that,
due to non-use of PIC code and zlib, the "linux" target is fully
functional and faster than other fully-functional targets.
Well, zlib is already out of the equasion. I suppose the next logical
question is: What does the shared libunzip bring to the table? More
importantly, in my own ignorance, how exactly can one use the shared
library without a header file to describe it? I can't believe I hadn't
noticed that before. I agree with Alexander's suggestion. Any
additional concerns?
The other question still stands. Should I bug zlib developers about
these files that it can't handle? It does hinder operation of other
projects that use zlib (python's zip modules).
Also, Alexander, while I've got your attention. I'm not sure
'fully-functional' is a correct term WRT the UTF8 issues. I'm
attempting to travel that path now with en_US.UTF-8. Only way to learn
is to dive right in! :-) On my previous build (not utf8), I had found
several files created with a .Net application that I couldn't do
operations on using the list of files in vim. Certain apostrophy
characters (') displayed as blocks. If I understand the issue
correctly, the filenames are the only problem for me in en_US as unzip
will correctly change the extracted filenames. Being real green WRT
UTF8 issues, is my 'understanding' of the locale issue concerning unzip
correct?
-- DJ Lucas
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
