gnperumal / gource

Automatically exported from code.google.com/p/gource
0 stars 0 forks source link

configure checks for jpeg and png libs #57

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
While i was bumping gource 0.26 for gentoo i notified that gource doesn't
link to either libjpeg or libpng (and with a quick look i can't find code
using it), but still configure checks for them. Indeed those are indirect
deps inherited from sdl-image, but still you can't be sure sdl-image is
compiled with lib{png,jpeg} support checking if those libs are installed.
Additionally as far as i know there is no way to check that sdl-image was
compiled with such support (this might be notified to sdl upstream may be?).

So may i suggest to drop those not usefull (at least for what i understand
of course) checks and add a note to the INSTALL file to compile sdl-image
with jpeg and png support?

I know this is just cosmetic, but well i'm a perfectionist :)

Original issue reported on code.google.com by enrico.t...@gmail.com on 17 Mar 2010 at 12:49

GoogleCodeExporter commented 9 years ago
I believe sdl-image dynamically loads those libs if they're available. The 
check in
configure is to ensure Gource will actually work since otherwise sdl-image 
can't load
jpegs and pngs.

This appears to stop it from adding them to the LIBS line (by adding an 
action-if-found):

#PNG library
AC_CHECK_LIB(png, png_read_info, [ has_libpng=1 ], AC_MSG_ERROR([PNG library
required. Please see README]))

#JPEG library
AC_CHECK_LIB(jpeg, jpeg_read_header, [ has_libjpg=1 ], AC_MSG_ERROR([JPEG 
library
required. Please see README]))

Does that fix your warning?

Original comment by acaudw...@gmail.com on 17 Mar 2010 at 9:45

GoogleCodeExporter commented 9 years ago
Maybe it would be better if Gource makes some innocuous use of those libraries 
so the
warning goes away, but it still linked to libpng and libjpeg so that people 
don't
accidentally package Gource without those libraries?

Original comment by acaudw...@gmail.com on 17 Mar 2010 at 9:52

GoogleCodeExporter commented 9 years ago
The dynamic linking of sdl-image is not so simple. For example some times ago i
updated jpeg from version 7 to version 8. The output of scanelf -n of the 
sdl-image
bins were correct, but trying to use it was resulting in failing to load 
libjpeg.so.7
(indeed i update to version 8), so a recompile of sdl-image was needed. But I'm 
not
so skilled to understand what happened that time, but all gentoo tools to check
dynamic linking of sdl-image were reporting no problems (and this is strange 
they
never failed in my expirience).

Anyway the problem is not the dynamic linking. When you compile sdl-image you 
can
forcibly disable the jpeg,png support passing some argument to the configure 
script
when compiling sdl-image. I know this normally not happen, but it could in 
theory. So
just checking that libpng and libjpeg are installed doesn't assure sdl-image 
will
work with jpeg and png. That's why i say that check is useless. The correct way 
would
be to check how sdl-image is compiled, but this is not possible at the moment 
(and
you may ask upstream if i'm wrong of course).

And finally i have no warning about that by the gentoo package manager, i just 
spot
it with my own eyes. Making some "innocuous use of those libraries" is just a 
way to
make that check needed (couse you will actually use those libraries in this 
way), but
doesn't solves the problem of sdl-image support for jpeg and png.

This problem applies normally only on source based distros or when a user 
recompile
sdl-image by himself, since on binary distro sdl-image is compiled with jpeg 
and png
support for obvious reason, so just checking that sdl-image is installed will 
assure
the presence of jpeg and png libs since they are required by sdl-image in such 
a case.

Original comment by enrico.t...@gmail.com on 17 Mar 2010 at 10:41

GoogleCodeExporter commented 9 years ago

Original comment by acaudw...@gmail.com on 18 Mar 2010 at 6:37