Re: graphics/cinepaint build fails on -current/amd64

[Joerg Sonnenberger <joerg%bec.de@localhost>]

On Sat, Apr 08, 2023 at 10:33:00PM +0200, Thomas Klausner wrote:
> On Sat, Apr 08, 2023 at 03:24:21PM -0500, John D. Baker wrote:
> > Attempting to build "graphics/cinepaint" from pkgsrc-2023Q1 on
> > NetBSD/amd64-10.99.2 fails with:
> > 
> > [...]
> > Making all in blur
> > gmake[2]: Entering directory '/tmp/pkgsrc/graphics/cinepaint/work/cinepaint-1.0-4/plug-ins/blur'
> > /bin/sh ../../libtool --tag=CC   --mode=link gcc  -I/usr/pkg/include -O2 -fPIC -D_FORTIFY_SOURCE=2 -I/usr/pkg/include -I/usr/include -I/usr/X11R7/include -I/usr/X11R7/include/libdrm -I/usr/X11R7/include/freetype2 -I/usr/pkg/include/glib-2.0 -I/usr/pkg/include/gio-unix-2.0 -I/usr/pkg/lib/glib-2.0/include -I/usr/pkg/include/harfbuzz -I/usr/pkg/include/python3.10 -Wall  -Wl,-zrelro -L/usr/pkg/lib -Wl,-R/usr/pkg/lib -L/usr/lib -Wl,-R/usr/lib -L/usr/X11R7/lib -Wl,-R/usr/X11R7/lib -o blur blur.o ../../lib/libcinepaint.la -L/usr/pkg/lib -Wl,-zrelro -L/usr/pkg/lib -Wl,-R/usr/pkg/lib -L/usr/lib -Wl,-R/usr/lib -L/usr/X11R7/lib -Wl,-R/usr/X11R7/lib -L/usr/X11R7/lib -lXcomposite -lXdamage -L/usr/pkg/lib -lharfbuzz  -L/usr/X11R7/lib -lXcomposite -lXdamage -L/usr/pkg/lib -lharfbuzz -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lpangoft2-1.0 -lpangocairo-1.0 -lXrender -lXinerama -lXi -lXrandr -lXcursor -lgdk_pixbuf-2.0 -lXext -lfontconfig -lgio-2.0 -lXfixes -lfreetype -lcairo -Wl,-rpath,/usr/X11R7/lib -lX11 -lglib-2.0 -lintl -lpango-1.0 -Wl,-R/usr/pkg/lib -lgobject-2.0 -Wl,-zrelro -L/usr/pkg/lib -Wl,-R/usr/pkg/lib -L/usr/lib -Wl,-R/usr/lib -L/usr/X11R7/lib -Wl,-R/usr/X11R7/lib ../../libhalf/cinepaint_half.lo -pthread -Wl,-R/usr/pkg/lib -L/usr/pkg/lib -lOpenEXR-3_1 -lOpenEXRUtil-3_1 -lOpenEXRCore-3_1 -lIex-3_1 -lIlmThread-3_1 -Wl,-R/usr/pkg/lib -lImath-3_1 -lc 
> > libtool: link: gcc -I/tmp/pkgsrc/graphics/cinepaint/work/.buildlink/include -O2 -fPIC -D_FORTIFY_SOURCE=2 -I/tmp/pkgsrc/graphics/cinepaint/work/.x11-buildlink/include -I/tmp/pkgsrc/graphics/cinepaint/work/.x11-buildlink/include/libdrm -I/tmp/pkgsrc/graphics/cinepaint/work/.x11-buildlink/include/freetype2 -I/tmp/pkgsrc/graphics/cinepaint/work/.buildlink/include/glib-2.0 -I/tmp/pkgsrc/graphics/cinepaint/work/.buildlink/include/gio-unix-2.0 -I/tmp/pkgsrc/graphics/cinepaint/work/.buildlink/lib/glib-2.0/include -I/tmp/pkgsrc/graphics/cinepaint/work/.buildlink/include/harfbuzz -I/tmp/pkgsrc/graphics/cinepaint/work/.buildlink/include/python3.10 -Wall -Wl,-zrelro -Wl,-rpath -Wl,/usr/pkg/lib -Wl,-rpath -Wl,/usr/X11R7/lib -o .libs/blur blur.o -Wl,-zrelro -Wl,-rpath -Wl,/usr/pkg/lib -Wl,-rpath -Wl,/usr/X11R7/lib -Wl,-rpath -Wl,/usr/X11R7/lib -Wl,-rpath -Wl,/usr/pkg/lib -Wl,-zrelro -Wl,-rpath -Wl,/usr/pkg/lib -Wl,-rpath -Wl,/usr/X11R7/lib ../../libhalf/.libs/cinepaint_half.o -Wl,-rpath -Wl,/usr/pkg/lib -Wl,-rpath -Wl,/usr/pkg/lib -pie  -L/tmp/pkgsrc/graphics/cinepaint/work/cinepaint-1.0-4/libhalf/.libs -L/tmp/pkgsrc/graphics/cinepaint/work/.buildlink/lib -L/tmp/pkgsrc/graphics/cinepaint/work/.x11-buildlink/lib -L../../lib/.libs -lcinepaint -lcinepaintHalf -lgtk-x11-2.0 -lgmodule-2.0 -lgdk-x11-2.0 -lXcomposite -lXdamage -lharfbuzz -latk-1.0 -lpangoft2-1.0 -lpangocairo-1.0 -lXinerama -lXi -lXrandr -lXcursor -lgdk_pixbuf-2.0 -lgio-2.0 -lXfixes -lcairo -lpixman-1 -lfontconfig -lfreetype -lbz2 -lpng16 -lxcb-shm -lxcb-render -lxcb -lXrender -lXext -lz -lrt -lm -lX11 -lglib-2.0 -lintl -lpango-1.0 -lgobject-2.0 -lOpenEXR-3_1 -lOpenEXRUtil-3_1 -lOpenEXRCore-3_1 -lIex-3_1 -lIlmThread-3_1 -lImath-3_1 -lc -pthread  -Wl,-rpath,/usr/pkg/lib -Wl,-rpath,/tmp/pkgsrc/graphics/cinepaint/work/.buildlink/lib
> > ld: ../../libhalf/.libs/cinepaint_half.o: undefined reference to symbol '_ZNSt8ios_base4InitD1Ev@@GLIBCXX_3.4'
> > ld: /usr/lib/libstdc++.so.9: error adding symbols: DSO missing from command line
> 
> This error means that a library should be added explicitly on the
> command line (the library providing
> _ZNSt8ios_base4InitD1Ev@@GLIBCXX_3.4). On older ld versions, it was
> sufficient if it was pulled in indirectly via another library that
> already linked against it, but newer binutils are more restrictive.

The real problem here would be that it is linking C++ code with CC.

Joerg