SFML community forums
Help => Graphics => Topic started by: Svenstaro on April 04, 2010, 12:37:36 am
-
In a recent attempt to use ImageMagick in conjunction with SFML I literally spent hours tracing down a bug that I do not want other users to stumble into.
SFML currently provides its own versions of libpng and libjpeg directly in its source tree. That in itself isn't a huge problem but when you link a library that has a different version of libpng there will be trouble along the lines of: terminate called after throwing an instance of
'Magick::ErrorResourceLimit'
what(): Magick: memory allocation failed `test.png' @ error/png.c/WriteOnePNGImage/6433
Aborted
It may look like an ImageMagick bug but it is actually a libpng API mismatch since ImageMagick builds in libpng 1.4 and SFML still uses libpng 1.2. A similar conflict can be observed with libjpeg.
A quick fix to this is to update those outdated libs now (SOIL probably as well) and in the long run give distro packagers a make target for using system-available packages.
Windows users probably don't care to have the versions of the external libs match up with their system installed ones as most people will not install those system wide. Windows users will still benefit from updated libpng and libjpeg versions.
-
I made you a patch: http://omploader.org/vNDFnYw
Apply it in SFML-1.5/ (version doesn't matter as the libpng and libjpeg versions didn't change even in SFML 2.0) using patch -Np1 < sfml-libjpeg-libpng-update.patch
-
give distro packagers a make target for using system-available packages.
Even better: instead of integrating their source code directly into SFML, I should compile them as static libs on Windows, and always use the system packages on Linux.
This is probably something that I'll do for SFML 2.
-
Any chance for that in SFML 1.6? At least an update of those libs would do for now.
-
SFML 1.6 is already packaged, sorry.
-
Thank your for your quick acting on the SFML2 branch to resolve this. I will backport the changes to SFML1 and use them as a patch for the Arch Linux SFML package. Will the changes hit SFML1 trunk at some point or will they remain in SFML2 only?
SFML1.6 is going to be the last SFML1 release, right?
-
Will the changes hit SFML1 trunk at some point or will they remain in SFML2 only?
Nop, The SFML 1.x branch will only be maintained for bug fixes. Now all the "new stuff" will be part of SFML 2.
SFML1.6 is going to be the last SFML1 release, right?
I really hope so :)
-
For the record, this is my backported patch: http://aur.archlinux.org/packages/sfml/sfml/use-system-libs.patch