On 14-01-02 6:09 AM, Olivier BARTHELEMY wrote:
With some additional debug messages in the code, it would seem that when
solve.R calls .Internal(La_solve(..)), mod_do_lapack() is called, but
PRIMVAL(op) should be 100 for La_solve. Instead, it is 0 and thus
La_qr_cmplx is called
That's very strange. The PRIMVAL comes from the big R_FunTab table in
names.c, and it is coded correctly. During initialization it is copied
into the La_solve
object that you're seeing in the function call.
So it looks as though either the table or that object has somehow become
corrupted. Debugging that is a little tricky, but should be doable.
First, work out whether R_FunTab is corrupted or not. If it is, then
set a hardware breakpoint to see when it happened. If not, then you
have to wait until the La_solve primitive is created, then set a
hardware breakpoint on it. Good luck.
Duncan Murdoch
2013/12/30 Olivier BARTHELEMY <barthel...@geovariances.com>
I tried relaunching the build for x64 this time, in a new folder, and
still get the same problem, so it mustn't be something that didn't get
deleted.
According to my first diagnostics with messages in the source, it's
strange. In solve.R, i can see that it will call ".Internal(La_solve(a, b,
tol))". But i never see a message i added right at the start of La_solve()
of Lapack.c. I also diagnosed that the "'a' must be a complex matrix" error
comes from La_qr_cmplx(). It's as if .Internal() called the wrong function
of Lapack.c. I'll try to look more tomorrow, but am not sure how to debug
.Internal()..
2013/12/30 Duncan Murdoch <murdoch.dun...@gmail.com>
On 13-12-30 4:47 AM, Olivier BARTHELEMY wrote:
Ok, i used the procedure in the manual. I think i am almost at the end of
the build process. I am stuck however at the build of grDevices module.
While byte-compiling it, i get the following error :
Error in solve.default(rgb) : 'a' must be a complex matrix
The line of that syntax errror can be found back in make.rgb of
src/library/grDevices/R/convertColor.R
I doubt this file has a syntax error. The only possible cause i can think
of is if the previous rbind that creates rgb returns NULL, but i can't
find
what would cause that.
Any hints on where i could look for the problem?
I've never seen that error, so can't offer much help. Did you delete
everything from your previous unsuccessful build attempts?
Do note that it is not a syntax error, it's an evaluation error. It
would likely have happened during the construction of the colorspaces list,
which calls make.rgb later in that same file. You could insert print() or
message() statements to localize the error, but it's not an error that
should have happened in a valid build.
Duncan Murdoch
I hope this is not too offtopic with the initial subject and the
developmenet mailing list
2013/12/18 Duncan Murdoch <murdoch.dun...@gmail.com>
On 13-12-18 5:24 AM, Olivier BARTHELEMY wrote:
I think this is more suited for the devel mailing list than the help
one.
I'm trying to build R on windows, With Rtools installed, and
configure/make
in R-3.0.2 sources folder from a cygwin console.
This doesn't sound like a good idea. The Rtools are set up for native
Windows builds. If you run configure yourself, you'll be targeting a
Cygwin build -- but that's something we don't support.
What you should do is follow the instructions for native Windows builds
that are given in chapter 3 of the Installation and Administration
manual.
In particular, *do not* run configure.
If you do choose to create a Cygwin build, please make sure it passes
the
tests before you use it. I haven't seen one that does.
Duncan Murdoch
I am stuck at the moment, because the build process tries create
symlinks,
and gcc build fails because the opened files containe the metadata of
the
not working symlink, and not the linked file.
The first problematic files is src/extra/xz/alone_decoder.c, pointing
to
common/alone_decoder.c, but i guess the following buildt files would
have
the same problem.
My configure didn't even detect the symlink cmd off cygwin while
performing
the tests, and i even launched configure with --disable-symlinks, but
their
creationis attmpted anyways.
Is there any quick way to workaround that? And since it's .c or.h
files we
are symlinking here, couldn't we simply do 'eponym' C or h files that
do a
C #include to the relative path, which would be more portable than
symlinks?
--
Olivier BARTHELEMY
+33.1.80.97.26.31
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
