Hello All, I am following up on this.
Is there any hope for a patch Scilab release that would support gcc < 8 ? This regression makes packaging the latest version of scilab impossible on conda-forge, which is probably the largest scientific software distribution. Thanks, Sylvain On Thu, Mar 5, 2020 at 11:56 AM Sylvain Corlay <sylvain.cor...@gmail.com> wrote: > Hi Clément, > > Indeed, this is what I ended up doing - and there are a couple of > instances of the same error in various places. > > This appears to be a legitimate error C++ even though this passes with GCC > 8. > > On the choice of dropping GCC<8, this seems a bit early, even if the > latest flavors of Ubuntu, or Debian Sid already have GCC8 available. GCC6 > and GCC7 are recent compilers and people target older distributions in > their builds. > > Best, > > Sylvain Corlay > > On Thu, Mar 5, 2020 at 11:41 AM Clément David <clement.da...@esi-group.com> > wrote: > >> Hello Sylvain, >> >> I took a look at the trace, it looks like g++ 7 is confused with the >> xml.h include ; as libxml2 is already protected with ifdef __cplusplus >> extern "C" you might just move the #include <xml.h> from XMLDocument.hxx:28 >> out of the extern "C". >> >> Sorry about that but gcc-7 is not our target for official releases, >> Debian/Ubuntu/Fedora all ship gcc-8 with a more stable c++17 support. I >> could only help to debug issues on the conda side. >> >> Regards, >> >> -- >> Clément >> >> > -----Original Message----- >> > From: dev <dev-boun...@lists.scilab.org> On Behalf Of Sylvain Corlay >> > Sent: Thursday, March 5, 2020 10:15 AM >> > To: List dedicated to the development of Scilab <dev@lists.scilab.org> >> > Subject: Re: [Scilab-Dev] Scilab 6.1.0 is available! >> > >> > Hello, >> > >> > Is there any update on the support of GCC 7 for Scilab 6.1? >> > >> > This is a major blocker for us to package it for the conda ecosystem. >> > >> > Best, >> > >> > On Thu, Feb 27, 2020 at 4:12 PM Sylvain Corlay < >> sylvain.cor...@gmail.com >> > <mailto:sylvain.cor...@gmail.com> > wrote: >> > >> > >> > Patching the source to use <experimental/filesystem> resolves that >> > particular issue with C++17 in GCC7. >> > >> > However, the Scilab build now fails with many occurrences of the >> error: >> > >> > error: template with C linkage >> > >> > >> > - You can see the raw build logs here: >> https://dev.azure.com/conda- >> > forge/84710dde-1620-425b-80d0- >> > 4cf5baca359d/_apis/build/builds/125787/logs/7 >> > - The scilab recipe update including the patches for <filesystem> >> is >> > available here: https://github.com/conda-forge/scilab-feedstock/pull/11 >> > >> > Officially supporting older versions of GCC than GCC 8 (which is >> from >> > May 2018) would be greatly appreciated. >> > >> > >> > Best, >> > >> > >> > On Thu, Feb 27, 2020 at 2:28 PM Sylvain Corlay >> > <sylvain.cor...@gmail.com <mailto:sylvain.cor...@gmail.com> > wrote: >> > >> > >> > Hi Clément, >> > >> > Regarding the Java, we already skip xcos in the build but >> we >> > were really hoping that we could start including it with this version. >> > >> > For the filesystem thingy, I will be patching the source >> as part of >> > the conda recipe to use <experimental/filesystem> instead and see how >> it goes - >> > although it would be really nice if we could support more compilers out >> of the >> > box. >> > >> > Sylvain >> > >> > On Thu, Feb 27, 2020 at 2:25 PM Clément David >> > <clement.da...@esi-group.com <mailto:clement.da...@esi-group.com> > >> > wrote: >> > >> > >> > Hello Sylvain, >> > >> > First, thank you for your work on the conda >> packaging. >> > The c++17 requirements is only needed for a single file that is used to >> implement >> > fullpath() (named fullpath.cpp). The used API is reduced to >> > std::filesystem::weakly_canonical and std::filesystem::absolute [1]. I >> guess using >> > a light patch might relax the use of the filesystem header, for example, >> > something like [2]. >> > >> > About the Java8 requirement, I guess you could >> > ./configure --without-xcos as a first approach. I started porting the >> Java code >> > out of javax.xml.bind [3] but that's very repetitive and error prone >> work. >> > >> > [1]: >> > >> https://codereview.scilab.org/#/c/21041/25/scilab/modules/fileio/src/cpp/fullp >> > ath.cpp >> > [2]: >> > https://stackoverflow.com/questions/45867379/why-does-gcc-not-seem-to- >> > have-the-filesystem-standard-library >> > [3]: https://codereview.scilab.org/#/c/20630/ >> > >> > Regards, >> > >> > -- >> > Clément >> > >> > > -----Original Message----- >> > > From: dev <dev-boun...@lists.scilab.org >> > <mailto:dev-boun...@lists.scilab.org> > On Behalf Of Sylvain Corlay >> > > Sent: Thursday, February 27, 2020 1:50 PM >> > > To: List dedicated to the development of Scilab >> > <dev@lists.scilab.org <mailto:dev@lists.scilab.org> > >> > > Subject: Re: [Scilab-Dev] Scilab 6.1.0 is >> available! >> > > >> > > Congratulations on the release. >> > > >> > > I am the author of the conda package for >> scilab, and >> > unfortunately, it does not >> > > seem that 6.1.0 can be successfully packaged for >> > conda-forge with the new >> > > requirement for the <filesystem> C++17 header, >> > which requires GCC 8. >> > > >> > > Conda-forge is still based on GCC 7, which is >> fairly >> > recent, with C++17 enabled by >> > > default. Would you consider not using the >> > <filesystem> from the C++17 standard >> > > so that Scilab can be made available to a wider >> > audience? >> > > >> > > Another blocker to the packaging of Scilab is >> the >> > outdated version of java that is >> > > required by the GUI. Is there any plan to >> support a >> > more recent version of >> > > OpenJDK? >> > > >> > > Best, >> > > >> > > Sylvain Corlay >> > > >> > > On Tue, Feb 25, 2020 at 2:10 PM Clément David >> > <Clement.David@esi- >> > > group.com <http://group.com> >> > <mailto:clement.da...@esi-group.com <mailto:Clement.David@esi- >> > group.com> > > wrote: >> > > >> > > >> > > Dear Scilab-ers, >> > > >> > > >> > > >> > > A brand new Scilab 6.1.0 >> > <https://www.scilab.org/download/6.1.0> is >> > > released today! >> > > >> > > >> > > >> > > This version includes further improvement >> atop >> > Scilab 6.0 for better >> > > stability and increased algorithm performance. >> It also >> > includes a reworked >> > > display for more compact and meaningful value >> > printing; web tools for HTTP, >> > > JSON support; better debug support and various >> > algorithm rewrite/extension. >> > > >> > > >> > > >> > > This first iteration of the 6.1 branch >> fixes up to 245 >> > bugs and implements >> > > missing features from the 6.0.2 version. We >> would >> > like to give a special thanks >> > > to Samuel and Stephane who have been very active >> > this year. >> > > >> > > >> > > >> > > If you find any critical issue or >> instability that might >> > need a 6.1.x release >> > > please alert us <https://bugzilla.scilab.org/> >> . If you >> > are a toolbox maintainer, >> > > please rebuild your code, upgrade it when >> needed and >> > publish it to >> > > atoms.scilab.org <http://atoms.scilab.org> >> > <https://atoms.scilab.org/> . >> > > >> > > >> > > >> > > For the complete list of changes and bugs >> fixed, >> > please take a look at >> > > the CHANGES <https://help.scilab.org/CHANGES> >> > file. >> > > >> > > >> > > >> > > -- >> > > >> > > Clément on behalf of the Scilab team >> > > >> > > >> > _______________________________________________ >> > > dev mailing list >> > > dev@lists.scilab.org <mailto: >> dev@lists.scilab.org> >> > <mailto:dev@lists.scilab.org <mailto:dev@lists.scilab.org> > >> > > >> http://lists.scilab.org/mailman/listinfo/dev >> > > >> > >> > >> > _______________________________________________ >> > dev mailing list >> > dev@lists.scilab.org <mailto:dev@lists.scilab.org >> > >> > http://lists.scilab.org/mailman/listinfo/dev >> > >> >> _______________________________________________ >> dev mailing list >> dev@lists.scilab.org >> http://lists.scilab.org/mailman/listinfo/dev >> >
_______________________________________________ dev mailing list dev@lists.scilab.org http://lists.scilab.org/mailman/listinfo/dev
