hplip-3.{9,10}, blob lj-x86_32.so dynamically resolves its "statically" linked symbols

[friday]

Some blobs internal static libraries are not actually linked staticaly so its symbols being dynamically resolved along all libraries linked or loaded with the blob and its caller which cause usage by the blob libraries with imcompatible API/ABI.

Particularly, blob has built-in library jbigkit version about 1.6 and it interfere with a system library with the same name (i.e. libjbig.so). The bug arise when that system jbigkit library is version of 2.0 which is binary not compatible with 1.x. This cause stack corruption in lj-x86_32.so and segfaults in hpcups.

Possible reproduction steps:
1. 32bit GNU/Linux OS.
2. Recent libraries jbigkit 2.x and libtiff 4.x build with jbig support (i.e. linked against system libjbig.so).
3. Blob lj-x86_32.so (mine has md5 sum 30bdf8c844508a53d80362f9eba670c5)
4. hpcups linked with that libtiff library.
5. Some execution of hpcups going through prnt/hpcups/ModeJbig.cpp:330 (for example, on printing with HP LaserJet p1006)

Expected results:
1. Function hp_encode_bits_to_jbig() uses symbol jbg_enc_init() which resolved and linked with system libjbig.so version 2.0 instead of built-in code.
2. jbg_enc_init() from sysyem library libjbig.so corrupts stack frame of hp_encode_bits_to_jbig() in blob erasing saved value of %ebx register of caller (jbg_enc_state structure in new version has some extra fields).
3. Just after call HPLJJBGCompress() at prnt/hpcups/ModeJbig.cpp:330 %ebx register not restored and set to zero.
4. Depending on compiler options (usually optimization needed, i.e. -O1 or -O2 for gcc) this could cause segfault later in the hpcups.

[friday (b3nder)]

Workarounds: add new entry in .dynamic section with value DT_SYMBOLIC (0x10)
 of the lj-x86_32.so, which directs linker to use self symbols first while resolution. For library with the given above md5 sum it is sufficient to write one byte 0x10 at file offset 0xA068.

[Arkadiusz Miśkiewicz (arekm)]

There is a patch for your solution (since seems that HP team doesn't plan to fix these binary plugins).