wrong REQUIRES in lang/gcc10

[Greg Troxel <gdt%lexort.com@localhost>]

When I build gcc10, the resulting binary package has

  REQUIRES=/usr/pkg/gcc10//lib/./libgcc_s.so.1
  REQUIRES=/usr/pkg/gcc10//lib/./libquadmath.so.0
  REQUIRES=/usr/pkg/gcc10//lib/./libstdc++.so.7

it also has (among others):

  PROVIDES=/usr/pkg/gcc10/lib/libgcc_s.so
  PROVIDES=/usr/pkg/gcc10/lib/libgcc_s.so.1
  PROVIDES=/usr/pkg/gcc10/lib/libquadmath.so
  PROVIDES=/usr/pkg/gcc10/lib/libquadmath.so.0
  PROVIDES=/usr/pkg/gcc10/lib/libquadmath.so.0.0
  PROVIDES=/usr/pkg/gcc10/lib/libstdc++.so
  PROVIDES=/usr/pkg/gcc10/lib/libstdc++.so.7
  PROVIDES=/usr/pkg/gcc10/lib/libstdc++.so.7.28

pkg_add then objects to it.  (This seems wrong, because I think pkg_add
tries to look in the new package for satisfying its own requires, but
maybe I'm misreading -- and really these REQUIRES lines are wrong and
should be fixed.)

I am seeing this on:

  NetBSD-10 amd64, with pkgsrc-current as of December 22
  NetBSD-current (December 22), with pkgsrc-2024Q4

and have been seeing it for a long time.  It's hard to experiment on
older platforms because this takes a long time to build on good
hardware.

I believe this is coming from a bad RPATH arg.  Well not really bad, but
non-canonical.  The needed lib is the same file as a provided lib so it
should not be listed, but the pathname does not compared byte for byte.
Arguably it's buggy of the script that creates REQUIRES not to
canonicalize, but again likely better to fix.

I don't see this with gcc12.

Looking in work/.destdir, I find

  ./usr/pkg/gcc10/lib/gcc/x86_64--netbsd/10.5.0/plugin/libcc1plugin.so.0.0:
          -lstdc++.7 => /usr/pkg/gcc10//lib/./libstdc++.so.7
          -lm.0 => /usr/lib/libm.so.0
          -lc.12 => /usr/lib/libc.so.12
          -lgcc_s.1 => /usr/pkg/gcc10//lib/./libgcc_s.so.1
  ./usr/pkg/gcc10/lib/gcc/x86_64--netbsd/10.5.0/plugin/libcp1plugin.so.0.0:
          -lstdc++.7 => /usr/pkg/gcc10//lib/./libstdc++.so.7
          -lm.0 => /usr/lib/libm.so.0
          -lc.12 => /usr/lib/libc.so.12
          -lgcc_s.1 => /usr/pkg/gcc10//lib/./libgcc_s.so.1
  ./usr/pkg/gcc10/lib/libcc1.so.0.0:
          -lstdc++.7 => /usr/pkg/gcc10//lib/./libstdc++.so.7
          -lm.0 => /usr/lib/libm.so.0
          -lc.12 => /usr/lib/libc.so.12
          -lgcc_s.1 => /usr/pkg/gcc10//lib/./libgcc_s.so.1
  ./usr/pkg/gcc10/lib/libstdc++.so.7.28:
          -lm.0 => /usr/lib/libm.so.0
          -lc.12 => /usr/lib/libc.so.12
          -lgcc_s.1 => /usr/pkg/gcc10//lib/./libgcc_s.so.1
  ./usr/pkg/gcc10/lib/libquadmath.so.0.0:
          -lm.0 => /usr/lib/libm.so.0
          -lc.12 => /usr/lib/libc.so.12
  ./usr/pkg/gcc10/lib/libgfortran.so.5.0:
          -lquadmath.0 => /usr/pkg/gcc10//lib/./libquadmath.so.0
          -lm.0 => /usr/lib/libm.so.0
          -lc.12 => /usr/lib/libc.so.12
          -lgcc_s.1 => /usr/pkg/gcc10//lib/./libgcc_s.so.1

and objdump -x concurs:

  $ objdump -x ./usr/pkg/gcc10/lib/libgfortran.so.5.0|egrep RPATH\|NEED
    NEEDED               libquadmath.so.0
    NEEDED               libm.so.0
    NEEDED               libgcc_s.so.1
    NEEDED               libc.so.12
    RPATH                /usr/pkg/gcc10//lib/.:/usr/pkg/gcc10/lib/.:/usr/pkg/gcc10/lib:/usr/pkg/lib
    VERNEED              0x0000000000017a98
    VERNEEDNUM           0x0000000000000002

which is messy to have the same dir 3 times, once not the canonical
path.


Sure enough the build output has

  c++ -std=gnu++98 -fno-PIE -c  -DLINK_LIBGCC_SPEC="\"%D -R /usr/pkg/gcc10//lib/%M -R /usr/pkg/gcc10/lib/%M \"" -DSTANDARD_STARTFILE_PREFIX=\"../../../\" -DSTANDARD_EXEC_PREFIX=\"/usr/pkg/gcc10/lib/gcc/\" -DSTANDARD_LIBEXEC_PREFIX=\"/\
  usr/pkg/gcc10/libexec/gcc/\" -DDEFAULT_TARGET_VERSION=\"10.5.0\" -DDEFAULT_REAL_TARGET_MACHINE=\"x86_64--netbsd\" -DDEFAULT_TARGET_MACHINE=\"x86_64--netbsd\" -DSTANDARD_BINDIR_PREFIX=\"/usr/pkg/gcc10/bin/\" -DTOOLDIR_BASE_PREFIX=\".\
  ./../../../\" -DACCEL_DIR_SUFFIX=\"\"  -DENABLE_SHARED_LIBGCC -DCONFIGURE_SPECS="\"\"" -DTOOL_INCLUDE_DIR=\"/usr/pkg/gcc10/lib/gcc/x86_64--netbsd/10.5.0/../../../../x86_64--netbsd/include\" -DNATIVE_SYSTEM_HEADER_DIR=\"/usr/include\\
  " -DTARGET_MACHINE=\"x86_64--netbsd\" -DPERSONALITY=\"ar\" -g -DIN_GCC     -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag -Wno-format -Wmissing-forma\
  t-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I. -I. -I../../gcc-10.5.0/gcc -I../../gcc-10.5.0/gcc/. -I../../gcc-10.5.0/gcc/../include -I./../int\
  l -I../../gcc-10.5.0/gcc/../libcpp/include -I/tmp/work/lang/gcc10/work/build/./gmp -I/tmp/work/lang/gcc10/work/gcc-10.5.0/gmp -I/tmp/work/lang/gcc10/work/build/./mpfr/src -I/tmp/work/lang/gcc10/work/gcc-10.5.0/mpfr/src -I/tmp/work/l\
  ang/gcc10/work/gcc-10.5.0/mpc/src  -I../../gcc-10.5.0/gcc/../libdecnumber -I../../gcc-10.5.0/gcc/../libdecnumber/dpd -I../libdecnumber -I../../gcc-10.5.0/gcc/../libbacktrace -I/tmp/work/lang/gcc10/work/build/./isl/include -I/tmp/wor\
  k/lang/gcc10/work/gcc-10.5.0/isl/include -I/usr/include -o gcc-ar.o -MT gcc-ar.o -MMD -MP -MF ./.deps/gcc-ar.TPo ../../gcc-10.5.0/gcc/gcc-ar.c
  c++ -std=gnu++98 -no-pie   -g -DIN_GCC     -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag -Wno-format -Wmissing-format-attribute -Woverloaded-virtual\
   -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc -Wl,-zrelro -L/usr/lib -Wl,-R/usr/lib -Wl,-R/usr/pkg/lib gcc-ar.o -o gcc-ar \
          file-find.o libcommon.a ../libcpp/libcpp.a ./../intl/libintl.a  ../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a


Is anybody else seeing this?   Does "make package-install" succeed for
anyone in lang/gcc10 with up-to-date package tools?

Opinions about gcc bug vs wrapper bug vs something else?
gcc's src/Makefile.in:2209 looks buggy - there is //, and perhaps %M has
"./" at the beginning.