On 2020/01/08 11:32, Jeremie Courreges-Anglas wrote:
>
> +cc rsadowski@
>
> On Wed, Jan 08 2020, Jeremie Courreges-Anglas <j...@wxcvbn.org> wrote:
> > On Tue, Jan 07 2020, Stuart Henderson <s...@spacehopper.org> wrote:
> >> On 2020/01/08 00:45, Pekka Niiranen wrote:
> >>> Hello,
> >>>
> >>> Has anybody else got this error:
> >>>
> >>> When I start emacs-gtk3 -package from X on PowerBook G4 (5,7)
> >>> I get error
> >>>
> >>> root@pekkappc:~ # emacs
> >>> emacs:/usr/local/lib/libestdc++.so.19.0: /usr/lib/libstdc++.so.57.0 :
> >>> WARNING: symbol(_ZNSt6locale5_Impl11_S_id_ctypeE) size mismatch, relink
> >>> your
> >>> program
> >>>
> >>> I have fetched sources with anoncvs after patch 016 had been released
> >>> and build a release (took 48h).
> >>> After that I removed all packages, recompiled first gcc and g++ and
> >>> finally
> >>> did "make install" in /usr/ports/editors/emacs (took days) but I still get
> >>> the same error.
> >>
> >> Is it displaying the message but working anyway, or is it not working?
> >
> > I get the same message on -current sparc64, with or without X. The
> > editor works fine over an ssh-forwarded connection.
>
> Pekka: note that if you don't experiment an actual problem (ie a bug or
> crash) you don't have to rebuild anything.
>
> >> It's not entirely unexpected, the platforms where /usr/bin/cc is gcc
> >> (alpha hppa mips64el powerpc sparc64) use a mixture of C++ compilers and
> >> incompatible standard libraries. We try to avoid mixing them as much
> >> as possible but sometimes it's unavoidable (for example, X libraries
> >> have to be built with the compiler in the base OS, and some of these
> >> use C++) and other times it may happen by mistake.
> >>
> >> If you send output from running "LD_DEBUG=1 emacs" (there will be quite
> >> a lot of output, you might need to run it under script(1) to capture it
> >> all) I'll see if I can spot why, but it might not be fixable.
> >
> > Here's the full output:
> >
> > https://pbot.rmdir.de/UemNvFzxIHUkL_6DD5a5_w
> >
> > --8<--
> > billy /tmp$ grep 'libstdc++' typescript | col -b
> > loading: libstdc++.so.57.0 required by
> > /usr/local/lib/libMagickWand-6.Q16.so.4.2
> > flags /usr/lib/libstdc++.so.57.0 = 0x0
> > obj /usr/lib/libstdc++.so.57.0 has emacs as head
> > linking dep /usr/lib/libstdc++.so.57.0 as child of
> > /usr/local/lib/libMagickWand-6.Q16.so.4.2
> > loading: libstdc++.so.57.0 required by
> > /usr/local/lib/libMagickCore-6.Q16.so.7.0
> > linking dep /usr/lib/libstdc++.so.57.0 as child of
> > /usr/local/lib/libMagickCore-6.Q16.so.7.0
> > examining: '/usr/lib/libstdc++.so.57.0'
> > loading: libm.so.10.1 required by /usr/lib/libstdc++.so.57.0
> > linking dep /usr/lib/libm.so.10.1 as child of /usr/lib/libstdc++.so.57.0
> > emacs:/usr/lib/libstdc++.so.57.0: /usr/local/lib/libestdc++.so.19.0 :
> > WARNING: symbol(_ZNSt6locale5_Impl11_S_id_ctypeE) size mismatch, relink
> > your program
> > 0000000807fec000 0000000808420000 rlib 0 2 0
> > /usr/lib/libstdc++.so.57.0
> > protect RELRO [0x808404420,0x80840c000) in /usr/lib/libstdc++.so.57.0
> > doing ctors obj 0x88930f400 @0x807fec2e0: [/usr/lib/libstdc++.so.57.0]
> > -->8--
>
> There are libstdc++ hits in graphics/ImageMagick. The most offending
> ones come from libraw_r.pc. libraw.pc has already been patched.
> Another hit comes from coders/Makefile.am but that one doesn't seem to
> be a problem.
>
> ok for the diff below?
> (ImageMagick still building here on sparc64, looks promising)
>
>
> Index: Makefile
> ===================================================================
> RCS file: /cvs/ports/graphics/libraw/Makefile,v
> retrieving revision 1.43
> diff -u -p -r1.43 Makefile
> --- Makefile 5 Sep 2019 16:20:25 -0000 1.43
> +++ Makefile 8 Jan 2020 09:30:47 -0000
> @@ -4,6 +4,7 @@ COMMENT = library for reading RAW files
>
> DISTNAME = LibRaw-0.19.5
> PKGNAME = ${DISTNAME:L}
> +REVISION = 0
> CATEGORIES = graphics
>
> SHARED_LIBS += raw 4.0 # 15.0
> Index: patches/patch-libraw_pc_in
> ===================================================================
> RCS file: /cvs/ports/graphics/libraw/patches/patch-libraw_pc_in,v
> retrieving revision 1.1
> diff -u -p -r1.1 patch-libraw_pc_in
> --- patches/patch-libraw_pc_in 27 Mar 2019 23:29:06 -0000 1.1
> +++ patches/patch-libraw_pc_in 8 Jan 2020 09:30:47 -0000
> @@ -1,6 +1,6 @@
> $OpenBSD: patch-libraw_pc_in,v 1.1 2019/03/27 23:29:06 ajacoutot Exp $
>
> -Do not hardcode -lstdc++ (symbol mismatch with libc++abi).
> +Do not hardcode -lstdc++ (symbol mismatch with libc++abi and libestdc++).
>
> Index: libraw.pc.in
> --- libraw.pc.in.orig
> Index: patches/patch-libraw_r_pc_in
> ===================================================================
> RCS file: patches/patch-libraw_r_pc_in
> diff -N patches/patch-libraw_r_pc_in
> --- /dev/null 1 Jan 1970 00:00:00 -0000
> +++ patches/patch-libraw_r_pc_in 8 Jan 2020 09:30:47 -0000
> @@ -0,0 +1,14 @@
> +$OpenBSD$
> +
> +Do not hardcode -lstdc++ (symbol mismatch with libc++abi and libestdc++).
> +
> +Index: libraw_r.pc.in
> +--- libraw_r.pc.in.orig
> ++++ libraw_r.pc.in
> +@@ -7,5 +7,5 @@ Name: libraw
> + Description: Raw image decoder library (thread-safe)
> + Requires: @PACKAGE_REQUIRES@
> + Version: @PACKAGE_VERSION@
> +-Libs: -L${libdir} -lraw_r -lstdc++@PC_OPENMP@
> ++Libs: -L${libdir} -lraw_r @PC_OPENMP@
Should be
-Libs: -L${libdir} -lraw_r -lstdc++@PC_OPENMP@
+Libs: -L${libdir} -lraw_r@PC_OPENMP@
(and the libraw.pc.in patch ought to be fixed too) - I have seen some
cases where libtool is excessively fussy about whitespace. libraw is
careful to put the space in where needed.
Otherwise OK.
> + Cflags: -I${includedir}/libraw
>
> --
> jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
>
