[Rd] Matrix does not build with R trunk since Oct.

Hin-Tak Leung htl10 at users.sourceforge.net
Fri Feb 15 20:13:16 CET 2013


--- On Fri, 15/2/13, Simon Urbanek <simon.urbanek at r-project.org> wrote:

> On Feb 15, 2013, at 1:55 PM, Hin-Tak Leung wrote:
> 
> > Look. I don't see this as "my" problem - as far as I am
> concerned, I have donated my time - and over and over - to
> testing pre-released code. I am not using pre-released code
> for production work. If the released code in 3.0 does not
> work correctly in 6 weeks' time, I just don't upgrade. No
> loss for me there.
> > 
> 
> It works - confirmed by several people. You have a problem,
> but you didn't tell us the specifics of the problem so
> there's nothing we can do.

I do not have a problem. I do not need to spend time regularly testing pre-release code, and I think I should stop.
 
> > I don't know why it is degenerating into another
> distraction about some people's egos.
> > 
> 
> I don't either - it's not productive.
> 
> Cheers,
> Simon
> 
> 
> > --- On Fri, 15/2/13, Simon Urbanek <simon.urbanek at r-project.org>
> wrote:
> > 
> >> On Feb 15, 2013, at 11:36 AM, Hin-Tak
> >> Leung wrote:
> >> 
> >>> --- On Fri, 15/2/13, Simon Urbanek <simon.urbanek at r-project.org>
> >> wrote:
> >>> 
> >>>> On Feb 15, 2013, at 9:11 AM, Hin-Tak
> >>>> Leung wrote:
> >>>> 
> >>>>> Somebody else had written separately
> about this
> >> before,
> >>>> and so have I a couple of months ago. I
> assumed
> >> this will be
> >>>> fixed before the next R. Since R 3.0 is
> supposedly
> >> only 6
> >>>> weeks away, even if it is fixed now it
> doesn't
> >> leave much
> >>>> room for testing. 
> >>>>> 
> >>>>> Anyway neither Matrix 1.0-11 (current)
> nor
> >> 1.0-9 (sept
> >>>> 2012) build with current R trunk.  The
> 
> >> last time
> >>>> it did was 1. 0-9 on 3rd october over 4
> months ago.
> >> So it
> >>>> appears to be due to change inside r trunk
> in sept
> >> or early
> >>>> oct. 
> >>>>> 
> >>>> 
> >>>> No problem here - Matrix 1.0-11 and R-devel
> build
> >> just fine
> >>>> with your flags (tested on Ubuntu 12.10,
> x86_64).
> >>>> 
> >>>> If in doubt, please remove R-devel and
> checkout a
> >> fresh
> >>>> copy. Also FWIW it's a bad practice to
> build inside
> >> the
> >>>> sources - it often causes all sorts of
> problems
> >> when you try
> >>>> to track the sources and stale files are
> probably
> >> what's
> >>>> hitting you.
> >>>> 
> >>>> FWIW: This is likely not the problem
> you're
> >> mentioning, but
> >>>> some recent gcc versions break and LTO is
> also
> >> known to
> >>>> cause issues depending on the compiler
> version, so
> >> tread
> >>>> lightly on the cutting edge.
> >>> 
> >>> 
> >>> Here is a fairly similar post:
> >>> http://r.789695.n4.nabble.com/Build-from-Source-fails-on-Loading-required-package-Matrix-td4640371.html
> >>> 
> >>> The eventual "solution" of that thread seems to
> be
> >> building from tar ball, which is quite beside the
> whole
> >> point of building from svn trunk.
> >>> 
> >> 
> >> And how is that relevant to what I said? Did you
> follow the
> >> advice I sent? If you did and still have an issue,
> post
> >> *exact* details on what you did, what system and
> tools you
> >> are using. 
> >> 
> >> 
> >>> FWIW, it is very unproductive to talk about
> "bad
> >> practice" - in a hand-waving
> undocumented/unsubstantiated
> >> manner
> >> 
> >> Building in sources has two problems: a) the
> content of the
> >> source tree can change so subsequent builds can be
> different
> >> from the clean one - you cannot undo that and b) if
> you
> >> update the sources stale files from previous builds
> can
> >> break the build. 
> >> 
> >> If solving your problems is "unproductive" then I'm
> not
> >> surprised you have them for 4 moths now.
> >> 
> >> 
> >>> - and options that might or might not work. If
> >> "--enable-lto" (or any other options, or build
> within the
> >> dev directory) does not work reliably, it should be
> either
> >> disabled/removed, or documented, or both.
> >> 
> >> R cannot test all aspects of a compiler and detect
> all its
> >> bugs. It is *your* responsibility to provide a
> working
> >> compiler - if you are unwilling to do that, R
> cannot do
> >> anything about that.
> >> 
> >> 
> >>> Anyway, it has not been working for over 4
> months.
> >>> 
> >> 
> >> That is not true, obviously, and I have presented
> a
> >> counter-example. It may not have been working for
> *you* and
> >> it's likely a problem in your setup (given your
> lack of
> >> cooperation there is no way to tell for sure). We
> cannot
> >> prevent user errors. We can try to point people in
> the right
> >> direction, but if they refuse to listen it's on
> their head.
> >> 
> >> 
> >>> You have about 6 weeks before this becomes a
> big
> >> problem - "big" as in "wide-spread".
> >>> 
> >> 
> >> You are yet to show that this is a problem in R at
> all. You
> >> failed to follow the basic instructions in the
> FAQ.
> >> 
> >> Cheers,
> >> Simon
> >> 
> >> 
> >> 
> >>>> Cheers,
> >>>> Simon
> >>>> 
> >>>> 
> >>>>> 
> >>>>> ----------------
> >>>>> Loading required package: Matrix
> >>>>> Error in namespaceExport(ns, exports)
> :
> >> undefined
> >>>> exports: .M.classEnv
> >>>>> Error : require(Matrix) is not TRUE
> >>>>> ERROR: installing package indices
> failed
> >>>>> * removing
> ‘/svn-loc/R/library/Matrix’
> >>>>> * restoring previous
> >> ‘/svn-loc/R/library/Matrix’
> >>>>> make[2]: *** [Matrix.ts] Error 1
> >>>>> make[2]: Leaving directory
> >>>> `/svn-loc/R/src/library/Recommended'
> >>>>> make[1]: *** [recommended-packages]
> Error 2
> >>>>> make[1]: Leaving directory
> >>>> `/svn-loc/R/src/library/Recommended'
> >>>>> make: *** [stamp-recommended] Error 2
> >>>>> ----------------
> >>>>> 
> >>>>> If it matters, here is what r trunk
> built
> >> with:
> >>>>> ./configure --enable-memory-profiling
> >>>> --enable-strict-barrier
> >> --enable-byte-compiled-packages
> >>>> --with-valgrind-instrumentation=2
> --enable-lto
> >>>>> 
> >>>>>
> ______________________________________________
> >>>>> R-devel at r-project.org
> >>>> mailing list
> >>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
> >>>> 
> >>>> 
> >>> 
> >>> 
> >> 
> >> 
> > 
> > 
> 
>



More information about the R-devel mailing list