Commit Graph

14 Commits

Author SHA1 Message Date
krant c2362f3407 graphicsmagick: update to 1.3.43
- Set project URL to HTTP since HTTPS one is broken

Signed-off-by: krant <aleksey.vasilenko@gmail.com>
2024-04-08 13:26:27 -07:00
krant 39bf78decc graphicsmagick: update to 1.3.42
- Adopt the package

Signed-off-by: krant <aleksey.vasilenko@gmail.com>
2024-02-04 16:22:28 -08:00
Andre Heider e7d9c86503 treewide: refactor to use PKG_BUILD_FLAGS:=lto
See commit 07730ff3 "treewide: add support for "lto" in PKG_BUILD_FLAGS"
on the main repository.

Note: Some packages only added `-flto` to CFLAGS and not LDFLAGS. This
fixes it and properly enables LTO.

Signed-off-by: Andre Heider <a.heider@gmail.com>
2023-04-08 08:38:54 +02:00
Tony Butler a2effac262 graphicsmagick: refresh GCC options in Makefile
this Makefile still used `CONFIG_GCC_USE_VERSION_*` to select various
compilation options, for GCC versions that are antiquated

convert to parsing the major from the `CONFIG_GCC_VERSION` which will
always exist and can also be used with range logic

intent seemed to be:
* `-flto` for "not =10" (or newer, probably)
* no additional options for "=10" (and newer, probably)

GCC 11 or 12 would likely revert to the default (not =10) option,
because 10 was the newest at the time, and 11 and 12 are "not 10"

unsure of what actually works, perhaps `-flto` works in all versions by
now (possibly early gcc 10 bug workaround?)

GCC 11 will have been using `-flto` anyway by the current logic and I
guess it must be working or there would have been changes

Signed-off-by: Tony Butler <spudz76@gmail.com>
2022-12-22 18:11:51 -08:00
Rosen Penev 0e8b0b3163
graphicsmagick: fix compilation with GCC 10
Same fix as in imagemagick.

Signed-off-by: Rosen Penev <rosenp@gmail.com>
2020-11-30 17:57:02 -08:00
Robert Högberg 2fa91f4c9f graphicsmagick: Fix package description typo
Signed-off-by: Robert Högberg <robert.hogberg@gmail.com>
2020-11-28 09:07:20 +02:00
Rosen Penev 5a44d367d5
graphicsmagick: fix old CONFIG_DEPEND
Signed-off-by: Rosen Penev <rosenp@gmail.com>
2020-08-02 00:43:44 -07:00
Jan Pavlinec 171993f5a5
graphicsmagic: update to version 1.3.35 (security fix)
Signed-off-by: Jan Pavlinec <jan.pavlinec@nic.cz>
2020-04-01 13:18:47 +02:00
Val Kulkov c8c3b8fe7f graphicsmagick: update to the latest release
Update to v1.3.34. This service release provides a number of bug
fixes, including security fixes.

Signed-off-by: Val Kulkov <val.kulkov@gmail.com>
2020-02-04 19:49:28 -05:00
Jan Pavlinec 299e5b0a9b
treewide: add PKG_CPE_ID for better cvescanner coverage
Signed-off-by: Jan Pavlinec <jan.pavlinec@nic.cz>
2019-09-17 12:40:26 +02:00
Val Kulkov c7e8c2aa12 graphicsmagick: update to the latest release
Update to v1.3.33, the latest official release. This release is the
product of significant bug and security fixes due to GraphicsMagick
participating in Google's oss-fuzz project.  This release fixes 7
issues detected by oss-fuzz as well as a number of issues reported
via the SourceForge bug tracker, or discovered via testing.

Signed-off-by: Val Kulkov <val.kulkov@gmail.com>
2019-08-05 15:13:55 -04:00
Val Kulkov 97b7a56e31 graphicsmagick: update to the latest upstream version
Update to 1.3.32.

Signed-off-by: Val Kulkov <val.kulkov@gmail.com>
2019-06-16 22:56:01 -04:00
Val Kulkov 1dcde6a107 graphicsmagick: optimize compilation
Use 'flto' compiler option to slightly reduce the installation
footprint.

Signed-off-by: Val Kulkov <val.kulkov@gmail.com>
2019-02-10 15:22:43 -05:00
Val Kulkov 55076b5bfc graphicsmagick: new package, an imagemagick alternative
GraphicsMagick is a fork of ImageMagick, licensed under the MIT license.
It requires less space and it is [reportedly] faster than ImageMagick.

GraphicsMagick's installation footprint is:

x86_64: 4.3 MB, and
brcm47xx-mips74k (mipsel_74kc): 3.7 MB.

The shared libraries occupy 2.2 MB (mipsel_74kc). The 90 GraphicsMagick's
modules occupy 2.5 MB. It may be possible to reduce the installation
footprint by introducing build parameters to control the selection of
modules. In view of the large number of modules and the possibility of
breakage due to module interdependencies or other reasons, such attempt
is not made at this time.

Signed-off-by: Val Kulkov <val.kulkov@gmail.com>
2019-01-25 18:35:17 -05:00