| Message ID | 1448410510-23087-1-git-send-email-sergio.prado@e-labworks.com |
|---|---|
| State | Accepted |
| Headers | show |
Dear Sergio Prado, On Tue, 24 Nov 2015 22:15:10 -0200, Sergio Prado wrote: > Libgdiplus is an open source implementation of the GDI+ API. > > Signed-off-by: Sergio Prado <sergio.prado@e-labworks.com> > --- > Changes v2 -> v3: > - removing md5 hash > - adding a comment explaining the source code license There were a few remaining trailing whitespaces. It would be good if you could tune your text editor configuration so that you can clearly see the trailing whitespaces. Other than that, I couldn't spot any issue, so I applied. Don't hesitate to monitor http://autobuild.buildroot.org and/or the daily autobuild report e-mails to see if there are any libgdiplus related failures. Thanks! Thomas
Hi Thomas, 2015-12-17 19:29 GMT-02:00 Thomas Petazzoni < thomas.petazzoni@free-electrons.com>: > Dear Sergio Prado, > > On Tue, 24 Nov 2015 22:15:10 -0200, Sergio Prado wrote: > > Libgdiplus is an open source implementation of the GDI+ API. > > > > Signed-off-by: Sergio Prado <sergio.prado@e-labworks.com> > > --- > > Changes v2 -> v3: > > - removing md5 hash > > - adding a comment explaining the source code license > > There were a few remaining trailing whitespaces. It would be good if > you could tune your text editor configuration so that you can clearly > see the trailing whitespaces. > OK, I did not notice that. I'll tune my text editor. > > Other than that, I couldn't spot any issue, so I applied. Don't > hesitate to monitor http://autobuild.buildroot.org and/or the daily > autobuild report e-mails to see if there are any libgdiplus related > failures. > OK. I'll do that. > > Thanks! > Thanks! > > Thomas > -- > Thomas Petazzoni, CTO, Free Electrons > Embedded Linux, Kernel and Android engineering > http://free-electrons.com >
Hello, On Thu, 17 Dec 2015 22:29:52 +0100, Thomas Petazzoni wrote: > Other than that, I couldn't spot any issue, so I applied. Don't > hesitate to monitor http://autobuild.buildroot.org and/or the daily > autobuild report e-mails to see if there are any libgdiplus related > failures. There are some build issues: http://autobuild.buildroot.org/?reason=libgdiplus-3.12 There is a -L/lib somewhere which is wrong. Could you have a look? Thanks a lot! Thomas
Hi Thomas, 2015-12-18 8:41 GMT-02:00 Thomas Petazzoni < thomas.petazzoni@free-electrons.com>: > Hello, > > On Thu, 17 Dec 2015 22:29:52 +0100, Thomas Petazzoni wrote: > > > Other than that, I couldn't spot any issue, so I applied. Don't > > hesitate to monitor http://autobuild.buildroot.org and/or the daily > > autobuild report e-mails to see if there are any libgdiplus related > > failures. > > There are some build issues: > > http://autobuild.buildroot.org/?reason=libgdiplus-3.12 > > There is a -L/lib somewhere which is wrong. Could you have a look? > Sure, I'll take a look. > > Thanks a lot! > > Thomas > -- > Thomas Petazzoni, CTO, Free Electrons > Embedded Linux, Kernel and Android engineering > http://free-electrons.com >
Hello Thomas, There was an error in the configure script that was not generating ldflags correctly, and the generated Makefile was trying to link with -L/lib. I have sent a patch to fix it, and there is already a patch to fix it upstream. The reason I did not catch this problem was because the toolchains I used to test generated a warning instead of an error: Beaglebone with uclibc arm-buildroot-linux-uclibcgnueabihf-gcc: WARNING: unsafe header/library path used in cross-compilation: '/lib' Qemu x86 with glibc i686-buildroot-linux-gnu-gcc: WARNING: unsafe header/library path used in cross-compilation: '/lib' Why some toolchains generate an error and others a warning in this situation? Is there a configuration to enable this check when generating the toolchain? Sergio Prado Embedded Labworks Office: +55 11 2628-3461 Mobile: +55 11 97123-3420 2015-12-18 8:56 GMT-02:00 Sergio Prado <sergio.prado@e-labworks.com>: > Hi Thomas, > > 2015-12-18 8:41 GMT-02:00 Thomas Petazzoni < > thomas.petazzoni@free-electrons.com>: > >> Hello, >> >> On Thu, 17 Dec 2015 22:29:52 +0100, Thomas Petazzoni wrote: >> >> > Other than that, I couldn't spot any issue, so I applied. Don't >> > hesitate to monitor http://autobuild.buildroot.org and/or the daily >> > autobuild report e-mails to see if there are any libgdiplus related >> > failures. >> >> There are some build issues: >> >> http://autobuild.buildroot.org/?reason=libgdiplus-3.12 >> >> There is a -L/lib somewhere which is wrong. Could you have a look? >> > > Sure, I'll take a look. > > >> >> Thanks a lot! >> >> Thomas >> -- >> Thomas Petazzoni, CTO, Free Electrons >> Embedded Linux, Kernel and Android engineering >> http://free-electrons.com >> > >
Dear Sergio Prado, On Fri, 18 Dec 2015 16:12:57 -0200, Sergio Prado wrote: > Beaglebone with uclibc > arm-buildroot-linux-uclibcgnueabihf-gcc: WARNING: unsafe header/library > path used in cross-compilation: '/lib' > > Qemu x86 with glibc > i686-buildroot-linux-gnu-gcc: WARNING: unsafe header/library path used in > cross-compilation: '/lib' > > Why some toolchains generate an error and others a warning in this > situation? Is there a configuration to enable this check when generating > the toolchain? It is not a matter of toolchain, it is a matter of whether you set the option BR2_COMPILER_PARANOID_UNSAFE_PATH=y or not. By default it's disabled, so those unsafe path messages are just warnings. In the autobuilders, we turn this option on by default, so that just unsafe path messages are treated as errors and abort the build. This option simply sets an environment variable that makes the toolchain wrapper error out when such unsafe paths are detected. Best regards, Thomas
2015-12-18 17:04 GMT-02:00 Thomas Petazzoni < thomas.petazzoni@free-electrons.com>: > Dear Sergio Prado, > > On Fri, 18 Dec 2015 16:12:57 -0200, Sergio Prado wrote: > > > Beaglebone with uclibc > > arm-buildroot-linux-uclibcgnueabihf-gcc: WARNING: unsafe header/library > > path used in cross-compilation: '/lib' > > > > Qemu x86 with glibc > > i686-buildroot-linux-gnu-gcc: WARNING: unsafe header/library path used in > > cross-compilation: '/lib' > > > > Why some toolchains generate an error and others a warning in this > > situation? Is there a configuration to enable this check when generating > > the toolchain? > > It is not a matter of toolchain, it is a matter of whether you set the > option BR2_COMPILER_PARANOID_UNSAFE_PATH=y or not. By default it's > disabled, so those unsafe path messages are just warnings. In the > autobuilders, we turn this option on by default, so that just unsafe > path messages are treated as errors and abort the build. > > This option simply sets an environment variable that makes the > toolchain wrapper error out when such unsafe paths are detected. > Did not know about this option. I will start testing new packages with this option enabled. > Best regards, > Thanks! > > Thomas > -- > Thomas Petazzoni, CTO, Free Electrons > Embedded Linux, Kernel and Android engineering > http://free-electrons.com >
diff --git a/package/Config.in b/package/Config.in index bdc3063abd1a..ef09361c5440 100644 --- a/package/Config.in +++ b/package/Config.in @@ -824,6 +824,7 @@ menu "Graphics" source "package/libfm-extra/Config.in" source "package/libfreeimage/Config.in" source "package/libgail/Config.in" + source "package/libgdiplus/Config.in" source "package/libgeotiff/Config.in" source "package/libglade/Config.in" source "package/libglew/Config.in" diff --git a/package/libgdiplus/Config.in b/package/libgdiplus/Config.in new file mode 100644 index 000000000000..f860ab339469 --- /dev/null +++ b/package/libgdiplus/Config.in @@ -0,0 +1,21 @@ +config BR2_PACKAGE_LIBGDIPLUS + bool "libgdiplus" + select BR2_PACKAGE_XLIB_LIBXFT + select BR2_PACKAGE_LIBGLIB2 + select BR2_PACKAGE_CAIRO + select BR2_PACKAGE_LIBPNG + depends on BR2_PACKAGE_XORG7 + depends on BR2_USE_WCHAR # libglib2 -> gettext + depends on BR2_TOOLCHAIN_HAS_THREADS # libglib2 + depends on BR2_USE_MMU # libglib2 + depends on BR2_ARCH_HAS_ATOMICS # cairo + help + An Open Source implementation of the GDI+ API. + + https://github.com/mono/libgdiplus + +comment "libgdiplus needs a toolchain w/ wchar, threads" + depends on BR2_USE_MMU + depends on BR2_ARCH_HAS_ATOMICS + depends on BR2_PACKAGE_XORG7 + depends on !BR2_USE_WCHAR || !BR2_TOOLCHAIN_HAS_THREADS diff --git a/package/libgdiplus/libgdiplus.hash b/package/libgdiplus/libgdiplus.hash new file mode 100644 index 000000000000..71ffdd346685 --- /dev/null +++ b/package/libgdiplus/libgdiplus.hash @@ -0,0 +1,2 @@ +# Locally computed: +sha256 7eadc5105c6352d456c5f8699dc89260bf402e82ce6668e7e0c625519f9e5b44 libgdiplus-3.12.tar.gz diff --git a/package/libgdiplus/libgdiplus.mk b/package/libgdiplus/libgdiplus.mk new file mode 100644 index 000000000000..9f96c972c561 --- /dev/null +++ b/package/libgdiplus/libgdiplus.mk @@ -0,0 +1,56 @@ +################################################################################ +# +# libgdiplus +# +################################################################################ + +LIBGDIPLUS_VERSION = 3.12 +LIBGDIPLUS_SITE = $(call github,mono,libgdiplus,$(LIBGDIPLUS_VERSION)) + +# Although there is a LICENSE file thas specifies LGPL or MPLv1.1, looks +# like it is incorrect. The actual source files specify that they're +# licensed under MIT, and so does the COPYING file (and they all predate +# the addition of the LICENSE file). +LIBGDIPLUS_LICENSE = MIT +LIBGDIPLUS_LICENSE_FILES = COPYING src/carbon-private.h + +LIBGDIPLUS_INSTALL_STAGING = YES + +# github tarball doesn't have configure +LIBGDIPLUS_AUTORECONF = YES + +LIBGDIPLUS_DEPENDENCIES = xlib_libXft libglib2 cairo libpng host-pkgconf + +# API changes in recent versions of libgif makes it incompatible with +# this version of libgdiplus, so we are disabling it for now. +LIBGDIPLUS_CONF_OPTS = --without-libgif + +# there is a bug in the configure script that enables pango support when +# passing --without-pango, so let's just not use it +ifeq ($(BR2_PACKAGE_PANGO),y) +LIBGDIPLUS_CONF_OPTS += --with-pango +LIBGDIPLUS_DEPENDENCIES += pango +endif + +ifeq ($(BR2_PACKAGE_LIBEXIF),y) +LIBGDIPLUS_CONF_OPTS += --with-libexif +LIBGDIPLUS_DEPENDENCIES += libexif +else +LIBGDIPLUS_CONF_OPTS += --without-libexif +endif + +ifeq ($(BR2_PACKAGE_JPEG),y) +LIBGDIPLUS_CONF_OPTS += --with-libjpeg +LIBGDIPLUS_DEPENDENCIES += jpeg +else +LIBGDIPLUS_CONF_OPTS += --without-libjpeg +endif + +ifeq ($(BR2_PACKAGE_TIFF),y) +LIBGDIPLUS_CONF_OPTS += --with-libtiff +LIBGDIPLUS_DEPENDENCIES += tiff +else +LIBGDIPLUS_CONF_OPTS += --without-libtiff +endif + +$(eval $(autotools-package))
Libgdiplus is an open source implementation of the GDI+ API. Signed-off-by: Sergio Prado <sergio.prado@e-labworks.com> --- Changes v2 -> v3: - removing md5 hash - adding a comment explaining the source code license Changes v1 -> v2: - because of libglib2, package depends on BR2_USE_WCHAR, BR2_TOOLCHAIN_HAS_THREADS and BR2_USE_MMU - because of cairo, package depends on BR2_PACKAGE_CAIRO - adding hashes - fixing license to MIT - adding a comment explaining why we need to enable autoreconf - adding a dependency on package host-pkgconf - adding a comment explaining why we cannot use --without-pango --- package/Config.in | 1 + package/libgdiplus/Config.in | 21 ++++++++++++++ package/libgdiplus/libgdiplus.hash | 2 ++ package/libgdiplus/libgdiplus.mk | 56 ++++++++++++++++++++++++++++++++++++++ 4 files changed, 80 insertions(+) create mode 100644 package/libgdiplus/Config.in create mode 100644 package/libgdiplus/libgdiplus.hash create mode 100644 package/libgdiplus/libgdiplus.mk