Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 921601

Summary: x11-wm/fvwm-2.7.0-r4 fails to compile (GCC-14-SYSTEM): PictureImageLoader.c:482:13: error: implicit declaration of function png_get_color_type [-Wimplicit-function-declaration]
Product: Gentoo Linux Reporter: Agostino Sarubbo <ago>
Component: Current packagesAssignee: No maintainer - Look at https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers if you want to take care of it <maintainer-needed>
Status: CONFIRMED ---    
Severity: normal CC: brahmajit.xyz, eschwartz93
Priority: Normal Keywords: PullRequest
Version: unspecified   
Hardware: All   
OS: Linux   
See Also: https://github.com/gentoo/gentoo/pull/36676
Whiteboard:
Package list:
Runtime testing required: ---
Bug Depends on:    
Bug Blocks: 870412    
Attachments: build.log

Description Agostino Sarubbo gentoo-dev 2024-01-08 08:26:53 UTC
https://blogs.gentoo.org/ago/2020/07/04/gentoo-tinderbox/

Issue: x11-wm/fvwm-2.7.0-r2 fails to compile (GCC-14-SYSTEM).
Discovered on: amd64 (internal ref: gcc14_tinderbox)

NOTE:
(GCC-14-SYSTEM) in the summary means that the bug was found on a machine that runs gcc-14 but this bug MAY or MAY NOT BE related to the new compiler
Comment 1 Agostino Sarubbo gentoo-dev 2024-01-08 08:26:55 UTC
Created attachment 881669 [details]
build.log

build log and emerge --info
Comment 2 Agostino Sarubbo gentoo-dev 2024-05-06 06:51:10 UTC
gcc14_tinderbox has reproduced this issue with version 2.7.0-r4 - Updating summary.
Comment 3 Eli Schwartz 2024-05-16 05:17:31 UTC
This only occurs when USE=png is disabled.

In /var/tmp/portage/x11-wm/fvwm-2.7.0-r4/work/fvwm-2.7.0/libs/Fpng.h

There is a fair amount of code to abstract away png support using glorious technology such as:

#if PngSupport
typedef png_uint_32 Fpng_uint_32;
#define Fpng_destroy_read_struct(a,b,c) png_destroy_read_struct(a,b,c)
#else
typedef unsigned long Fpng_uint_32;
#define Fpng_destroy_read_struct(a,b,c)
#endif


It also exposes png.h to consumers of Fpng.h.

In /var/tmp/portage/x11-wm/fvwm-2.7.0-r4/work/fvwm-2.7.0/libs/PictureImageLoader.c

static Bool PImageLoadPng(FIMAGE_CMD_ARGS)
{ 
        if (!PngSupport)
        {
                return False;
        }
[...]


And later on in the function, it uses various typedef'ed Fpng* typedefs and defines, but also uses, unconditionally,

png_get_color_type(Fpng_ptr, Finfo_ptr)

no define to hide it.

I personally think the entire thing is silly and standard technology here is to ifdef out the entire function to a stub.

Note: the linked PR is broken. It unconditionally depends on png.h which is quite missing the point. We can just as easily remove the USE flag and unconditionally enable png support.
Comment 4 Brahmajit Das 2024-05-16 11:29:31 UTC
Eli, does something like this look alright to you? I reason that since PNG support is not enabled, we shouldn't be needing this. 

diff --git a/libs/PictureImageLoader.c b/libs/PictureImageLoader.c
index c615081..0a91400 100644
--- a/libs/PictureImageLoader.c
+++ b/libs/PictureImageLoader.c
@@ -468,6 +468,7 @@ Bool PImageLoadPng(FIMAGE_CMD_ARGS)
 		Fpng_set_expand(Fpng_ptr);
 	}
 
+#if PngSupport
 	/* TA:  XXX:  (2011-02-14) -- Happy Valentines Day.
 	 *
 	 * png_get_color_type() defined in libpng 1.5 now hides a data member
@@ -492,6 +493,7 @@ Bool PImageLoadPng(FIMAGE_CMD_ARGS)
 	{
 		hasg = 1;
 	}
+#endif
 
 	if (hasa)
 		Fpng_set_expand(Fpng_ptr);