Alok Aggarwal wrote: > > On Fri, 14 Dec 2007, Mike Riley wrote: > >> Pardon my ignorance, but why are you doing this? Lot's of >> applications are delivered in packages other than where libraries they >> use are located. > > From the bug report: > > The putback for 6618343 resulted in the lofiadm(1M) including zlib.h in > order to compress a file. It turns out that lofiadm is included in the > SUNWcsu whereas zlib (and zlib.h) is delivered as part of SUNWzlib. This > can cause problems if lofiadm is used to compress a file on a system > that doesn't have SUNWzlib installed. > > So, in other words if libz isn't installed on the system > the command will simply be killed with a rather unpleasant > error. > >> What your change does here is move the code that resolves the symbol >> to access the library into the application itself, when Solaris would >> have done that for you. Also, you have now created a hard dependency >> on libz.so.1 being in /usr/lib, as well as being named libz.so.1, >> where previously the Makefile handled the name and Solaris found where >> it was located for you. > > Let me turn that around, how is this dependancy > better or worse than <libz.h> being in /usr/include? > And libz.h being named libz and not something else > in the future? > > Both are public ARC'd interfaces (although I can't > find their stability levels at the moment), their > consumers will break the moment you start moving/renaming them. > >> In the gzip_compress() function you call die() if you can't locate the >> symbol compress2() in the library, or if you can't find the library. >> I fail to see how that is different from Solaris reporting the same >> info and not running the program, unless it is that this routine is >> never invoked unless compression is requested, in which case an >> uncompressed volume would never see this error using your new code. > > The behavior is very different. > > Without this fix, lofiadm will die whether or not you > requested compression or not with the following error > message - > > ld.so.1: lofiadm: fatal: libz.so.1: open failed: No such file or directory > zsh: killed lofiadm > > With this fix, lofiadm will error out only if compression is requested > with the following error message - > > lofiadm: error locating /usr/lib/libz.so.1: No such file or directory > > I will let you decide which behavior you would rather see.
I figured that was the case. Just wanted to confirm it. >> In a separate issue: >> >> Looking at the code I see that gzip_compress() is used in a table: >> lofi_compress_table >> >> The only place that is ever called is line 610: >> 610 (void) li->l_compress(uncompressed_seg, rbytes, >> 611 compressed_seg + SEGHDR, &real_segsize, li->l_level); >> >> In gzip_compress() you are also returning either -1 or 0, depending on >> what calling calling compress2() via compress2p returns. Yet in line >> 610 you are throwing that result away. So the purpose of returning a >> 0 or -1 here is??? > > l_compress and l_decompress are both defined as lofi_compress_func_t's > which returns an int. > One decides to look at the return value whereas the other throws it > away. So, returning an int > is there for consistency. It just seems strange to see different return values being used when you know they are going to be ignored. Mike
