[MacPorts] #73949: libwmf 0.2.15: build fails when an older libwmf is already installed (incomplete fix in f79f336322e)
MacPorts
noreply at macports.org
Sat May 2 15:45:57 UTC 2026
#73949: libwmf 0.2.15: build fails when an older libwmf is already installed
(incomplete fix in f79f336322e)
---------------------+--------------------
Reporter: lukaso | Owner: (none)
Type: defect | Status: new
Priority: Normal | Milestone:
Component: ports | Version:
Resolution: | Keywords:
Port: libwmf |
---------------------+--------------------
Description changed by ryandesign:
Old description:
> `libwmf @0.2.15_0` fails to build on macOS when an older `libwmf` (e.g.
> `0.2.8.4_9`) is currently installed. The `post-configure` reinplace added
> in [f79f336322e](https://github.com/macports/macports-
> ports/commit/f79f336322ee13d837024821eef6b1f24aafd55a) only patches
> `src/ipa/Makefile`, but `src/Makefile` has the same `-I${prefix}/include`
> ahead of `-I$(top_srcdir)/include`. When the OLD installed
> `${prefix}/include/libwmf/ipa.h` is present, it shadows the new in-tree
> header during the build of `src/player.c`, and the API broke between
> 0.2.8.4 and 0.2.15.
>
> == Reproduction ==
>
> 1. Have `libwmf @0.2.8.4_9` installed.
> 2. `port selfupdate` (so the 0.2.15 Portfile with
> [f79f336322e](https://github.com/macports/macports-
> ports/commit/f79f336322ee13d837024821eef6b1f24aafd55a) is in place).
> 3. `port install libwmf` → upgrade fails during `Building libwmf` while
> compiling `src/player.c`.
>
> == Error ==
>
> {{{
> :info:build ./player/color.h:369:8: error: conflicting types for
> 'wmf_rgb_white'
> :info:build 369 | wmfRGB wmf_rgb_white (void)
> :info:build | ^
> :info:build /opt/local/include/libwmf/ipa.h:89:15: note: previous
> declaration is here
> :info:build 89 | extern wmfRGB wmf_rgb_white (wmfAPI*);
> :info:build ./player/color.h:380:8: error: conflicting types for
> 'wmf_rgb_black'
> :info:build /opt/local/include/libwmf/ipa.h:90:15: note: previous
> declaration is here
> :info:build 90 | extern wmfRGB wmf_rgb_black (wmfAPI*);
> }}}
>
> == Environment ==
>
> - macOS 26.3.1, Apple Silicon (also reported with x86_64 builds)
> - MacPorts 2.12.5
> - Affects `libwmf @0.2.15_0`, revision 0
> - Workaround: `port -f uninstall libwmf && port install libwmf`
>
> == Root cause (AI static analysis — so please verify) ==
>
> In `src/Makefile.am`:
>
> {{{
> AM_CPPFLAGS += -I$(top_srcdir)/include -I$(top_srcdir)/src
> -I$(top_builddir)
> }}}
>
> The `+=` appends, so the configure-substituted `@AM_CPPFLAGS@` (which
> contains `-I${prefix}/include`) ends up *before* the in-tree include
> paths in the generated `src/Makefile`. When an older libwmf is installed,
> `${prefix}/include/libwmf/ipa.h` is found before the new in-tree
> `include/libwmf/ipa.h`, and the function signatures conflict (e.g.
> `wmf_rgb_white(wmfAPI*)` vs `wmf_rgb_white(void)`).
>
> `src/convert/Makefile.am` has the same pattern and is likely affected by
> the same root cause; `src/ipa/Makefile` already gets stripped by
> [f79f336322e](https://github.com/macports/macports-
> ports/commit/f79f336322ee13d837024821eef6b1f24aafd55a).
>
> A fresh install (no older libwmf present) succeeds because
> `${prefix}/include/libwmf/` doesn't exist yet, so the stale
> `-I${prefix}/include` is harmless. The bug only surfaces during upgrade.
>
> == Suggested fixes (AI-suggested — so please verify) ==
>
> 1. Extend the existing `post-configure` reinplace to `src/Makefile` (and
> `src/convert/Makefile`):
>
> {{{
> post-configure {
> foreach mf {src/Makefile src/ipa/Makefile src/convert/Makefile} {
> reinplace "s|AM_CPPFLAGS = -I${prefix}/include|AM_CPPFLAGS = |g"
> ${worksrcpath}/${mf}
> reinplace "s|CPPFLAGS = -I${prefix}/include|CPPFLAGS = |g"
> ${worksrcpath}/${mf}
> }
> }
> }}}
>
> 2. Better: patch `src/Makefile.am` (and friends) upstream so in-tree
> paths come first — i.e. use a separate `LIBWMF_INTERNAL_CPPFLAGS =
> -I$(top_srcdir)/include …` and prepend it in the per-target `_CPPFLAGS`,
> instead of `AM_CPPFLAGS +=`.
>
> 3. Or bump the port epoch and uninstall the old version before building,
> so the stale headers can't be picked up.
New description:
`libwmf @0.2.15_0` fails to build on macOS when an older `libwmf` (e.g.
`0.2.8.4_9`) is currently installed. The `post-configure` reinplace added
in [f79f336322ee13d837024821eef6b1f24aafd55a/macports-ports] only patches
`src/ipa/Makefile`, but `src/Makefile` has the same `-I${prefix}/include`
ahead of `-I$(top_srcdir)/include`. When the OLD installed
`${prefix}/include/libwmf/ipa.h` is present, it shadows the new in-tree
header during the build of `src/player.c`, and the API broke between
0.2.8.4 and 0.2.15.
== Reproduction ==
1. Have `libwmf @0.2.8.4_9` installed.
2. `port selfupdate` (so the 0.2.15 Portfile with
[f79f336322ee13d837024821eef6b1f24aafd55a/macports-ports] is in place).
3. `port install libwmf` → upgrade fails during `Building libwmf` while
compiling `src/player.c`.
== Error ==
{{{
:info:build ./player/color.h:369:8: error: conflicting types for
'wmf_rgb_white'
:info:build 369 | wmfRGB wmf_rgb_white (void)
:info:build | ^
:info:build /opt/local/include/libwmf/ipa.h:89:15: note: previous
declaration is here
:info:build 89 | extern wmfRGB wmf_rgb_white (wmfAPI*);
:info:build ./player/color.h:380:8: error: conflicting types for
'wmf_rgb_black'
:info:build /opt/local/include/libwmf/ipa.h:90:15: note: previous
declaration is here
:info:build 90 | extern wmfRGB wmf_rgb_black (wmfAPI*);
}}}
== Environment ==
- macOS 26.3.1, Apple Silicon (also reported with x86_64 builds)
- MacPorts 2.12.5
- Affects `libwmf @0.2.15_0`, revision 0
- Workaround: `port -f uninstall libwmf && port install libwmf`
== Root cause (AI static analysis — so please verify) ==
In `src/Makefile.am`:
{{{
AM_CPPFLAGS += -I$(top_srcdir)/include -I$(top_srcdir)/src
-I$(top_builddir)
}}}
The `+=` appends, so the configure-substituted `@AM_CPPFLAGS@` (which
contains `-I${prefix}/include`) ends up *before* the in-tree include paths
in the generated `src/Makefile`. When an older libwmf is installed,
`${prefix}/include/libwmf/ipa.h` is found before the new in-tree
`include/libwmf/ipa.h`, and the function signatures conflict (e.g.
`wmf_rgb_white(wmfAPI*)` vs `wmf_rgb_white(void)`).
`src/convert/Makefile.am` has the same pattern and is likely affected by
the same root cause; `src/ipa/Makefile` already gets stripped by
[f79f336322ee13d837024821eef6b1f24aafd55a/macports-ports].
A fresh install (no older libwmf present) succeeds because
`${prefix}/include/libwmf/` doesn't exist yet, so the stale
`-I${prefix}/include` is harmless. The bug only surfaces during upgrade.
== Suggested fixes (AI-suggested — so please verify) ==
1. Extend the existing `post-configure` reinplace to `src/Makefile` (and
`src/convert/Makefile`):
{{{
post-configure {
foreach mf {src/Makefile src/ipa/Makefile src/convert/Makefile} {
reinplace "s|AM_CPPFLAGS = -I${prefix}/include|AM_CPPFLAGS = |g"
${worksrcpath}/${mf}
reinplace "s|CPPFLAGS = -I${prefix}/include|CPPFLAGS = |g"
${worksrcpath}/${mf}
}
}
}}}
2. Better: patch `src/Makefile.am` (and friends) upstream so in-tree paths
come first — i.e. use a separate `LIBWMF_INTERNAL_CPPFLAGS =
-I$(top_srcdir)/include …` and prepend it in the per-target `_CPPFLAGS`,
instead of `AM_CPPFLAGS +=`.
3. Or bump the port epoch and uninstall the old version before building,
so the stale headers can't be picked up.
--
--
Ticket URL: <https://trac.macports.org/ticket/73949#comment:2>
MacPorts <https://www.macports.org/>
Ports system for macOS
More information about the macports-tickets
mailing list