On Sun, 23 Feb 2020 15:07:40 +0300 Vadim Zhukov wrote: > вс, 23 февр. 2020 г. в 10:19, Jeremie Courreges-Anglas > <j...@wxcvbn.org>: > > > > On Sat, Feb 22 2020, Charlene Wendling <juliana...@posteo.jp> wrote: > > > On Sun, 16 Feb 2020 08:04:12 +0100 > > > Jeremie Courreges-Anglas wrote: > > > > > >> On Sat, Feb 15 2020, Kurt Mosiejczuk <k...@cranky.work> wrote: > > >> > http://build-failures.rhaalovely.net/sparc64/2020-02-11/geo/spatialite/gis.log > > >> > http://build-failures.rhaalovely.net/powerpc/2020-01-27/geo/spatialite/gis.log > > >> > > > >> > ok to mark this BROKEN-sparc64/BROKEN-powerpc ? > > >> > > >> libtool strips -lrasterlite from the command line arguments, this > > >> looks wrong. > > >> > > >> Also "-lstdc++ -lestdc++", boo. > > > > > > So i studied the issue and found it, the applied code is not what > > > libtool's debug message and manpage say it is. > > > > > > The second splice() tries to substitute stdc++ with estdc++, it is > > > not needed, because anyway orderedlibs seems always unique (i > > > tried by building stuff and using Data::Dumper). > > > > > > As such, the conditional can be removed entirely, since we just > > > want to strip stdc++ from orderedlibs when estdc++ is present. > > > > > > This fixes geo/spatialite/gis on macppc and sparc64. > > > > > > The below diff against libtool survived a sparc64 bulk. I've built > > > cad/magic and devel/openmpi among other ports using ports-gcc as > > > COMPILER, without issues on amd64. > > > > > > Comments/feedback are welcome, > > > > We should put -lestdc++ in the latest location of -lestdc++ > > and -lstdc++. The order of libraries matters at least for static > > linking, and I believe the intent of the code is correct. Please > > see below, > > > > > Charlène. > > > > > > > > > Index: Link.pm > > > =================================================================== > > > RCS file: /cvs/src/usr.bin/libtool/LT/Mode/Link.pm,v > > > retrieving revision 1.36 > > > diff -u -p -r1.36 Link.pm > > > --- Link.pm 23 Jul 2017 09:48:53 -0000 1.36 > > > +++ Link.pm 22 Feb 2020 14:34:51 -0000 > > > @@ -832,14 +832,7 @@ sub common1 > > > my $is = $tiedlibs->indexof("stdc++"); > > > if (defined($ie) and defined($is)) { > > > tsay {"stripping stdc++ from orderedlibs due to > > > having estdc++ already; ie=$ie, is=$is"}; > > > - # check what library comes later > > > - if ($ie < $is) { > > > - splice(@$orderedlibs, $ie, 1); > > > > After this, estdc++ has been removed and $is is now off by one > > > > > - splice(@$orderedlibs, $is, 1, "estdc++"); > > > > So here we fail to replace "stdc++" with "estdc++", instead we > > overwrite the next value with "estdc++". > > > > This is consistent with "-lstdc++ -lestdc++" appearing in > > > > > > http://build-failures.rhaalovely.net/sparc64/2020-02-11/geo/spatialite/gis.log > > > > and -lrasterlite being absent from the linking command line. Diff > > below. > > > > > - $ie = $is; > > > - } else { > > > - splice(@$orderedlibs, $is, 1); > > > - } > > > + splice(@$orderedlibs, $is, 1); > > > } > > > tsay {"staticlibs = \n", join("\n", @$staticlibs)}; > > > tsay {"orderedlibs = @$orderedlibs"}; > > > > > > First clobber "stdc++" with "estdc++" then remove the original > > "estdc++", this way the indexes stay consistent. This fixes > > geo/spatialite/gis on sparc64. > > > > Do you want to put this in another bulk? ok? > > > > > > Index: LT/Mode/Link.pm > > =================================================================== > > RCS file: /d/cvs/src/usr.bin/libtool/LT/Mode/Link.pm,v > > retrieving revision 1.36 > > diff -u -p -r1.36 Link.pm > > --- LT/Mode/Link.pm 23 Jul 2017 09:48:53 -0000 1.36 > > +++ LT/Mode/Link.pm 23 Feb 2020 07:08:59 -0000 > > @@ -834,8 +834,8 @@ sub common1 > > tsay {"stripping stdc++ from orderedlibs due to > > having estdc++ already; ie=$ie, is=$is"}; > > # check what library comes later > > if ($ie < $is) { > > - splice(@$orderedlibs, $ie, 1); > > splice(@$orderedlibs, $is, 1, "estdc++"); > > + splice(@$orderedlibs, $ie, 1); > > $ie = $is; > > } else { > > splice(@$orderedlibs, $is, 1); > > I've just checked the fix with test program, it does the job. The > patch looks like OK, but definitely needs to be run through the bulk > build.
I tested it on macppc just in case, it indeed works. Thanks for correcting this. I guess it's up to Kurt now ^^
