On Tue, 20 Sep 2016 11:10:02 +0200
Roel Janssen <r...@gnu.org> wrote:

> Eric Bavier writes:
> 
> > On 2016-09-19 05:11, Roel Janssen wrote:  
> >> Roel Janssen writes:
> >>   
> >>> Dear Guix,
> >>> 
> >>> I don't know what the impact of the following upgrade is, but I think 
> >>> it
> >>> would be good to update Boost to the latest stable version that was
> >>> released on May 13th, 2016.
> >>> 
> >>> What do you think?
> >>> 
> >>> Kind regards,
> >>> Roel Janssen
> >>>   
> >>>> From a6409b0648352cac86a3ceb205ee183c034085f5 Mon Sep 17 00:00:00 
> >>>> 2001  
> >>> From: Roel Janssen <r...@gnu.org>
> >>> Date: Mon, 19 Sep 2016 10:08:52 +0200
> >>> Subject: [PATCH] gnu: boost: Update to 1.61.0.
> >>> 
> >>> * gnu/packages/boost.scm (boost): Update to 1.61.0.
> >>> ---
> >>>  gnu/packages/boost.scm | 4 ++--
> >>>  1 file changed, 2 insertions(+), 2 deletions(-)
> >>> 
> >>> diff --git a/gnu/packages/boost.scm b/gnu/packages/boost.scm
> >>> index 8fe8c8e..ccc1f06 100644
> >>> --- a/gnu/packages/boost.scm
> >>> +++ b/gnu/packages/boost.scm
> >>> @@ -34,7 +34,7 @@
> >>>  (define-public boost
> >>>    (package
> >>>      (name "boost")
> >>> -    (version "1.60.0")
> >>> +    (version "1.61.0")
> >>>      (source (origin
> >>>                (method url-fetch)
> >>>                (uri (string-append
> >>> @@ -43,7 +43,7 @@
> >>>                      ".tar.bz2"))
> >>>                (sha256
> >>>                 (base32
> >>> -                
> >>> "0fzx6dwqbrkd4bcd8pjv0fpapwmrxxwr8yx9g67lihlsk3zzysk8"))))
> >>> +                
> >>> "0h5nk7pgxf7xsvvshj9qfpsfp9wx6gq9r78n3nx736pxq83bsix5"))))
> >>>      (build-system gnu-build-system)
> >>>      (inputs `(("zlib" ,zlib)))
> >>>      (native-inputs  
> >> 
> >> It looks like an upgrade to 1.61.0 causes a build failure for MySQL:
> >> 
> >> -------------------------- BUILD OUTPUT LOG FOR MYSQL 
> >> --------------------------
> >> -- BOOST_VERSION_NUMBER is #define BOOST_VERSION 106100
> >> CMake Warning at cmake/boost.cmake:266 (MESSAGE):
> >>   Boost minor version found is 61 we need 60
> >> Call Stack (most recent call first):
> >>   CMakeLists.txt:455 (INCLUDE)
> >> 
> >> 
> >> -- BOOST_INCLUDE_DIR /gnu/store/...fzzl-boost-1.61.0/include
> >> -- LOCAL_BOOST_DIR
> >> -- LOCAL_BOOST_ZIP
> >> -- Could not find (the correct version of) boost.
> >> -- MySQL currently requires boost_1_60_0
> >> 
> >> CMake Error at cmake/boost.cmake:81 (MESSAGE):
> >>   You can download it with -DDOWNLOAD_BOOST=1 -DWITH_BOOST=<directory>
> >> ------------------------ END BUILD OUTPUT LOG FOR MYSQL 
> >> ------------------------
> >> 
> >> So I guess the impact is too large to just go for it.
> >> 
> >> Do we have a Guix command to find out which packages are dependent on
> >> a package (in this case Boost)?
> >> 
> >> Kind regards,
> >> Roel Janssen  
> >
> > I looked at this upgrade a few weeks ago.  I took a stab at building the 
> > complete dependency set, and, for the most part, mysql is the only 
> > package that breaks.  I fixed this with the below patch (which also 
> > enable parallel builds that can improve build times significantly):
> >
> > diff --git a/gnu/packages/boost.scm b/gnu/packages/boost.scm
> > index bb123d3..f3288d1 100644
> > --- a/gnu/packages/boost.scm
> > +++ b/gnu/packages/boost.scm
> > @@ -34,7 +34,7 @@
> >   (define-public boost
> >     (package
> >       (name "boost")
> > -    (version "1.60.0")
> > +    (version "1.61.0")
> >       (source (origin
> >                 (method url-fetch)
> >                 (uri (string-append
> > @@ -43,7 +43,7 @@
> >                       ".tar.bz2"))
> >                 (sha256
> >                  (base32
> > -                
> > "0fzx6dwqbrkd4bcd8pjv0fpapwmrxxwr8yx9g67lihlsk3zzysk8"))))
> > +                
> > "0h5nk7pgxf7xsvvshj9qfpsfp9wx6gq9r78n3nx736pxq83bsix5"))))
> >       (build-system gnu-build-system)
> >       (inputs `(("zlib" ,zlib)))
> >       (native-inputs
> > @@ -53,6 +53,7 @@
> >       (arguments
> >        (let ((build-flags
> >               `("threading=multi" "link=shared"
> > +              (format #f "-j~a" (parallel-job-count))
> >
> >                 ;; Set the RUNPATH to $libdir so that the libs find each 
> > other.
> >                 (string-append "linkflags=-Wl,-rpath="
> > diff --git a/gnu/packages/databases.scm b/gnu/packages/databases.scm
> > index e05232d..5d7fe13 100644
> > --- a/gnu/packages/databases.scm
> > +++ b/gnu/packages/databases.scm
> > @@ -202,7 +202,7 @@ SQL, Key/Value, XML/XQuery or Java Object storage 
> > for their data model.")
> >                  
> > "11qbib1xpy0zkki7j9ip17hks5kp5zgpcj7x8gy3a4m66lb1mgsh"))))
> >       (build-system cmake-build-system)
> >       (arguments
> > -     '(#:configure-flags
> > +     `(#:configure-flags
> >          '("-DBUILD_CONFIG=mysql_release"
> >            "-DWITH_SSL=system"
> >            "-DWITH_ZLIB=system"
> > @@ -229,7 +229,9 @@ SQL, Key/Value, XML/XQuery or Java Object storage 
> > for their data model.")
> >                      (lambda _
> >                        ;; Mysql wants boost-1.59.0 specifically
> >                        (substitute* "cmake/boost.cmake"
> > -                                  (("59") "60"))))
> > +                       (("59")
> > +                        ,(match (string-split (package-version boost) 
> > #\.)
> > +                           ((_ minor . _) minor))))))
> >                     (add-after
> >                      'install 'remove-extra-binaries
> >                      (lambda* (#:key outputs #:allow-other-keys)  
> 
> This patch looks good to me.  I changed the `(("59") "60")' construct to
> `(("59") "61")' myself, and that seemed to work.  Your solution is
> better because this will continue to work in the future, plus the
> parallel building is nice.
> 
> Is there anything that requires more work to apply your patch for MySQL
> and then upgrade Boost?  Are there any other packages that break that we
> should look into?

As far as I recall, the only breakages besides mysql that I experienced
were due to reasons outside of the boost upgrade.  I'll try to find my
notes from those builds...

Given that this upgrade forces a rebuild of libreoffice, should it be
applied to core-updates?

`~Eric

Reply via email to