Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 921601 - 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]
Summary: x11-wm/fvwm-2.7.0-r4 fails to compile (GCC-14-SYSTEM): PictureImageLoader.c:4...
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: No maintainer - Look at https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers if you want to take care of it
URL:
Whiteboard:
Keywords: PullRequest
Depends on:
Blocks: c99-porting
  Show dependency tree
 
Reported: 2024-01-08 08:26 UTC by Agostino Sarubbo
Modified: 2024-05-16 11:29 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
build.log (build.log,75.12 KB, text/plain)
2024-01-08 08:26 UTC, Agostino Sarubbo
Details

Note You need to log in before you can comment on or make changes to this bug.
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 gentoo-dev 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);