Description of problem: When I was looking for libjpeg.a, according to `rpm -ql libjpeg-devel`, this package should have the static lib file. However, it does not! I also did a search with `yum search jpeg`. It didn't return me anything related to jpeg static lib. Looking at other libraries, such as libpng-devel, I am quite convinced that libjpeg-devel is missing the static lib file. Version-Release number of selected component (if applicable): Ver.6b Rel.37 How reproducible: Both i386 and x86_64 platforms. should be on every machine. Steps to Reproduce: 1. rpm -qi libjpeg-devel (this shows the package info, stating static lib is included.) 2. rpm -ql libjpeg-devel | grep libjpeg.a Actual results: [nothing] Expected results: /usr/lib/libjpeg.a Additional info:
I noticed this too. Temporary fix is to download libjpeg from ijg.org, build it under your fedora core 6 system, and thence, rather than installing the resulting build, copy the libjpeg.a file from the build area into /usr/lib. The source version of libjpeg available at ijg.org is identical to that in FC6. This will work for i386 systems. I guess that if you clean that build and remake after defining CC as gcc -m64, the resulting libjpeg.a can be placed in /usr/lib64 on an x86_64 system. This problem appears to be present for libtiff as well.
Created attachment 145725 [details] Spec file including static libraries
The libjpeg static libraries are required to build splashy
Um, it's not that I'm unaware of how to build a static libjpeg ;-). The issue here is that there's a Fedora/RHEL policy against shipping static libraries without darn good reason. I agree with that policy in general: when there's a bug found in a library, it is simple to issue an update if all applications link to a shared version of the library. But any application that has a statically linked copy of the library is broken until it gets rebuilt --- by hand. In the case of security updates, that is *really* bad ... and while libjpeg has a good track record itself, image libraries in general are under constant scrutiny for security bugs. So the question here is why exactly we should make an exception for libjpeg. I'm not impressed by arguments that "foo needs it" --- the counterargument is that foo should be fixed to not depend on static linking. What technical argument can I make that libjpeg deserves an exception to the policy? (See also bug #186060 which is the same issue filed against fc5)
Thank you for the excellent review and kudoos to the process in place that assures a high level of quality for Fedora. Following your message I went on the splashy-devel mailing list and ask them to provide some good reasons for static linking. As it turns out, the upcoming 0.3 splashy will not require static linking anymore so I guess Fedora won't get poluted by a static lib this time arround :)
libjpeg-static package created as of libjpeg-6b-38. Pushed to F7 testing today, will backpatch as opportunity presents.
libjpeg-6b-38.fc7 has been pushed to the Fedora 7 testing repository. If problems still persist, please make note of it in this bug report.
libjpeg-6b-38.fc7 has been pushed to the Fedora 7 stable repository. If problems still persist, please make note of it in this bug report.