Tiny Core Extensions > TCE 2.x
libjpeg
tobiaus:
--- Quote from: ^thehatsrule^ on May 11, 2009, 07:14:28 PM ---Do they overwrite base libs? I think it's good practice to not do so, esp. when not needed.
--- End quote ---
thank you, i wondered the same. i don't think it's good practice to have extensions that (unnecessarily) compromise the base... i didn't even think it was possible to have extensions compromise the base, but there is tce and tcz and last i heard/misheard, one does overwrite and the other doesn't. EDIT: although obviously our concern here is misplaced, that's nice.
jpeters:
--- Quote from: ^thehatsrule^ on May 11, 2009, 07:14:28 PM ---Do they overwrite base libs? I think it's good practice to not do so, esp. when not needed.
--- End quote ---
Of course not...it's written to /usr/local/lib
jpeters:
I looked into this issue a bit.
1. this was compiled into /usr/local, so there's no conflict with base anything.
2. it was compiled with --enable-static and --enable-shared, so base libjpeg.so.62.0.0 is not same (despite the same name) The compiled is 543 lines vs base 251 lines.
3. the compiled libjpeg.so.la clearly states where the compiled libs have to be located, in this case /usr/local/lib.
4. the compiled libs support jpeg functions not included in base. Briefly they include:
djpeg:
decompresses image files from JPEG/JFIF format to either PPM (PBMPLUS color format), PGM (PBMPLUS gray-scale format), BMP, or Targa format.
jpegtran:
is used for lossless transformation of JPEG files.
rdjpgcom:
displays text comments from within a JPEG file.wrjpgcom
wrjpgcom:
inserts text comments into a JPEG file.
5. On complaints about including docs,"bloat",etc. The docs in man1 are --help files, 4K a piece for each of the above commands.
When you type "djpeg --help", for example, it lists all the switches and usage:
--- Code: ---usage: djpeg [switches] [inputfile]
Switches (names may be abbreviated):
-colors N Reduce image to no more than N colors
-fast Fast, low-quality processing
-grayscale Force grayscale output
-scale M/N Scale output image by fraction M/N, eg, 1/8
-bmp Select BMP output format (Windows style)
-gif Select GIF output format
-os2 Select BMP output format (OS/2 style)
-pnm Select PBMPLUS (PPM/PGM) output format (default)
-targa Select Targa output format
Switches for advanced users:
-dct int Use integer DCT method (default)
-dct fast Use fast integer DCT (less accurate)
-dct float Use floating-point DCT method
-dither fs Use F-S dithering (default)
-dither none Don't use dithering in quantization
-dither ordered Use ordered dither (medium speed, quality)
-map FILE Map to colors used in named image file
-nosmooth Don't use high-quality upsampling
-onepass Use 1-pass quantization (fast, low quality)
-maxmemory N Maximum memory to use (in kbytes)
-outfile name Specify name for output file
--- End code ---
This package is from BLFS, and configured according to their recommendations. The descriptions are copied from the BLFS book. I have no problem with including/not including/removing the manuals/removing the libs/ etc, etc. The license is free...people can do whatever they like to suit their own purposes.
note: As noted above, I only submitted this because I was too stupid to grep the correct lib name, so thought it wasn't in base. I've got a growing directory full of these extensions for my own use....all with manuals, since I need all the help I can get :)
^thehatsrule^:
1-2. Note that .so files are shared/dynamic libraries. What lines are you talking about? If you meant size differences, it would probably be due to the compiler/optimizer flags, etc.
Essentially, this would create some redundancy in having 2 of the same libs. Also, the loader will probably use /usr/lib first.. In this case the base library will always be used by default.
4. Afaik those are userland tools, so they can probably be used with the base library as well.
5. If the docs are large, they can be separated into another extension or always separated to keep things more modularized - but (so far) that decision is left to the maintainer.
jpeters:
--- Quote from: ^thehatsrule^ on May 12, 2009, 02:24:54 AM ---1-2. Note that .so files are shared/dynamic libraries. What lines are you talking about? If you meant size differences, it would probably be due to the compiler/optimizer flags, etc.
--- End quote ---
---looks like more than optimizer flags. For lines, I compared "vim /libjpeg.so.62.0.0.
--- Quote ---Essentially, this would create some redundancy in having 2 of the same libs. Also, the loader will probably use /usr/lib first.. In this case the base library will always be used by default.
--- End quote ---
That's my understanding also. Without the extension, base is used. With the extension /usr/local is used.
--- Quote ---4. Afaik those are userland tools, so they can probably be used with the base library as well.
--- End quote ---
The switches build both static and shared libraries, as recommended by BLFS. I think I compiled once without switches, and it produced the apps without the libs....so that might be a possibility. I'd like to be convinced the base libs have the same functionality, however. When things don't work, it's hard to trace it back to the 5k squeezed from wherever in the base.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version