[sparc64/powerpc] Mark geo/spatialite/gis BROKEN

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

[sparc64/powerpc] Mark geo/spatialite/gis BROKEN

Kurt Mosiejczuk-9
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 ?

--Kurt

Index: Makefile
===================================================================
RCS file: /cvs/ports/geo/spatialite/gis/Makefile,v
retrieving revision 1.14
diff -u -p -r1.14 Makefile
--- Makefile 17 May 2019 16:45:26 -0000 1.14
+++ Makefile 16 Feb 2020 03:15:35 -0000
@@ -1,5 +1,8 @@
 # $OpenBSD: Makefile,v 1.14 2019/05/17 16:45:26 sthen Exp $
 
+BROKEN-sparc64 = Link failure referencing rasterlite
+BROKEN-powerpc = Link failure referencing rasterlite
+
 COMMENT = minimalistic GIS on top of spatialite and rasterlite
 PROJECT = spatialite_gis
 DISTNAME = ${PROJECT}-1.0.0c

Reply | Threaded
Open this post in threaded view
|

Re: [sparc64/powerpc] Mark geo/spatialite/gis BROKEN

Jeremie Courreges-Anglas-2
On Sat, Feb 15 2020, Kurt Mosiejczuk <[hidden email]> 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.

I'd rather give this error some exposure than sweep it under the rug.

--8<--
/usr/bin/libtool --tag=disable-static --tag=CXX    --mode=link c++  -I/usr/local/lib/wx/include/gtk3-unicode-3.0 -I/usr/local/include/wx-3.0 -I/usr/X11R6/include -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXGTK__ -pthread -I/usr/local/include    -L/usr/local/lib -o spatialite_gis Bitmaps.o ClassifyDlgs.o  Dialogs.o GraphicsDlgs.o LayerTree.o  Main.o MapDynamic.o MapView.o  MetadataInit.o Network.o Objects.o  OutputMap.o Shapefiles.o SqlHelpers.o  TableDialogs.o -L/usr/local/lib -pthread   -L/usr/X11R6/lib -L/usr/X11R6/lib -lwx_gtk3u_aui-3.0 -lwx_gtk3u_xrc-3.0 -lwx_gtk3u_html-3.0 -lwx_gtk3u_qa-3.0 -lwx_gtk3u_adv-3.0 -lwx_gtk3u_core-3.0 -lwx_baseu_xml-3.0 -lwx_baseu_net-3.0 -lwx_baseu-3.0  -L/usr/local/lib -lspatialite -L/usr/local/lib -lrasterlite -L/usr/local/lib -lfreexl -lm -lhpdf -lgeotiff -lgeos_c -lproj -ltiff -ljpeg -lz
libtool: link: c++ -o spatialite_gis -pthread -I/usr/local/lib/wx/include/gtk3-unicode-3.0 -I/usr/local/include/wx-3.0 -I/usr/X11R6/include -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXGTK__ -I/usr/local/include Bitmaps.o ClassifyDlgs.o Dialogs.o GraphicsDlgs.o LayerTree.o Main.o MapDynamic.o MapView.o MetadataInit.o Network.o Objects.o OutputMap.o Shapefiles.o SqlHelpers.o TableDialogs.o -L.libs -lwx_gtk3u_aui-3.0 -lgtk-3 -lgdk-3 -lpangocairo-1.0 -lpango-1.0 -lharfbuzz -lgdk_pixbuf-2.0 -lcairo-gobject -lcairo -lpthread -lpixman-1 -lm -lfontconfig -lfreetype -lz -lexpat -lpng -lxcb-shm -lxcb -lxcb-render -lXrender -lX11 -lXext -lgobject-2.0 -lglib-2.0 -lintl -liconv -lgio-2.0 -lXinerama -lXi -lXrandr -lXcursor -lXfixes -lXcomposite -lXdamage -lepoxy -lfribidi -lgraphite2 -lgmodule-2.0 -latk-1.0 -latk-bridge-2.0 -lpangoft2-1.0 -lpcre -lffi -lgthread-2.0 -lXxf86vm -lSM -lICE -lnotify -ljpeg -ltiff -lzstd -llzma -lwx_gtk3u_adv-3.0 -lwx_gtk3u_core-3.0 -lwx_baseu-3.0 -lSDL2 -lsndio -lsamplerate -lXss -lusbhid -lwx_gtk3u_xrc-3.0 -lwx_gtk3u_html-3.0 -lmspack -lwx_baseu_xml-3.0 -lwx_gtk3u_qa-3.0 -lwx_baseu_net-3.0 -lspatialite -lxml2 -lfreexl -lcharset -lproj -lsqlite3 -lgeos_c -lgeos -lstdc++ -lestdc++ -lgeotiff -lhpdf -Wl,-rpath-link,/usr/X11R6/lib,-rpath-link,/usr/local/lib
Main.o: In function `MyFrame::GetRandomColor(int*, int*, int*)':
Main.cpp:(.text+0x4620): warning: rand() may return deterministic values, is that what you want?
.libs/libwx_baseu-3.0.so.0.0: warning: wcscat() is almost always misused, please use wcslcat()
.libs/libglib-2.0.so.4201.3: warning: vsprintf() is often misused, please use vsnprintf()
.libs/libwx_baseu-3.0.so.0.0: warning: wcscpy() is almost always misused, please use wcslcpy()
Main.o: In function `MyFrame::MemoryDbSave()':
Main.cpp:(.text+0xe908): warning: stpcpy() is dangerous; do not use it
Main.o: In function `MyFrame::ConvertFromJulianDateTime(double, char*)':
Main.cpp:(.text+0x6210): warning: strcat() is almost always misused, please use strlcat()
ClassifyDlgs.o: In function `SubClassSizeDialog::CreateControls()':
ClassifyDlgs.cpp:(.text+0x5a50): warning: sprintf() is often misused, please use snprintf()
Main.o: In function `MyFrame::ConvertString(wxString&, char*, int*)':
Main.cpp:(.text+0x95dc): warning: strcpy() is almost always misused, please use strlcpy()
MapView.o: In function `MyMapView::GetRaster(void*, wxBitmap*)':
MapView.cpp:(.text+0x1207c): undefined reference to `rasterliteGetBestAccess'
MapView.o: In function `MyMapView::DrawRasterLayer(wxGraphicsContext*, MapLayer*)':
MapView.cpp:(.text+0x12f30): undefined reference to `rasterliteOpen'
MapView.cpp:(.text+0x12f38): undefined reference to `rasterliteIsError'
MapView.cpp:(.text+0x12f54): undefined reference to `rasterliteSetTransparentColor'
MapView.cpp:(.text+0x12f68): undefined reference to `rasterliteSetBackgroundColor'
...
-->8--


--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

Reply | Threaded
Open this post in threaded view
|

libtool: really strip stdc++ when estdc++ is present (Was: [sparc64/powerpc] Mark geo/spatialite/gis BROKEN)

Charlene Wendling
On Sun, 16 Feb 2020 08:04:12 +0100
Jeremie Courreges-Anglas wrote:

> On Sat, Feb 15 2020, Kurt Mosiejczuk <[hidden email]> 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,

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);
- splice(@$orderedlibs, $is, 1, "estdc++");
- $ie = $is;
- } else {
- splice(@$orderedlibs, $is, 1);
- }
+ splice(@$orderedlibs, $is, 1);
  }
  tsay {"staticlibs = \n", join("\n", @$staticlibs)};
  tsay {"orderedlibs = @$orderedlibs"};



Reply | Threaded
Open this post in threaded view
|

Re: libtool: really strip stdc++ when estdc++ is present (Was: [sparc64/powerpc] Mark geo/spatialite/gis BROKEN)

Kurt Mosiejczuk-9
On Sat, Feb 22, 2020 at 04:17:59PM +0100, Charlene Wendling wrote:
> On Sun, 16 Feb 2020 08:04:12 +0100
> Jeremie Courreges-Anglas wrote:

> > On Sat, Feb 15 2020, Kurt Mosiejczuk <[hidden email]> 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,

Well, I put this in that last sparc64 bulk and it did what it said and
did not break everything. ok kmos.

--Kurt

Reply | Threaded
Open this post in threaded view
|

Re: libtool: really strip stdc++ when estdc++ is present

Jeremie Courreges-Anglas-2
In reply to this post by Charlene Wendling
On Sat, Feb 22 2020, Charlene Wendling <[hidden email]> wrote:

> On Sun, 16 Feb 2020 08:04:12 +0100
> Jeremie Courreges-Anglas wrote:
>
>> On Sat, Feb 15 2020, Kurt Mosiejczuk <[hidden email]> 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);


--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

Reply | Threaded
Open this post in threaded view
|

Re: libtool: really strip stdc++ when estdc++ is present

Vadim Zhukov
вс, 23 февр. 2020 г. в 10:19, Jeremie Courreges-Anglas <[hidden email]>:

>
> On Sat, Feb 22 2020, Charlene Wendling <[hidden email]> wrote:
> > On Sun, 16 Feb 2020 08:04:12 +0100
> > Jeremie Courreges-Anglas wrote:
> >
> >> On Sat, Feb 15 2020, Kurt Mosiejczuk <[hidden email]> 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.

--
  WBR,
  Vadim Zhukov

Reply | Threaded
Open this post in threaded view
|

Re: libtool: really strip stdc++ when estdc++ is present

Charlene Wendling
On Sun, 23 Feb 2020 15:07:40 +0300
Vadim Zhukov wrote:

> вс, 23 февр. 2020 г. в 10:19, Jeremie Courreges-Anglas
> <[hidden email]>:
> >
> > On Sat, Feb 22 2020, Charlene Wendling <[hidden email]> wrote:
> > > On Sun, 16 Feb 2020 08:04:12 +0100
> > > Jeremie Courreges-Anglas wrote:
> > >
> > >> On Sat, Feb 15 2020, Kurt Mosiejczuk <[hidden email]> 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 ^^


Reply | Threaded
Open this post in threaded view
|

Re: libtool: really strip stdc++ when estdc++ is present

Kurt Mosiejczuk-9
On Sun, Feb 23, 2020 at 05:02:36PM +0100, Charlene Wendling wrote:

> > 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 ^^

I'm restarting the sparc64 bulk with this in place. We'll see how it goes.

--Kurt

Reply | Threaded
Open this post in threaded view
|

Re: libtool: really strip stdc++ when estdc++ is present

Kurt Mosiejczuk-9
On Sun, Feb 23, 2020 at 12:35:00PM -0500, Kurt Mosiejczuk wrote:
> On Sun, Feb 23, 2020 at 05:02:36PM +0100, Charlene Wendling wrote:

> > > 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 ^^

> I'm restarting the sparc64 bulk with this in place. We'll see how it goes.

That bulk has completed just fine. ok kmos

--Kurt