Re: [R-pkg-devel] is Fortran write still strictly forbidden?
Hi Jisca: I have used the write successfully. I’m not sure if this matters or not, but I am using WSL 2 with Ubuntu 22.04 installed. It works fine with R => 4.0. Hope this helps. Sincerely, Erin Erin Hodgess, PhD mailto: erinm.hodg...@gmail.com On Wed, May 8, 2024 at 6:49 PM Jisca Huisman wrote: > Hello, > > I like to use write() in Fortran code to combine text with some integers > & doubles, to pass runtime information to R in a way that is prettier > and more legible than with intpr() & dblepr(). In the past any calls to > write() were strictly forbidden in Fortran code, as apparently it messed > something up internally (I cannot recall the details). But from 'writing > R extensions' it seems that there have been quite a few changes with > respect to support for Fortran code, and it currently reads: > > > 6.5.1 Printing from Fortran > > On many systems Fortran|write|and|print|statements can be used, but the > output may not interleave well with that of C, and may be invisible > onGUIinterfaces. They are not portable and best avoided. > > > To be more specific, would the subroutine below be allowed? Is it needed > to declare R >= 4.0 (?) in the package DESCRIPTION (& then use labelpr() > instead of intpr() ?) Is there an alternative without write() to get the > same result? > > > subroutine Rprint_pretty(iter, x) > integer, intent(IN) :: iter > double precision, intent(IN) :: x > integer :: date_time_values(8), nchar, IntDummy(0) > character(len=8) :: time_now > character(len=200) :: msg_to_R > > call date_and_time(VALUES=date_time_values) > write(time_now, '(i2.2,":",i2.2,":",i2.2)') date_time_values(5:7) > write(msg_to_R, '(a8, " i: ", i5, " value: ", f8.2)') time_now, > iter, x > > nchar = len(trim(msg_to_R)) > call intpr(trim(msg_to_R), nchar, IntDummy, 0) > >end subroutine Rprint_pretty > > > Thanks! > > > [[alternative HTML version deleted]] > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel > [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] OpenCL R packages on CRAN
Hello! What about using WSL on Windows, please? Would that help? Thank you, Sincerely, Erin On Mon, Mar 13, 2023 at 5:25 AM Uwe Ligges wrote: > > > On 13.03.2023 11:43, quirin stier wrote: > > Hi, > > > > I would like to ask what the current situation is regarding R packages > > for computations on the GPU. There are no more official CRAN packages > > using CUDA or OpenCL as foundation. There are only packages providing > > either access to OpenCL, tensorflow or similar and packages using > > directives in C++ via OpenMP. > > > > My aim is to provide an R package using OpenCL. However, as far as I > > know, such package would not run in Windows. Does CRAN accept packages > > which are not compatible with every os? > > CRAN asks for cross plattform code if possible. In some situations where > it is not possible to provide cross plattform code, CRAN also accepts > code that works for many (but not all) plattforms. > > OpenCL and Windows: Why would a package using OpenCL not work on Windows? > We may have difficulties providimg binaries of the package (and checking > it) as corresponding graphics hardware is not available on the > build/check machines, but if possible you shopudl support that users > with the required hardware can compile the package from sources on > Windows, too. > > Best, > Uwe Ligges > > __________ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel > -- Erin Hodgess, PhD mailto: erinm.hodg...@gmail.com [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] multithreading in packages
Yes it does use MPI. You can get the pbd from GitHub, as a backup. Thanks On Sat, Oct 9, 2021 at 2:23 PM Vladimir Dergachev wrote: > > > On Sat, 9 Oct 2021, Erin Hodgess wrote: > > > Have you thought about using C or c++, please? > > Yes, indeed, the core of the package is written in C, with some C++ for > sorting (which turned out to be rather interesting). > > Beyound writing optimized C there are two ways to speed up execution on a > single computer - multithreading and vector instructions. > > Multithreading is easier here, because only one or two libraries are > needed (libgomp or pthread) and because it is often hard to vectorize > operations like sorting, hashing and the like. > > Also, to use vector instructions to full potential one typically needs a > fair bit of black magic which is unlikely to pass CRAN tests. I am having > enough trouble as it is getting a simple flexible array past address > sanitizers. > > > Also, there are packages called pbdDMAT from Drew Schmidt at U of Tenn > which might help. > > Great, thanks for pointing this out ! Looks like pbdDMAT uses mpi. > > Also, it appears this package was removed from CRAN for failing to compile > on macs, which seems rather unfair - I don't know of any clusters running > mac os. > > Vladimir Dergachev -- Erin Hodgess, PhD mailto: erinm.hodg...@gmail.com [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] multithreading in packages
Have you thought about using C or c++, please? Also, there are packages called pbdDMAT from Drew Schmidt at U of Tenn which might help. On Sat, Oct 9, 2021 at 8:39 AM Vladimir Dergachev wrote: > > > On Sat, 9 Oct 2021, Ivan Krylov wrote: > > > В Thu, 7 Oct 2021 21:58:08 -0400 (EDT) > > Vladimir Dergachev пишет: > > > >>* My understanding from reading documentation and source code is > >> that there is no dedicated support in R yet, but there are packages > >> that use multithreading. Are there any plans for multithreading > >> support in future R versions ? > > > > Shared memory multithreading is hard to get right in a memory-safe > > language (e.g. R), but there's the parallel package, which is a part of > > base R, which offers process-based parallelism and may run your code on > > multiple machines at the same time. There's no communication _between_ > > these machines, though. (But I think there's an MPI package on CRAN.) > > Well, the way I planned to use multitheading is to speedup processing of > very large vectors, so one does not have to wait seconds for the command > to return. Same could be done for many built-in R primitives. > > > > >>* pthread or openmp ? I am particularly concerned about > >> interaction with other packages. I have seen that using pthread and > >> openmp libraries simultaneously can result in incorrectly pinned > >> threads. > > > > pthreads-based code could be harder to run on Windows (which is a > > first-class platform for R, expected to be supported by most packages). > > Gábor Csárdi pointed out that R is compiled with mingw on Windows and > has pthread support - something I did not know either. > > > OpenMP should be cross-platform, but Apple compilers are sometimes > > lacking; the latest Apple likely has been solved since I've heard about > > it. If your problem can be made embarrassingly parallel, you're welcome > > to use the parallel package. > > I used parallel before, it is very nice, but R-level only. I am looking > for something to speedup response of individual package functions so they > themselves can be used of part of more complicated code. > > > > >>* control of maximum number of threads. One can default to openmp > >> environment variable, but these might vary between openmp > >> implementations. > > > > Moreover, CRAN-facing tests aren't allowed to consume more than 200% > > CPU, so it's a good idea to leave the number of workers in control of > > the user. According to a reference guide I got from openmp.org, OpenMP > > implementations are expected to understand omp_set_num_threads() and > > the OMP_NUM_THREADS environment variable. > > Oh, this would never be run through CRAN tests, it is meant for data that > is too big for CRAN. > > I seem to remember that the Intel compiler used a different environmental > variable, but it could be this was fixed since the last time I used it. > > best > > Vladimir Dergachev > > > > > -- > > Best regards, > > Ivan > > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel > -- Erin Hodgess, PhD mailto: erinm.hodg...@gmail.com [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [Rd] From .Fortran to .Call?
Will there be any interest in using Coarrays Fortran, please? Thanks, Erin Erin Hodgess, PhD mailto: erinm.hodg...@gmail.com On Wed, Dec 23, 2020 at 10:29 AM Martin Maechler wrote: > >>>>> Balasubramanian Narasimhan > >>>>> on Wed, 23 Dec 2020 08:34:40 -0800 writes: > > > I think it should be pretty easy to fix up SUtools to use the .Call > > instead of .Fortran following along the lines of > > > https://github.com/wrathematics/Romp > > > I too deal with a lot of f77 and so I will most likely finish it > before > > the new year, if not earlier. (Would welcome testers besides myself.) > > > Incidentally, any idea of what the performance hit is, > quantitatively? I > > confess I never paid attention to it myself as most Fortran code I > use > > seems pretty fast, i.e. glmnet. > > > -Naras > > well, glmnet's src/*.f code seems closer to assembly than to > even old fortran 77 style .. > which would not change when calling it via .Call() ... > ;-) > > The performance "hit" of using .Fortran is probably almost only > from the fact .C() and .Fortran() now compulsorily *copy* their > arguments, whereas with .Call() you are enabled to shoot > yourself in both feet .. ;-) > > Martin > > > > > On 12/23/20 3:57 AM, Koenker, Roger W wrote: > >> Thanks to all and best wishes for a better 2021. > >> > >> Unfortunately I remain somewhat confused: > >> > >> o Bill reveals an elegant way to get from my rudimentary > registration setup to > >> one that would explicitly type the C interface functions, > >> > >> o Ivan seems to suggest that there would be no performance gain > from doing this. > >> > >> o Naras’s pcLasso package does use the explicit C typing, but then > uses .Fortran > >> not .Call. > >> > >> o Avi uses .Call and cites the Romp package > https://github.com/wrathematics/Romp > >> where it is asserted that "there is a (nearly) deprecated interface > .Fortran() which you > >> should not use due to its large performance overhead.” > >> > >> As the proverbial naive R (ab)user I’m left wondering: > >> > >> o if I updated my quantreg_init.c file in accordance with Bill’s > suggestion could I > >> then simply change my .Fortran calls to .Call? > >> > >> o and if so, do I need to include ALL the fortran subroutines in > my src directory > >> or only the ones called from R? > >> > >> o and in either case could I really expect to see a significant > performance gain? > >> > >> Finally, perhaps I should stipulate that my fortran is strictly > f77, so no modern features > >> are in play, indeed most of the code is originally written in > ratfor, Brian Kernighan’s > >> dialect from ancient times at Bell Labs. > >> > >> Again, thanks to all for any advice, > >> Roger > >> > >> > >>> On Dec 23, 2020, at 1:11 AM, Avraham Adler < > avraham.ad...@gmail.com> wrote: > >>> > >>> Hello, Ivan. > >>> > >>> I used .Call instead of .Fortran in the Delaporte package [1]. What > >>> helped me out a lot was Drew Schmidt's Romp examples and > descriptions > >>> [2]. If you are more comfortable with the older Fortran interface, > >>> Tomasz Kalinowski has a package which uses Fortran 2018 more > >>> efficiently [3]. I haven't tried this last in practice, however. > >>> > >>> Hope that helps, > >>> > >>> Avi > >>> > >>> [1] > https://urldefense.com/v3/__https://CRAN.R-project.org/package=Delaporte__;!!DZ3fjg!s1-ihrZ9DPUtXpxdIpJPA1VedpZFt12Ahmn4CycOmile_uSahFZnJPn_5KPITBN5NK8$ > >>> [2] > https://urldefense.com/v3/__https://github.com/wrathematics/Romp__;!!DZ3fjg!s1-ihrZ9DPUtXpxdIpJPA1VedpZFt12Ahmn4CycOmile_uSahFZnJPn_5KPISF5aCYs$ > >>> [3] > https://urldefense.com/v3/__https://github.com/t-kalinowski/RFI__;!!DZ3fjg!s1-ihrZ9DPUtXpxdIpJPA1VedpZFt12Ahmn4CycOmile_uSahFZnJPn_5KPIbwXmXqY$ > >>> > >>> Tomasz Kalinowski > >>> > >>> > >>> > >>> On Tue, Dec 22, 2020 at 7:24 PM Balasubramanian Narasimhan > >>> wrote: > >&g
Re: [Rd] From .Fortran to .Call?
edpZFt12Ahmn4CycOmile_uSahFZnJPn_5KPITBN5NK8$ > >>>> [2] > https://urldefense.com/v3/__https://github.com/wrathematics/Romp__;!!DZ3fjg!s1-ihrZ9DPUtXpxdIpJPA1VedpZFt12Ahmn4CycOmile_uSahFZnJPn_5KPISF5aCYs$ > >>>> [3] > https://urldefense.com/v3/__https://github.com/t-kalinowski/RFI__;!!DZ3fjg!s1-ihrZ9DPUtXpxdIpJPA1VedpZFt12Ahmn4CycOmile_uSahFZnJPn_5KPIbwXmXqY$ > >>>> > >>>> Tomasz Kalinowski > >>>> > >>>> > >>>> > >>>> On Tue, Dec 22, 2020 at 7:24 PM Balasubramanian Narasimhan > >>>> wrote: > >>>>> To deal with such Fortran issues in several packages I deal with, I > >>>>> wrote the SUtools package ( > https://urldefense.com/v3/__https://github.com/bnaras/SUtools__;!!DZ3fjg!s1-ihrZ9DPUtXpxdIpJPA1VedpZFt12Ahmn4CycOmile_uSahFZnJPn_5KPIJ5BbDwA$ > ) that you > >>>>> can try. The current version generates the registration assuming > >>>>> implicit Fortran naming conventions though. (I've been meaning to > >>>>> upgrade it to use the gfortran -fc-prototypes-external flag which > should > >>>>> be easy; I might just finish that during these holidays.) > >>>>> > >>>>> There's a vignette as well: > >>>>> > https://urldefense.com/v3/__https://bnaras.github.io/SUtools/articles/SUtools.html__;!!DZ3fjg!s1-ihrZ9DPUtXpxdIpJPA1VedpZFt12Ahmn4CycOmile_uSahFZnJPn_5KPITq9-Quc$ > >>>>> > >>>>> -Naras > >>>>> > >>>>> > >>>>> On 12/19/20 9:53 AM, Ivan Krylov wrote: > >>>>>> On Sat, 19 Dec 2020 17:04:59 + > >>>>>> "Koenker, Roger W" wrote: > >>>>>> > >>>>>>> There are comments in various places, including R-extensions §5.4 > >>>>>>> suggesting that .Fortran is (nearly) deprecated and hinting that > use > >>>>>>> of .Call is more efficient and now preferred for packages. > >>>>>> My understanding of §5.4 and 5.5 is that explicit routine > registration > >>>>>> is what's important for efficiency, and your package already does > that > >>>>>> (i.e. calls R_registerRoutines()). The only two things left to add > >>>>>> would be types (REALSXP/INTSXP/...) and styles (R_ARG_IN, > >>>>>> R_ARG_OUT/...) of the arguments of each subroutine. > >>>>>> > >>>>>> Switching to .Call makes sense if you want to change the interface > of > >>>>>> your native subroutines to accept arbitrary heavily structured SEXPs > >>>>>> (and switching to .External could be useful if you wanted to play > with > >>>>>> evaluation of the arguments). > >>>>>> > >>>>> __ > >>>>> R-devel@r-project.org mailing list > >>>>> > https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/r-devel__;!!DZ3fjg!s1-ihrZ9DPUtXpxdIpJPA1VedpZFt12Ahmn4CycOmile_uSahFZnJPn_5KPIr_nqkqg$ > >> > >> __ > >> R-devel@r-project.org mailing list > >> > https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/r-devel__;!!DZ3fjg!r3_sswU4ZHCe3huoGUy2boX-Vr7aUS-RaExyeh_Rsv8gvGiABcqzvOOKZinGvMnBkW0$ > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Erin Hodgess, PhD mailto: erinm.hodg...@gmail.com [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [R-pkg-devel] Fortran with OpenMP on MACOS
I’m sure that you have done this, but did you set a compiler option of -fopenmp, please? Thanks On Tue, Oct 13, 2020 at 9:35 AM Sergio Ibarra-Espinosa wrote: > Dear List, > > I have a package that was archived ( > > https://cran-archive.r-project.org/web/checks/2020/2020-10-07_check_results_vein.html > ) because I could not solve an issue with OpenMP and Fortran on MACOS. > > I have seen that packages with C add precompilation conditions, for > instance: > > > https://github.com/tesujimath/R-OpenMPController/blob/86bd047e8bfdf3c87877336ff8e2d3b69327fe03/src/omp_set_num_threads_ptr.c#L12 > > #ifdef _OPENMP > omp_set_num_threads(*np); > #endif > > So, I tried adding those lines in #ifdef _OPENMP #endif in > fortran, with the flag -cpp and the MACROS recommended by the R EXTS > manual: > > USE_FC_TO_LINK = > PKG_FFLAGS = $(SHLIB_OPENMP_FFLAGS) *-cpp* > PKG_LIBS = $(SHLIB_OPENMP_FFLAGS) > > But with R CMD Check i got the message: > > Non-portable flags in variable 'PKG_FFLAGS': -cpp > > I would be very grateful if someone provides me some guidelines. Thank you > so much > > Best, Sergio > > > *Sergio Ibarra Espinosa* > Postdoc in Atmospheric Sciences, Universidade de São Paulo > > + <++8617643016295>55 11 934 909 778 | +55 11 974 253 791 > <+55+11+974+253+791> | sergio.iba...@usp.br > > www.sergioibarra.blogspot.com | *Skype*: sergio_ibarra1 > <https://mail.google.com/mail/u/0/#SignatureSanitizer_SafeHtmlFilter_> > Rua do Matão, 1226 > <https://www.google.com/maps/search/Rua+do+Mat%C3%A3o,+1226?entry=gmail=g> > - Cidade Universitária São Paulo-SP - Brasil - 05508-090 > <http://github.com/ibarraespinosa> > <https://zoom.us/j/6527509021?pwd=VmlXQWliR1JSZGtpS0tJR1A2dUZpZz09> > > [[alternative HTML version deleted]] > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel > -- Erin Hodgess, PhD mailto: erinm.hodg...@gmail.com [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Errors in make check in Windows 10 with OpenBLAS
Finally figured it out...I was having "path problems"!
I'm all set here.
Thanks so much for your help
Sincerely,
Erin
Erin Hodgess, PhD
mailto: erinm.hodg...@gmail.com
On Sat, Mar 21, 2020 at 10:29 AM Tomas Kalibera
wrote:
> Maybe the created Riconv.dll is copied over by libiconv at some point
> during your custom build.
>
> Tomas
>
> On 3/21/20 3:58 PM, Erin Hodgess wrote:
>
> Hello again.
>
> So I'm trying to find the place where the GNU iconv comes from. However,
> I looked at output from both the regular build and the custom, and I'm not
> seeing any differences in how win_iconv is generated.
>
> Any suggestions, please?
>
> Custom:
> c:/Rtools/mingw_64/bin/ar crs libtz.a localtime.o registryTZ.o strftime.o
> installing zoneinfo
> making win_iconv.d from win_iconv.c
> c:/Rtools/mingw_64/bin/gcc -std=gnu99 -I../../include -O3 -Wall
> -pedantic -march=native -pipe -c win_iconv.c -o win_iconv.o
> c:/Rtools/mingw_64/bin/gcc -std=gnu99 -shared -o Riconv.dll Riconv.def
> win_iconv.o
>
> Regular:
> c:/Rtools/mingw_64/bin/ar crs libtz.a localtime.o registryTZ.o strftime.o
> installing zoneinfo
> making win_iconv.d from win_iconv.c
> c:/Rtools/mingw_64/bin/gcc -std=gnu99 -I../../include -O3 -Wall
> -pedantic -mtune=core2 -c win_iconv.c -o win_iconv.o
> c:/Rtools/mingw_64/bin/gcc -std=gnu99 -shared -o Riconv.dll Riconv.def
> win_iconv.o
>
> Just the -march=native -pipe
>
> Erin Hodgess, PhD
> mailto: erinm.hodg...@gmail.com
>
>
> On Fri, Mar 20, 2020 at 9:01 AM Tomas Kalibera
> wrote:
>
>> Thanks, so the problem is that your custom build uses GNU libiconv, which
>> does not support codepage 28605. win_iconv, the one shipped with R,
>> supports that code page. win_iconv is a wrapper for the Windows API. Unless
>> you had a special reason not to, I would just recommend to use win_iconv.
>> The "experience" will match the C library conversion calls, which may be
>> used directly in some code at some places, and it is most tested as people
>> normally use it. Still, the problem is not specific to strtrim, just to the
>> example.
>>
>> Best
>> Tomas
>>
>>
>> On 3/20/20 3:27 PM, Erin Hodgess wrote:
>>
>> Here are the results.
>>
>> Looks like enc2native and the iconv settings are different.
>>
>>
>> > #output from custom build
>> > Sys.getlocale()
>> [1] "LC_COLLATE=English_United States.1252;LC_CTYPE=English_United
>> States.1252;LC_MONETARY=English_United
>> States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252"
>> > enc2native("\uff21")
>> [1] ""
>> > enc2native("\u4e2d")
>> [1] ""
>> > Sys.setlocale("LC_CTYPE", "English_United States.28605")
>> [1] "English_United States.28605"
>> > enc2native("\uff21")
>> Error: unsupported conversion from 'UTF-8' in codepage 28605
>> > enc2native("\u4e2d")
>> Error: unsupported conversion from 'UTF-8' in codepage 28605
>> > extSoftVersion()[c("iconv","BLAS")]
>> iconvBLAS
>> "GNU libiconv 1.14" ""
>>
>>
>> > #output from regular build
>> > Sys.getlocale()
>> [1] "LC_COLLATE=English_United States.1252;LC_CTYPE=English_United
>> States.1252;LC_MONETARY=English_United
>> States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252"
>> > enc2native("\uff21")
>> [1] "A"
>> > enc2native("\u4e2d")
>> [1] ""
>> > Sys.setlocale("LC_CTYPE", "English_United States.28605")
>> [1] "English_United States.28605"
>> > enc2native("\uff21")
>> [1] "A"
>> > enc2native("\u4e2d")
>> [1] ""
>> > extSoftVersion()[c("iconv","BLAS")]
>> iconvBLAS
>> "win_iconv" ""
>> >
>>
>> Thanks!
>>
>>
>> Erin Hodgess, PhD
>> mailto: erinm.hodg...@gmail.com
>>
>>
>> On Fri, Mar 20, 2020 at 8:03 AM Tomas Kalibera
>> wrote:
>>
>>> Hi Erin,
>>>
>>> when you are building from sources, you can always uncomment the example
>>> in str.Rd. But it would be good first to find out why it is failing on your
>>> system/build.
>>>
>>> Please run the example in Rgui of the official R 3.6.3 build on your
>>> machine. Does it work there?
>>>
>>>
Re: [R-pkg-devel] Errors in make check in Windows 10 with OpenBLAS
Hello again.
So I'm trying to find the place where the GNU iconv comes from. However, I
looked at output from both the regular build and the custom, and I'm not
seeing any differences in how win_iconv is generated.
Any suggestions, please?
Custom:
c:/Rtools/mingw_64/bin/ar crs libtz.a localtime.o registryTZ.o strftime.o
installing zoneinfo
making win_iconv.d from win_iconv.c
c:/Rtools/mingw_64/bin/gcc -std=gnu99 -I../../include -O3 -Wall -pedantic
-march=native -pipe -c win_iconv.c -o win_iconv.o
c:/Rtools/mingw_64/bin/gcc -std=gnu99 -shared -o Riconv.dll Riconv.def
win_iconv.o
Regular:
c:/Rtools/mingw_64/bin/ar crs libtz.a localtime.o registryTZ.o strftime.o
installing zoneinfo
making win_iconv.d from win_iconv.c
c:/Rtools/mingw_64/bin/gcc -std=gnu99 -I../../include -O3 -Wall -pedantic
-mtune=core2 -c win_iconv.c -o win_iconv.o
c:/Rtools/mingw_64/bin/gcc -std=gnu99 -shared -o Riconv.dll Riconv.def
win_iconv.o
Just the -march=native -pipe
Erin Hodgess, PhD
mailto: erinm.hodg...@gmail.com
On Fri, Mar 20, 2020 at 9:01 AM Tomas Kalibera
wrote:
> Thanks, so the problem is that your custom build uses GNU libiconv, which
> does not support codepage 28605. win_iconv, the one shipped with R,
> supports that code page. win_iconv is a wrapper for the Windows API. Unless
> you had a special reason not to, I would just recommend to use win_iconv.
> The "experience" will match the C library conversion calls, which may be
> used directly in some code at some places, and it is most tested as people
> normally use it. Still, the problem is not specific to strtrim, just to the
> example.
>
> Best
> Tomas
>
>
> On 3/20/20 3:27 PM, Erin Hodgess wrote:
>
> Here are the results.
>
> Looks like enc2native and the iconv settings are different.
>
>
> > #output from custom build
> > Sys.getlocale()
> [1] "LC_COLLATE=English_United States.1252;LC_CTYPE=English_United
> States.1252;LC_MONETARY=English_United
> States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252"
> > enc2native("\uff21")
> [1] ""
> > enc2native("\u4e2d")
> [1] ""
> > Sys.setlocale("LC_CTYPE", "English_United States.28605")
> [1] "English_United States.28605"
> > enc2native("\uff21")
> Error: unsupported conversion from 'UTF-8' in codepage 28605
> > enc2native("\u4e2d")
> Error: unsupported conversion from 'UTF-8' in codepage 28605
> > extSoftVersion()[c("iconv","BLAS")]
> iconvBLAS
> "GNU libiconv 1.14" ""
>
>
> > #output from regular build
> > Sys.getlocale()
> [1] "LC_COLLATE=English_United States.1252;LC_CTYPE=English_United
> States.1252;LC_MONETARY=English_United
> States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252"
> > enc2native("\uff21")
> [1] "A"
> > enc2native("\u4e2d")
> [1] ""
> > Sys.setlocale("LC_CTYPE", "English_United States.28605")
> [1] "English_United States.28605"
> > enc2native("\uff21")
> [1] "A"
> > enc2native("\u4e2d")
> [1] ""
> > extSoftVersion()[c("iconv","BLAS")]
> iconvBLAS
> "win_iconv" ""
> >
>
> Thanks!
>
>
> Erin Hodgess, PhD
> mailto: erinm.hodg...@gmail.com
>
>
> On Fri, Mar 20, 2020 at 8:03 AM Tomas Kalibera
> wrote:
>
>> Hi Erin,
>>
>> when you are building from sources, you can always uncomment the example
>> in str.Rd. But it would be good first to find out why it is failing on your
>> system/build.
>>
>> Please run the example in Rgui of the official R 3.6.3 build on your
>> machine. Does it work there?
>>
>> Please run the following commands in Rgui of the official R 3.6.3 build
>> on the machine and on your custom build. What do you get?
>>
>> Sys.getlocale()
>> enc2native("\uff21")
>> enc2native("\u4e2d")
>> Sys.setlocale("LC_CTYPE", "English_United States.28605")
>> enc2native("\uff21")
>> enc2native("\u4e2d")
>> extSoftVersion()[c("iconv","BLAS")]
>> Thanks,
>> Tomas
>>
>> On 3/20/20 2:35 PM, Erin Hodgess wrote:
>>
>> I was wondering if there is a way to either skip the utilities check and
>> continuing, in order to test the other packages, please.
>>
>> Thanks!
>>
>>
>> On Fri, Mar 20, 2020 at 5:01 AM Martin Maechler <
>> maech...@stat.math.ethz.ch> wrote:
>>
>
Re: [R-pkg-devel] Errors in make check in Windows 10 with OpenBLAS
Thanks for the explanation!
I will re-run everything.
Sincerely,
Erin
On Fri, Mar 20, 2020 at 9:01 AM Tomas Kalibera
wrote:
> Thanks, so the problem is that your custom build uses GNU libiconv, which
> does not support codepage 28605. win_iconv, the one shipped with R,
> supports that code page. win_iconv is a wrapper for the Windows API. Unless
> you had a special reason not to, I would just recommend to use win_iconv.
> The "experience" will match the C library conversion calls, which may be
> used directly in some code at some places, and it is most tested as people
> normally use it. Still, the problem is not specific to strtrim, just to the
> example.
>
> Best
>
> Tomas
>
>
> On 3/20/20 3:27 PM, Erin Hodgess wrote:
>
> Here are the results.
>
> Looks like enc2native and the iconv settings are different.
>
>
> > #output from custom build
> > Sys.getlocale()
> [1] "LC_COLLATE=English_United States.1252;LC_CTYPE=English_United
> States.1252;LC_MONETARY=English_United
> States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252"
> > enc2native("\uff21")
> [1] ""
> > enc2native("\u4e2d")
> [1] ""
> > Sys.setlocale("LC_CTYPE", "English_United States.28605")
> [1] "English_United States.28605"
> > enc2native("\uff21")
> Error: unsupported conversion from 'UTF-8' in codepage 28605
> > enc2native("\u4e2d")
> Error: unsupported conversion from 'UTF-8' in codepage 28605
> > extSoftVersion()[c("iconv","BLAS")]
> iconvBLAS
> "GNU libiconv 1.14" ""
>
>
> > #output from regular build
> > Sys.getlocale()
> [1] "LC_COLLATE=English_United States.1252;LC_CTYPE=English_United
> States.1252;LC_MONETARY=English_United
> States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252"
> > enc2native("\uff21")
> [1] "A"
> > enc2native("\u4e2d")
> [1] ""
> > Sys.setlocale("LC_CTYPE", "English_United States.28605")
> [1] "English_United States.28605"
> > enc2native("\uff21")
> [1] "A"
> > enc2native("\u4e2d")
> [1] ""
> > extSoftVersion()[c("iconv","BLAS")]
> iconvBLAS
> "win_iconv" ""
> >
>
> Thanks!
>
>
> Erin Hodgess, PhD
> mailto: erinm.hodg...@gmail.com
>
>
> On Fri, Mar 20, 2020 at 8:03 AM Tomas Kalibera
> wrote:
>
>> Hi Erin,
>>
>> when you are building from sources, you can always uncomment the example
>> in str.Rd. But it would be good first to find out why it is failing on your
>> system/build.
>>
>> Please run the example in Rgui of the official R 3.6.3 build on your
>> machine. Does it work there?
>>
>> Please run the following commands in Rgui of the official R 3.6.3 build
>> on the machine and on your custom build. What do you get?
>>
>> Sys.getlocale()
>> enc2native("\uff21")
>> enc2native("\u4e2d")
>> Sys.setlocale("LC_CTYPE", "English_United States.28605")
>> enc2native("\uff21")
>> enc2native("\u4e2d")
>> extSoftVersion()[c("iconv","BLAS")]
>> Thanks,
>> Tomas
>>
>> On 3/20/20 2:35 PM, Erin Hodgess wrote:
>>
>> I was wondering if there is a way to either skip the utilities check and
>> continuing, in order to test the other packages, please.
>>
>> Thanks!
>>
>>
>> On Fri, Mar 20, 2020 at 5:01 AM Martin Maechler <
>> maech...@stat.math.ethz.ch> wrote:
>>
>>> >>>>> Erin Hodgesson Thu, 19 Mar 2020 22:44:39 -0600 writes:
>>>
>>> > Hi Tomas and others:
>>> > Here is the session Info. I also used the str example both
>>> without and
>>> > with changing the locale.
>>>
>>> > sI <- sessionInfo()
>>> >> str(sI)
>>> > List of 10
>>> > $ R.version :List of 14
>>> > ..$ platform : chr "x86_64-w64-mingw32"
>>> > ..$ arch : chr "x86_64"
>>> > ..$ os: chr "mingw32"
>>> > ..$ system: chr "x86_64, mingw32"
>>> > ..$ status: chr ""
>>> > ..$ major : chr "3"
>>> > ..$ minor : chr "6.3&q
Re: [R-pkg-devel] Errors in make check in Windows 10 with OpenBLAS
And the example runs just fine on the regular build.
Thanks
Erin Hodgess, PhD
mailto: erinm.hodg...@gmail.com
On Fri, Mar 20, 2020 at 8:03 AM Tomas Kalibera
wrote:
> Hi Erin,
>
> when you are building from sources, you can always uncomment the example
> in str.Rd. But it would be good first to find out why it is failing on your
> system/build.
>
> Please run the example in Rgui of the official R 3.6.3 build on your
> machine. Does it work there?
>
> Please run the following commands in Rgui of the official R 3.6.3 build on
> the machine and on your custom build. What do you get?
>
> Sys.getlocale()
> enc2native("\uff21")
> enc2native("\u4e2d")
> Sys.setlocale("LC_CTYPE", "English_United States.28605")
> enc2native("\uff21")
> enc2native("\u4e2d")
> extSoftVersion()[c("iconv","BLAS")]
> Thanks,
> Tomas
>
> On 3/20/20 2:35 PM, Erin Hodgess wrote:
>
> I was wondering if there is a way to either skip the utilities check and
> continuing, in order to test the other packages, please.
>
> Thanks!
>
>
> On Fri, Mar 20, 2020 at 5:01 AM Martin Maechler <
> maech...@stat.math.ethz.ch> wrote:
>
>> >>>>> Erin Hodgesson Thu, 19 Mar 2020 22:44:39 -0600 writes:
>>
>> > Hi Tomas and others:
>> > Here is the session Info. I also used the str example both
>> without and
>> > with changing the locale.
>>
>> > sI <- sessionInfo()
>> >> str(sI)
>> > List of 10
>> > $ R.version :List of 14
>> > ..$ platform : chr "x86_64-w64-mingw32"
>> > ..$ arch : chr "x86_64"
>> > ..$ os: chr "mingw32"
>> > ..$ system: chr "x86_64, mingw32"
>> > ..$ status: chr ""
>> > ..$ major : chr "3"
>> > ..$ minor : chr "6.3"
>> > ..$ year : chr "2020"
>> > ..$ month : chr "02"
>> > ..$ day : chr "29"
>> > ..$ svn rev : chr "77875"
>> > ..$ language : chr "R"
>> > ..$ version.string: chr "R version 3.6.3 (2020-02-29)"
>> > ..$ nickname : chr "Holding the Windsock"
>> > $ platform : chr "x86_64-w64-mingw32/x64 (64-bit)"
>> > $ locale: chr "LC_COLLATE=English_United
>> > States.1252;LC_CTYPE=English_United
>> States.1252;LC_MONETARY=English_United
>> > States.125"| __truncated__
>> > $ running : chr "Windows 10 x64 (build 18362)"
>> > $ RNGkind : chr [1:3] "Mersenne-Twister" "Inversion" "Rejection"
>> > $ basePkgs : chr [1:7] "stats" "graphics" "grDevices" "utils" ...
>> > $ loadedOnly:List of 1
>> > ..$ compiler:List of 9
>> > .. ..$ Package: chr "compiler"
>> > .. ..$ Version: chr "3.6.3"
>> > .. ..$ Priority : chr "base"
>> > .. ..$ Title : chr "The R Compiler Package"
>> > .. ..$ Author : chr "Luke Tierney "
>> > .. ..$ Maintainer : chr "R Core Team "
>> > .. ..$ Description: chr "Byte code compiler for R."
>> > .. ..$ License: chr "Part of R 3.6.3"
>> > .. ..$ Built : chr "R 3.6.3; ; 2020-03-20 04:29:00 UTC;
>> windows"
>> > .. ..- attr(*, "class")= chr "packageDescription"
>> > .. ..- attr(*, "file")= chr
>> > "c:/newtimeR/R-3.6.3/library/compiler/Meta/package.rds"
>> > $ matprod : chr "default"
>> > $ BLAS : chr ""
>> > $ LAPACK: chr ""
>> > - attr(*, "class")= chr "sessionInfo"
>>
>>
>> > Running the str example WITHOUT changing the locale:
>> >> ## Truncation behavior (<-> correct width measurement) for "long"
>> > non-ASCII:
>> >> idx <- c(65313:65338, 65345:65350)
>> >> fwch <- intToUtf8(idx) # full width character string: each has
>> width 2
>> >> ch <- strtrim(paste(LETTERS, collapse="._"), 64)
>> >> (ncc <- c(c.ch = nchar(ch), w.ch = ncha
Re: [R-pkg-devel] Errors in make check in Windows 10 with OpenBLAS
Here are the results.
Looks like enc2native and the iconv settings are different.
> #output from custom build
> Sys.getlocale()
[1] "LC_COLLATE=English_United States.1252;LC_CTYPE=English_United
States.1252;LC_MONETARY=English_United
States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252"
> enc2native("\uff21")
[1] ""
> enc2native("\u4e2d")
[1] ""
> Sys.setlocale("LC_CTYPE", "English_United States.28605")
[1] "English_United States.28605"
> enc2native("\uff21")
Error: unsupported conversion from 'UTF-8' in codepage 28605
> enc2native("\u4e2d")
Error: unsupported conversion from 'UTF-8' in codepage 28605
> extSoftVersion()[c("iconv","BLAS")]
iconvBLAS
"GNU libiconv 1.14" ""
> #output from regular build
> Sys.getlocale()
[1] "LC_COLLATE=English_United States.1252;LC_CTYPE=English_United
States.1252;LC_MONETARY=English_United
States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252"
> enc2native("\uff21")
[1] "A"
> enc2native("\u4e2d")
[1] ""
> Sys.setlocale("LC_CTYPE", "English_United States.28605")
[1] "English_United States.28605"
> enc2native("\uff21")
[1] "A"
> enc2native("\u4e2d")
[1] ""
> extSoftVersion()[c("iconv","BLAS")]
iconvBLAS
"win_iconv" ""
>
Thanks!
Erin Hodgess, PhD
mailto: erinm.hodg...@gmail.com
On Fri, Mar 20, 2020 at 8:03 AM Tomas Kalibera
wrote:
> Hi Erin,
>
> when you are building from sources, you can always uncomment the example
> in str.Rd. But it would be good first to find out why it is failing on your
> system/build.
>
> Please run the example in Rgui of the official R 3.6.3 build on your
> machine. Does it work there?
>
> Please run the following commands in Rgui of the official R 3.6.3 build on
> the machine and on your custom build. What do you get?
>
> Sys.getlocale()
> enc2native("\uff21")
> enc2native("\u4e2d")
> Sys.setlocale("LC_CTYPE", "English_United States.28605")
> enc2native("\uff21")
> enc2native("\u4e2d")
> extSoftVersion()[c("iconv","BLAS")]
> Thanks,
> Tomas
>
> On 3/20/20 2:35 PM, Erin Hodgess wrote:
>
> I was wondering if there is a way to either skip the utilities check and
> continuing, in order to test the other packages, please.
>
> Thanks!
>
>
> On Fri, Mar 20, 2020 at 5:01 AM Martin Maechler <
> maech...@stat.math.ethz.ch> wrote:
>
>> >>>>> Erin Hodgesson Thu, 19 Mar 2020 22:44:39 -0600 writes:
>>
>> > Hi Tomas and others:
>> > Here is the session Info. I also used the str example both
>> without and
>> > with changing the locale.
>>
>> > sI <- sessionInfo()
>> >> str(sI)
>> > List of 10
>> > $ R.version :List of 14
>> > ..$ platform : chr "x86_64-w64-mingw32"
>> > ..$ arch : chr "x86_64"
>> > ..$ os: chr "mingw32"
>> > ..$ system: chr "x86_64, mingw32"
>> > ..$ status: chr ""
>> > ..$ major : chr "3"
>> > ..$ minor : chr "6.3"
>> > ..$ year : chr "2020"
>> > ..$ month : chr "02"
>> > ..$ day : chr "29"
>> > ..$ svn rev : chr "77875"
>> > ..$ language : chr "R"
>> > ..$ version.string: chr "R version 3.6.3 (2020-02-29)"
>> > ..$ nickname : chr "Holding the Windsock"
>> > $ platform : chr "x86_64-w64-mingw32/x64 (64-bit)"
>> > $ locale: chr "LC_COLLATE=English_United
>> > States.1252;LC_CTYPE=English_United
>> States.1252;LC_MONETARY=English_United
>> > States.125"| __truncated__
>> > $ running : chr "Windows 10 x64 (build 18362)"
>> > $ RNGkind : chr [1:3] "Mersenne-Twister" "Inversion" "Rejection"
>> > $ basePkgs : chr [1:7] "stats" "graphics" "grDevices" "utils" ...
>> > $ loadedOnly:List of 1
>> > ..$ compiler:List of 9
>> > .. ..$ Package: chr "compiler"
>> > .. ..$ Version: chr
Re: [R-pkg-devel] Errors in make check in Windows 10 with OpenBLAS
Great idea!
Thanks
On Fri, Mar 20, 2020 at 8:03 AM Tomas Kalibera
wrote:
> Hi Erin,
>
> when you are building from sources, you can always uncomment the example
> in str.Rd. But it would be good first to find out why it is failing on your
> system/build.
>
> Please run the example in Rgui of the official R 3.6.3 build on your
> machine. Does it work there?
>
> Please run the following commands in Rgui of the official R 3.6.3 build on
> the machine and on your custom build. What do you get?
>
> Sys.getlocale()
> enc2native("\uff21")
> enc2native("\u4e2d")
> Sys.setlocale("LC_CTYPE", "English_United States.28605")
> enc2native("\uff21")
> enc2native("\u4e2d")
> extSoftVersion()[c("iconv","BLAS")]
> Thanks,
> Tomas
>
> On 3/20/20 2:35 PM, Erin Hodgess wrote:
>
> I was wondering if there is a way to either skip the utilities check and
> continuing, in order to test the other packages, please.
>
> Thanks!
>
>
> On Fri, Mar 20, 2020 at 5:01 AM Martin Maechler <
> maech...@stat.math.ethz.ch> wrote:
>
>> >>>>> Erin Hodgesson Thu, 19 Mar 2020 22:44:39 -0600 writes:
>>
>> > Hi Tomas and others:
>> > Here is the session Info. I also used the str example both
>> without and
>> > with changing the locale.
>>
>> > sI <- sessionInfo()
>> >> str(sI)
>> > List of 10
>> > $ R.version :List of 14
>> > ..$ platform : chr "x86_64-w64-mingw32"
>> > ..$ arch : chr "x86_64"
>> > ..$ os: chr "mingw32"
>> > ..$ system: chr "x86_64, mingw32"
>> > ..$ status: chr ""
>> > ..$ major : chr "3"
>> > ..$ minor : chr "6.3"
>> > ..$ year : chr "2020"
>> > ..$ month : chr "02"
>> > ..$ day : chr "29"
>> > ..$ svn rev : chr "77875"
>> > ..$ language : chr "R"
>> > ..$ version.string: chr "R version 3.6.3 (2020-02-29)"
>> > ..$ nickname : chr "Holding the Windsock"
>> > $ platform : chr "x86_64-w64-mingw32/x64 (64-bit)"
>> > $ locale: chr "LC_COLLATE=English_United
>> > States.1252;LC_CTYPE=English_United
>> States.1252;LC_MONETARY=English_United
>> > States.125"| __truncated__
>> > $ running : chr "Windows 10 x64 (build 18362)"
>> > $ RNGkind : chr [1:3] "Mersenne-Twister" "Inversion" "Rejection"
>> > $ basePkgs : chr [1:7] "stats" "graphics" "grDevices" "utils" ...
>> > $ loadedOnly:List of 1
>> > ..$ compiler:List of 9
>> > .. ..$ Package: chr "compiler"
>> > .. ..$ Version: chr "3.6.3"
>> > .. ..$ Priority : chr "base"
>> > .. ..$ Title : chr "The R Compiler Package"
>> > .. ..$ Author : chr "Luke Tierney "
>> > .. ..$ Maintainer : chr "R Core Team "
>> > .. ..$ Description: chr "Byte code compiler for R."
>> > .. ..$ License: chr "Part of R 3.6.3"
>> > .. ..$ Built : chr "R 3.6.3; ; 2020-03-20 04:29:00 UTC;
>> windows"
>> > .. ..- attr(*, "class")= chr "packageDescription"
>> > .. ..- attr(*, "file")= chr
>> > "c:/newtimeR/R-3.6.3/library/compiler/Meta/package.rds"
>> > $ matprod : chr "default"
>> > $ BLAS : chr ""
>> > $ LAPACK: chr ""
>> > - attr(*, "class")= chr "sessionInfo"
>>
>>
>> > Running the str example WITHOUT changing the locale:
>> >> ## Truncation behavior (<-> correct width measurement) for "long"
>> > non-ASCII:
>> >> idx <- c(65313:65338, 65345:65350)
>> >> fwch <- intToUtf8(idx) # full width character string: each has
>> width 2
>> >> ch <- strtrim(paste(LETTERS, collapse="._"), 64)
>> >> (ncc <- c(c.ch = nchar(ch), w.ch = nchar(ch, "w"),
>> > + c.fw = nchar(fwch), w.fw = nchar
Re: [R-pkg-devel] Errors in make check in Windows 10 with OpenBLAS
I was wondering if there is a way to either skip the utilities check and continuing, in order to test the other packages, please. Thanks! On Fri, Mar 20, 2020 at 5:01 AM Martin Maechler wrote: > >>>>> Erin Hodgesson Thu, 19 Mar 2020 22:44:39 -0600 writes: > > > Hi Tomas and others: > > Here is the session Info. I also used the str example both without > and > > with changing the locale. > > > sI <- sessionInfo() > >> str(sI) > > List of 10 > > $ R.version :List of 14 > > ..$ platform : chr "x86_64-w64-mingw32" > > ..$ arch : chr "x86_64" > > ..$ os: chr "mingw32" > > ..$ system: chr "x86_64, mingw32" > > ..$ status: chr "" > > ..$ major : chr "3" > > ..$ minor : chr "6.3" > > ..$ year : chr "2020" > > ..$ month : chr "02" > > ..$ day : chr "29" > > ..$ svn rev : chr "77875" > > ..$ language : chr "R" > > ..$ version.string: chr "R version 3.6.3 (2020-02-29)" > > ..$ nickname : chr "Holding the Windsock" > > $ platform : chr "x86_64-w64-mingw32/x64 (64-bit)" > > $ locale: chr "LC_COLLATE=English_United > > States.1252;LC_CTYPE=English_United > States.1252;LC_MONETARY=English_United > > States.125"| __truncated__ > > $ running : chr "Windows 10 x64 (build 18362)" > > $ RNGkind : chr [1:3] "Mersenne-Twister" "Inversion" "Rejection" > > $ basePkgs : chr [1:7] "stats" "graphics" "grDevices" "utils" ... > > $ loadedOnly:List of 1 > > ..$ compiler:List of 9 > > .. ..$ Package: chr "compiler" > > .. ..$ Version: chr "3.6.3" > > .. ..$ Priority : chr "base" > > .. ..$ Title : chr "The R Compiler Package" > > .. ..$ Author : chr "Luke Tierney " > > .. ..$ Maintainer : chr "R Core Team " > > .. ..$ Description: chr "Byte code compiler for R." > > .. ..$ License: chr "Part of R 3.6.3" > > .. ..$ Built : chr "R 3.6.3; ; 2020-03-20 04:29:00 UTC; > windows" > > .. ..- attr(*, "class")= chr "packageDescription" > > .. ..- attr(*, "file")= chr > > "c:/newtimeR/R-3.6.3/library/compiler/Meta/package.rds" > > $ matprod : chr "default" > > $ BLAS : chr "" > > $ LAPACK: chr "" > > - attr(*, "class")= chr "sessionInfo" > > > > Running the str example WITHOUT changing the locale: > >> ## Truncation behavior (<-> correct width measurement) for "long" > > non-ASCII: > >> idx <- c(65313:65338, 65345:65350) > >> fwch <- intToUtf8(idx) # full width character string: each has > width 2 > >> ch <- strtrim(paste(LETTERS, collapse="._"), 64) > >> (ncc <- c(c.ch = nchar(ch), w.ch = nchar(ch, "w"), > > + c.fw = nchar(fwch), w.fw = nchar(fwch, "w"))) > > c.ch w.ch c.fw w.fw > > 64 64 32 64 > >> stopifnot(unname(ncc) == c(64,64, 32, 64)) > >> ## nchar.max: 1st line needs an increase of 2 in order to see 1 > (in > > UTF-$ > >> invisible(lapply(60:66, function(N) str(fwch, nchar.max = N))) > > chr " > chr " > chr " > chr " > chr " > chr ""| > __truncated__ > > chr "<"| > __truncated__ > >> invisible(lapply(60:66, function(N) str( ch , nchar.max = N))) # "1 > is 1" > > he$ > > chr "A._B._C._D._E._F._G._H._I._J._K._L._M._N._O"| __truncated__ > > chr "A._B._C._D._E._F._G._H._I._J._K._L._M._N._O."| __truncated__ > > chr "A._B._C._D._E._F._G._H._I._J._K._L._M._N._O._"| __truncated__ > > chr "A._B._C._D._E._F._G._H._I._J._K._L._M._N._O._P"| __truncated__ > > chr "A._B._C._D._E._F._G._H._I._J._K._L._M._N._O._P."| __truncated__ > > chr "A._B._C._D._E._F._G._H._I._J._K._L._M._N._O._P._"| > __truncated__ >
Re: [R-pkg-devel] Errors in make check in Windows 10 with OpenBLAS
Hi Tomas and others:
Here is the session Info. I also used the str example both without and
with changing the locale.
sI <- sessionInfo()
> str(sI)
List of 10
$ R.version :List of 14
..$ platform : chr "x86_64-w64-mingw32"
..$ arch : chr "x86_64"
..$ os: chr "mingw32"
..$ system: chr "x86_64, mingw32"
..$ status: chr ""
..$ major : chr "3"
..$ minor : chr "6.3"
..$ year : chr "2020"
..$ month : chr "02"
..$ day : chr "29"
..$ svn rev : chr "77875"
..$ language : chr "R"
..$ version.string: chr "R version 3.6.3 (2020-02-29)"
..$ nickname : chr "Holding the Windsock"
$ platform : chr "x86_64-w64-mingw32/x64 (64-bit)"
$ locale: chr "LC_COLLATE=English_United
States.1252;LC_CTYPE=English_United States.1252;LC_MONETARY=English_United
States.125"| __truncated__
$ running : chr "Windows 10 x64 (build 18362)"
$ RNGkind : chr [1:3] "Mersenne-Twister" "Inversion" "Rejection"
$ basePkgs : chr [1:7] "stats" "graphics" "grDevices" "utils" ...
$ loadedOnly:List of 1
..$ compiler:List of 9
.. ..$ Package: chr "compiler"
.. ..$ Version: chr "3.6.3"
.. ..$ Priority : chr "base"
.. ..$ Title : chr "The R Compiler Package"
.. ..$ Author : chr "Luke Tierney "
.. ..$ Maintainer : chr "R Core Team "
.. ..$ Description: chr "Byte code compiler for R."
.. ..$ License: chr "Part of R 3.6.3"
.. ..$ Built : chr "R 3.6.3; ; 2020-03-20 04:29:00 UTC; windows"
.. ..- attr(*, "class")= chr "packageDescription"
.. ..- attr(*, "file")= chr
"c:/newtimeR/R-3.6.3/library/compiler/Meta/package.rds"
$ matprod : chr "default"
$ BLAS : chr ""
$ LAPACK: chr ""
- attr(*, "class")= chr "sessionInfo"
Running the str example WITHOUT changing the locale:
> ## Truncation behavior (<-> correct width measurement) for "long"
non-ASCII:
> idx <- c(65313:65338, 65345:65350)
> fwch <- intToUtf8(idx) # full width character string: each has width 2
> ch <- strtrim(paste(LETTERS, collapse="._"), 64)
> (ncc <- c(c.ch = nchar(ch), w.ch = nchar(ch, "w"),
+ c.fw = nchar(fwch), w.fw = nchar(fwch, "w")))
c.ch w.ch c.fw w.fw
64 64 32 64
> stopifnot(unname(ncc) == c(64,64, 32, 64))
> ## nchar.max: 1st line needs an increase of 2 in order to see 1 (in
UTF-$
> invisible(lapply(60:66, function(N) str(fwch, nchar.max = N)))
chr ""| __truncated__
chr "<"| __truncated__
> invisible(lapply(60:66, function(N) str( ch , nchar.max = N))) # "1 is 1"
he$
chr "A._B._C._D._E._F._G._H._I._J._K._L._M._N._O"| __truncated__
chr "A._B._C._D._E._F._G._H._I._J._K._L._M._N._O."| __truncated__
chr "A._B._C._D._E._F._G._H._I._J._K._L._M._N._O._"| __truncated__
chr "A._B._C._D._E._F._G._H._I._J._K._L._M._N._O._P"| __truncated__
chr "A._B._C._D._E._F._G._H._I._J._K._L._M._N._O._P."| __truncated__
chr "A._B._C._D._E._F._G._H._I._J._K._L._M._N._O._P._"| __truncated__
chr "A._B._C._D._E._F._G._H._I._J._K._L._M._N._O._P._Q._R._S._T._U._V"
>
Running the str example WITH changing the locale:
oloc <- Sys.getlocale("LC_CTYPE")
> mbyte.lc <- if(.Platform$OS.type == "windows")
+ "English_United States.28605" else "en_GB.UTF-8"
> try(Sys.setlocale("LC_CTYPE", mbyte.lc))
[1] "English_United States.28605"
> ## Truncation behavior (<-> correct width measurement) for "long"
non-ASCII:
> idx <- c(65313:65338, 65345:65350)
> fwch <- intToUtf8(idx) # full width character string: each has width 2
> ch <- strtrim(paste(LETTERS, collapse="._"), 64)
> (ncc <- c(c.ch = nchar(ch), w.ch = nchar(ch, "w"),
+ c.fw = nchar(fwch), w.fw = nchar(fwch, "w")))
c.ch w.ch c.fw w.fw
64 64 32 64
> stopifnot(unname(ncc) == c(64,64, 32, 64))
> ## nchar.max: 1st line needs an increase of 2 in order to see 1 (in
UTF-$
> invisible(lapply(60:66, function(N) str(fwch, nchar.max = N)))
Error in strtrim(x.lrg, nchar.max - nc) :
unsupported conversion from 'UTF-8' in codepage 28605
> invisible(lapply(60:66, function(N) str( ch , nchar.max = N))) # "1 is 1"
he$
chr "A._B._C._D._E._F._G._H._I._J._K._L._M._N._O"| __truncated__
chr "A._B._C._D._E._F._G._H._I._J._K._L._M._N._O.&
[R-pkg-devel] Errors in make check in Windows 10 with OpenBLAS
Hello everyone:
I have built the latest version of the OpenBLAS on my Windows 10 machine.
When I run make distribution in R, everything is fine.
However, when I run make check all, I get the following error:
C:\newtimeR\R-3.6.3\src\gnuwin32>make check-all
Testing examples for package 'base'
Testing examples for package 'tools'
comparing 'tools-Ex.Rout' to 'tools-Ex.Rout.save' ... OK
Testing examples for package 'utils'
Error: testing 'utils' failed
Execution halted
make[3]: *** [Makefile.win:29: test-Examples-Base] Error 1
make[2]: *** [Makefile.common:185: test-Examples] Error 2
make[1]: *** [Makefile.common:171: test-all-basics] Error 1
make: *** [Makefile:324: check-all] Error 2
And here is the section from the .Rout.fail for utils:
> ## Multibyte characters in strings (in multibyte locales):
> oloc <- Sys.getlocale("LC_CTYPE")
> mbyte.lc <- if(.Platform$OS.type == "windows")
+ "English_United States.28605" else "en_GB.UTF-8"
> try(Sys.setlocale("LC_CTYPE", mbyte.lc))
[1] "English_United States.28605"
> ## Truncation behavior (<-> correct width measurement) for "long"
non-ASCII:
> idx <- c(65313:65338, 65345:65350)
> fwch <- intToUtf8(idx) # full width character string: each has width 2
> ch <- strtrim(paste(LETTERS, collapse="._"), 64)
> (ncc <- c(c.ch = nchar(ch), w.ch = nchar(ch, "w"),
+ c.fw = nchar(fwch), w.fw = nchar(fwch, "w")))
c.ch w.ch c.fw w.fw
64 64 32 64
> stopifnot(unname(ncc) == c(64,64, 32, 64))
> ## nchar.max: 1st line needs an increase of 2 in order to see 1 (in
UTF-8!):
> invisible(lapply(60:66, function(N) str(fwch, nchar.max = N)))
Error in strtrim(x.lrg, nchar.max - nc) :
unsupported conversion from 'UTF-8' in codepage 28605
Calls: lapply ... FUN -> str -> str.default -> maybe_truncate -> strtrim
Execution halted
Has anyone run into this before, please?
If I run this line-by-line starting at the "idx <-", things are fine.
I also compiled R from source without the OpenBLAS, and it was fine.
Thanks for any suggestions.
Sincerely,
Erin
Erin Hodgess, PhD
mailto: erinm.hodg...@gmail.com
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Using FORTRAN libraries and compiler options
Hello! Have you tried compiling with the -lblas -llapack options, please? Then you can use the appropriate subroutine. Thanks, Erin On Mon, Nov 11, 2019 at 9:40 AM Rampal S. Etienne wrote: > Hello, > > I am using FORTRAN code with the deSolve package. However, the code > still runs slowly. Googling tells me that there are two options to speed > up my code: > > 1. Compile with option -O3 > > 2. Use the library dgemm. > > I understand that this can be set in makevars. However, as I have > limited experience with FORTRAN (never loaded libraries or set compiling > options), I was wondering whether anyone can give me a hint on how to > set this. I have just a single FORTRAN file (with multiple subroutines). > > Cheers, Rampal > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel > -- Erin Hodgess, PhD mailto: erinm.hodg...@gmail.com [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [Rd] Problem with compiling OpenBLAS to work with R
I actually figured it out. I went back in any changed the mean difference from 2-e12 to 5e-12. Thanks, Erin Erin Hodgess, PhD mailto: erinm.hodg...@gmail.com On Mon, Mar 4, 2019 at 2:10 AM Martin Maechler wrote: > >>>>> Erin Hodgess > >>>>> on Fri, 1 Mar 2019 12:30:35 -0700 writes: > > > Yay! I re-installed everything and got through "Make > > distribution"! I have one more question, please: I am > > running the make check-all. I have an error at reg-1d. > > It stops the process. However, the mean difference (as > > per the file) is 2.0e-12. I'm ok with that. How do I > > bypass this, please? > > If you'd be really precise in your report (use correct file > names; show the exact error message + context lines of the *.Rout.fail > file) I could help you. > > Note (by the way) that this may be yet another example showing > that OpenBLAS may be faster but less accurate than the > (plain+ minor tweaks) version of BLAS that ships with R. > > Martin > > > Thanks, Erin > > > Erin Hodgess, PhD mailto: erinm.hodg...@gmail.com > > > > On Wed, Feb 27, 2019 at 10:22 PM Avraham Adler > > wrote: > > >> I believe that repo just follows the directions on my > >> blog. Without seeing Dr. Hodges’s code, my initial > >> concern is the many references to Cygwin. My method > >> specifically does not use Cygwin but MSYS2 and > >> Mingw64/Rtools35. That will likely change to solely > >> Rtools40 once R3.6 is released due to the Msys system > >> being built in to it. > >> > >> There may be some library conflicts between Cygwin and > >> msys2/mingw64. If possible, my suggestion would be > >> uninstall everything and then just install msys2 (and add > >> in make after you to the first msys update) and rtools35. > >> Then there should be no conflicting libraries. > >> > >> Thanks, > >> > >> Avi > >> > >> On Thu, Feb 28, 2019 at 12:11 AM Kenny Bell > >> wrote: > >> > >>> This person has had apparent success - you could follow > >>> what they did or just download their product (with > >>> appropriate caution downloading a random .exe). > >>> > >>> https://github.com/thequackdaddy/R-OpenBLAS > >>> > >>> On Thu, Feb 28, 2019 at 6:28 AM Erin Hodgess > >>> wrote: > >>> > >>> > Hello! > >>> > > >>> > I'm not sure if this is the right place to post this, > >>> so apologies > in advance if I'm not in the right list. > >>> > > >>> > I downloaded the OpenBLAS and am following Avraham > >>> Adler's great > instructions. However, when I run make, > >>> things go well to a certain point, > and then go bad: > >>> > > >>> > make > [snip] > >>> > > >>> > touch cygopenblas_haswellp-r0.3.5.a > make -j 1 -C > >>> test all > make[1]: Entering directory > > >>> '/home/erinm/OPB_HOME/xianyi-OpenBLAS-eebc189/test' > > >>> gfortran -O2 -Wall -frecursive -m64 -mavx2 -o sblat1 > >>> sblat1.o > ../cygopenblas_haswellp-r0.3.5.a > >>> -L/usr/lib/gcc/x86_64-pc-msys/7.3.0 > >>> > > >>> > -L/usr/lib/gcc/x86_64-pc-msys/7.3.0/../../../../x86_64-pc-msys/lib/../lib > >>> > -L/usr/lib/../lib > > >>> -L/usr/lib/gcc/x86_64-pc-msys/7.3.0/../../../../x86_64-pc-msys/lib > >>> > -L/usr/lib/w32api -lmsys-2.0 > > >>> > D:/msys64/usr/lib/../lib/libpthread.a(t-d001088.o):fake:(.text+0x2): > >>> > undefined reference to `__imp_pthread_mutex_destroy' > > >>> > D:/msys64/usr/lib/../lib/libpthread.a(t-d001090.o):fake:(.text+0x2): > >>> > undefined reference to `__imp_pthread_mutex_init' > > >>> > D:/msys64/usr/lib/../lib/libpthread.a(t-d001091.o):fake:(.text+0x2): > >>> > undefined reference to `__imp_pthread_mutex_lock' > > >>> > D:/msys64/usr/lib/../lib/libpthread.a(t-d001094.o):fake:(.text+0x2): > >>> > undefined reference to `__imp_pthread_mutex_trylock' > > >>> > D:/msys64/usr/lib/../lib/libpthread.a(t-d001095.o):fake:(.text+0x2): > >
[Rd] Using a different compiler when creating a package on Windows
Hello! I am updating to the R-devel version as of 2/28 and recompiling with OpenBLAS. I got that to compile nicely. I am now updating a package that uses the OpenBLAS and the PGI compiler, which has changed too. I just changed the path names in Makevars. Here is the Makevars file. FC= d:/PGI/win64/18.10/bin/pgf90 F77= d:/PGI/win64/18.10/bin/pgf90 CC = d:/PGI/win64/18.10/bin/pgcc FFLAGS= -Ld:/PGI/win64/18.10/bin/pgf90.dll -Ld:/PGI/win64/18.10/bin/pgc14.dll FLIBS= -Ld:/PGI/win64/18.10/bin/pgf90.dll -Ld:/PGI/win64/18.10/bin/pgc14.dll PKG_LIBS = $(LAPACK_LIBS) $(BLAS_LIBS) $(FLIBS) MPI_FFLAGS= -Mmpi=msmpi SHLIB_FFLAGS= -Mmakedll CUDA_FFLAGS=-acc -Minfo=accel -Mlarge_arrays -Ld:/PGI/win64/18.10/bin/pgf90.dll -Ld:/PGI/win64/18.10/bin/pgc14.dll DLLCUDA_FFLAGS=-ta=tesla:nordc -Ld:/PGI/win64/18.10/lib/acc_init_link_cuda.obj -Ld:/PGI/win64/18.10/lib/libaccapi.lib -Ld:/PGI/win64/18.10/lib/libaccg.lib -Ld:/PGI/win64/18.10/lib/libaccn.lib -Ld:/PGI/win64/18.10/lib/libaccg2.lib -Ld:/PGI/win64/18.10/lib/libcudadevice.lib -Ld:/PGI/win64/18.10/lib/pgc14.lib -Ld:/PGI/win64/18.10/lib/libnspgc.lib -defaultlib:legacy_stdio_definitions -defaultlib:oldnames -Ld:/PGI/win64/18.10/bin/pgf90.dll -Ld:/PGI/win64/18.10/bin/pgc14.dll rmpiFort.obj: rmpiFort.f90 $(FC) $(FFLAGS) $(MPI_FFLAGS) -c rmpiFort.f90 -o rmpiFort.obj -m64 $(FC) $(CUDA_FFLAGS) $(DLLCUDA_FFLAGS) -c test4.f90 -o test4.obj -m64 $(FC) $(SHLIB_FFLAGS) $(FFLAGS) $(MPI_FFLAGS) $(CUDA_FFLAGS) -o rmpiFort.dll test4.obj rmpiFort.obj -m64 When I do Make check, I get the following: * installing *source* package 'rmpiFort' ... ** libs d:/Rtools/mingw_64/bin/gfortran -O2 -march=native -pipe -Mmpi=msmpi -c rmpiFort.f90 -o rmpiFort.obj -m64 gfortran.exe: error: unrecognized command line option '-Mmpi=msmpi' make: *** [Makevars:14: rmpiFort.obj] Error 1 ERROR: compilation failed for package 'rmpiFort' * removing 'D:/rnew/rmpiFort.Rcheck/rmpiFort' So it is still trying to use the gfortran compiler rather than the PGI compiler. The PGI libraries are first in the PATH. Since it worked fine before, I am at a loss as to why it doesn't work now. Any suggestions much appreciated. Thanks, Erin Erin Hodgess, PhD mailto: erinm.hodg...@gmail.com [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem with compiling OpenBLAS to work with R
Yay! I re-installed everything and got through "Make distribution"! I have one more question, please: I am running the make check-all. I have an error at reg-1d. It stops the process. However, the mean difference (as per the file) is 2.0e-12. I'm ok with that. How do I bypass this, please? Thanks, Erin Erin Hodgess, PhD mailto: erinm.hodg...@gmail.com On Wed, Feb 27, 2019 at 10:22 PM Avraham Adler wrote: > I believe that repo just follows the directions on my blog. Without seeing > Dr. Hodges’s code, my initial concern is the many references to Cygwin. My > method specifically does not use Cygwin but MSYS2 and Mingw64/Rtools35. > That will likely change to solely Rtools40 once R3.6 is released due to the > Msys system being built in to it. > > There may be some library conflicts between Cygwin and msys2/mingw64. If > possible, my suggestion would be uninstall everything and then just install > msys2 (and add in make after you to the first msys update) and rtools35. > Then there should be no conflicting libraries. > > Thanks, > > Avi > > On Thu, Feb 28, 2019 at 12:11 AM Kenny Bell wrote: > >> This person has had apparent success - you could follow what they did or >> just download their product (with appropriate caution downloading a random >> .exe). >> >> https://github.com/thequackdaddy/R-OpenBLAS >> >> On Thu, Feb 28, 2019 at 6:28 AM Erin Hodgess >> wrote: >> >> > Hello! >> > >> > I'm not sure if this is the right place to post this, so apologies >> > in advance if I'm not in the right list. >> > >> > I downloaded the OpenBLAS and am following Avraham Adler's great >> > instructions. However, when I run make, things go well to a certain >> point, >> > and then go bad: >> > >> > make >> > [snip] >> > >> > touch cygopenblas_haswellp-r0.3.5.a >> > make -j 1 -C test all >> > make[1]: Entering directory >> > '/home/erinm/OPB_HOME/xianyi-OpenBLAS-eebc189/test' >> > gfortran -O2 -Wall -frecursive -m64 -mavx2 -o sblat1 sblat1.o >> > ../cygopenblas_haswellp-r0.3.5.a -L/usr/lib/gcc/x86_64-pc-msys/7.3.0 >> > >> -L/usr/lib/gcc/x86_64-pc-msys/7.3.0/../../../../x86_64-pc-msys/lib/../lib >> > -L/usr/lib/../lib >> > -L/usr/lib/gcc/x86_64-pc-msys/7.3.0/../../../../x86_64-pc-msys/lib >> > -L/usr/lib/w32api -lmsys-2.0 >> > D:/msys64/usr/lib/../lib/libpthread.a(t-d001088.o):fake:(.text+0x2): >> > undefined reference to `__imp_pthread_mutex_destroy' >> > D:/msys64/usr/lib/../lib/libpthread.a(t-d001090.o):fake:(.text+0x2): >> > undefined reference to `__imp_pthread_mutex_init' >> > D:/msys64/usr/lib/../lib/libpthread.a(t-d001091.o):fake:(.text+0x2): >> > undefined reference to `__imp_pthread_mutex_lock' >> > D:/msys64/usr/lib/../lib/libpthread.a(t-d001094.o):fake:(.text+0x2): >> > undefined reference to `__imp_pthread_mutex_trylock' >> > D:/msys64/usr/lib/../lib/libpthread.a(t-d001095.o):fake:(.text+0x2): >> > undefined reference to `__imp_pthread_mutex_unlock' >> > collect2.exe: error: ld returned 1 exit status >> > make[1]: *** [Makefile:134: sblat1] Error 1 >> > make[1]: Leaving directory >> > '/home/erinm/OPB_HOME/xianyi-OpenBLAS-eebc189/test' >> > make: *** [Makefile:124: tests] Error 2 >> > >> > >> > I think it has something to do with the threads/pthreads but am not sure >> > how to fix it. Any suggestions much appreciated. >> > >> > Thanks, >> > Sincerely, >> > Erin >> > >> > Erin Hodgess, PhD >> > mailto: erinm.hodg...@gmail.com >> > >> > [[alternative HTML version deleted]] >> > >> > __ >> > R-devel@r-project.org mailing list >> > https://stat.ethz.ch/mailman/listinfo/r-devel >> > >> >> [[alternative HTML version deleted]] >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > -- > Sent from Gmail Mobile > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem with compiling OpenBLAS to work with R
The Cygwin is the problem. I am redoing and will let you know how it goes. Thanks for your help. Sincerely, Erin On Wed, Feb 27, 2019 at 10:22 PM Avraham Adler wrote: > I believe that repo just follows the directions on my blog. Without seeing > Dr. Hodges’s code, my initial concern is the many references to Cygwin. My > method specifically does not use Cygwin but MSYS2 and Mingw64/Rtools35. > That will likely change to solely Rtools40 once R3.6 is released due to the > Msys system being built in to it. > > There may be some library conflicts between Cygwin and msys2/mingw64. If > possible, my suggestion would be uninstall everything and then just install > msys2 (and add in make after you to the first msys update) and rtools35. > Then there should be no conflicting libraries. > > Thanks, > > Avi > > On Thu, Feb 28, 2019 at 12:11 AM Kenny Bell wrote: > >> This person has had apparent success - you could follow what they did or >> just download their product (with appropriate caution downloading a random >> .exe). >> >> https://github.com/thequackdaddy/R-OpenBLAS >> >> On Thu, Feb 28, 2019 at 6:28 AM Erin Hodgess >> wrote: >> >> > Hello! >> > >> > I'm not sure if this is the right place to post this, so apologies >> > in advance if I'm not in the right list. >> > >> > I downloaded the OpenBLAS and am following Avraham Adler's great >> > instructions. However, when I run make, things go well to a certain >> point, >> > and then go bad: >> > >> > make >> > [snip] >> > >> > touch cygopenblas_haswellp-r0.3.5.a >> > make -j 1 -C test all >> > make[1]: Entering directory >> > '/home/erinm/OPB_HOME/xianyi-OpenBLAS-eebc189/test' >> > gfortran -O2 -Wall -frecursive -m64 -mavx2 -o sblat1 sblat1.o >> > ../cygopenblas_haswellp-r0.3.5.a -L/usr/lib/gcc/x86_64-pc-msys/7.3.0 >> > >> -L/usr/lib/gcc/x86_64-pc-msys/7.3.0/../../../../x86_64-pc-msys/lib/../lib >> > -L/usr/lib/../lib >> > -L/usr/lib/gcc/x86_64-pc-msys/7.3.0/../../../../x86_64-pc-msys/lib >> > -L/usr/lib/w32api -lmsys-2.0 >> > D:/msys64/usr/lib/../lib/libpthread.a(t-d001088.o):fake:(.text+0x2): >> > undefined reference to `__imp_pthread_mutex_destroy' >> > D:/msys64/usr/lib/../lib/libpthread.a(t-d001090.o):fake:(.text+0x2): >> > undefined reference to `__imp_pthread_mutex_init' >> > D:/msys64/usr/lib/../lib/libpthread.a(t-d001091.o):fake:(.text+0x2): >> > undefined reference to `__imp_pthread_mutex_lock' >> > D:/msys64/usr/lib/../lib/libpthread.a(t-d001094.o):fake:(.text+0x2): >> > undefined reference to `__imp_pthread_mutex_trylock' >> > D:/msys64/usr/lib/../lib/libpthread.a(t-d001095.o):fake:(.text+0x2): >> > undefined reference to `__imp_pthread_mutex_unlock' >> > collect2.exe: error: ld returned 1 exit status >> > make[1]: *** [Makefile:134: sblat1] Error 1 >> > make[1]: Leaving directory >> > '/home/erinm/OPB_HOME/xianyi-OpenBLAS-eebc189/test' >> > make: *** [Makefile:124: tests] Error 2 >> > >> > >> > I think it has something to do with the threads/pthreads but am not sure >> > how to fix it. Any suggestions much appreciated. >> > >> > Thanks, >> > Sincerely, >> > Erin >> > >> > Erin Hodgess, PhD >> > mailto: erinm.hodg...@gmail.com >> > >> > [[alternative HTML version deleted]] >> > >> > __ >> > R-devel@r-project.org mailing list >> > https://stat.ethz.ch/mailman/listinfo/r-devel >> > >> >> [[alternative HTML version deleted]] >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > -- > Sent from Gmail Mobile > -- Erin Hodgess, PhD mailto: erinm.hodg...@gmail.com [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Problem with compiling OpenBLAS to work with R
Hello! I'm not sure if this is the right place to post this, so apologies in advance if I'm not in the right list. I downloaded the OpenBLAS and am following Avraham Adler's great instructions. However, when I run make, things go well to a certain point, and then go bad: make [snip] touch cygopenblas_haswellp-r0.3.5.a make -j 1 -C test all make[1]: Entering directory '/home/erinm/OPB_HOME/xianyi-OpenBLAS-eebc189/test' gfortran -O2 -Wall -frecursive -m64 -mavx2 -o sblat1 sblat1.o ../cygopenblas_haswellp-r0.3.5.a -L/usr/lib/gcc/x86_64-pc-msys/7.3.0 -L/usr/lib/gcc/x86_64-pc-msys/7.3.0/../../../../x86_64-pc-msys/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-pc-msys/7.3.0/../../../../x86_64-pc-msys/lib -L/usr/lib/w32api -lmsys-2.0 D:/msys64/usr/lib/../lib/libpthread.a(t-d001088.o):fake:(.text+0x2): undefined reference to `__imp_pthread_mutex_destroy' D:/msys64/usr/lib/../lib/libpthread.a(t-d001090.o):fake:(.text+0x2): undefined reference to `__imp_pthread_mutex_init' D:/msys64/usr/lib/../lib/libpthread.a(t-d001091.o):fake:(.text+0x2): undefined reference to `__imp_pthread_mutex_lock' D:/msys64/usr/lib/../lib/libpthread.a(t-d001094.o):fake:(.text+0x2): undefined reference to `__imp_pthread_mutex_trylock' D:/msys64/usr/lib/../lib/libpthread.a(t-d001095.o):fake:(.text+0x2): undefined reference to `__imp_pthread_mutex_unlock' collect2.exe: error: ld returned 1 exit status make[1]: *** [Makefile:134: sblat1] Error 1 make[1]: Leaving directory '/home/erinm/OPB_HOME/xianyi-OpenBLAS-eebc189/test' make: *** [Makefile:124: tests] Error 2 I think it has something to do with the threads/pthreads but am not sure how to fix it. Any suggestions much appreciated. Thanks, Sincerely, Erin Erin Hodgess, PhD mailto: erinm.hodg...@gmail.com [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [R-pkg-devel] Trying to compile R-3.5.1 with openblas for windows
Finally got Openblas installed! The speed up is amazing! Thanks for your help and patience. Sincerely, Erin Erin Hodgess, PhD mailto: erinm.hodg...@gmail.com On Fri, Sep 14, 2018 at 2:46 PM Avraham Adler wrote: > No, I’m sorry, I haven’t seen that and I built R 3.5.1 with OpenBLAS > recently. Does it work if you use the vanilla BLAS? > > Avi > > On Fri, Sep 14, 2018 at 4:14 PM Erin Hodgess > wrote: > >> Hi again! >> >> I checked everything, did "make distribution" and the same thing occurred. >> >> >> d:/Rtools/mingw_64/bin/ar -rucs ../SuiteSparse_config.a >> SuiteSparse_config.o >> D:\Rtools\mingw_64\bin\nm.exe: 'sublibs': No such file >> d:/Rtools/mingw_64/bin/gcc -shared -s -static-libgcc -o Matrix.dll >> tmp.def CHMfactor.o Csparse.o TMatrix_as.o Tsparse.o init.o Mutils.o >> chm_common.o cs.o cs_utils.o dense.o dgCMatrix.o dgTMatrix.o dgeMatrix.o >> dpoMatrix.o dppMatrix.o dsCMatrix.o dsyMatrix.o dspMatrix.o dtCMatrix.o >> dtTMatrix.o dtrMatrix.o dtpMatrix.o factorizations.o ldense.o lgCMatrix.o >> sparseQR.o abIndex.o -LD:/erinm/R-3.5.1/bin/x64 -lRlapack >> -LD:/erinm/R-3.5.1/bin/x64 -lRblas -LD:/erinm/R-3.5.1/extsoft/lib/x64 >> -LD:/erinm/R-3.5.1/extsoft/lib -LD:/erinm/R-3.5.1/bin/x64 -lR >> CHMfactor.o:CHMfactor.c:(.text+0x3b): undefined reference to >> `cholmod_copy_factor' >> CHMfactor.o:CHMfactor.c:(.text+0x7b): undefined reference to >> `cholmod_change_factor' >> CHMfactor.o:CHMfactor.c:(.text+0x92): undefined reference to >> `cholmod_factor_to_sparse' >> CHMfactor.o:CHMfactor.c:(.text+0xa5): undefined reference to >> `cholmod_free_factor' >> CHMfactor.o:CHMfactor.c:(.text+0x18e): undefined reference to >> `cholmod_solve' >> CHMfactor.o:CHMfactor.c:(.text+0x267): undefined reference to >> `cholmod_copy_factor' >> CHMfactor.o:CHMfactor.c:(.text+0x27e): undefined reference to >> `cholmod_updown' >> CHMfactor.o:CHMfactor.c:(.text+0x396): undefined reference to >> `cholmod_spsolve' >> CHMfactor.o:CHMfactor.c:(.text+0x620): undefined reference to >> `cholmod_factorize_p' >> CHMfactor.o:CHMfactor.c:(.text+0x658): undefined reference to >> `cholmod_change_factor' >> CHMfactor.o:CHMfactor.c:(.text+0x720): undefined reference to >> `cholmod_copy_factor' >> CHMfactor.o:CHMfactor.c:(.text+0x87b): undefined reference to >> `cholmod_copy_factor' >> CHMfactor.o:CHMfactor.c:(.text+0x8c3): undefined reference to >> `cholmod_free_factor' >> Csparse.o:Csparse.c:(.text+0x9f1): undefined reference to >> `cholmod_sparse_to_dense' >> Csparse.o:Csparse.c:(.text+0xcd6): undefined reference to `cholmod_speye' >> Csparse.o:Csparse.c:(.text+0xd21): undefined reference to `cholmod_add' >> Csparse.o:Csparse.c:(.text+0xd31): undefined reference to >> `cholmod_free_sparse' >> Csparse.o:Csparse.c:(.text+0xd3d): undefined reference to >> `cholmod_copy_sparse' >> Csparse.o:Csparse.c:(.text+0xd4c): undefined reference to >> `cholmod_free_sparse' >> Csparse.o:Csparse.c:(.text+0xdf9): undefined reference to `cholmod_copy' >> >> Does this look familiar, please? >> >> Thanks, >> Erin >> >> Erin Hodgess, PhD >> mailto: erinm.hodg...@gmail.com >> >> >> On Fri, Sep 14, 2018 at 1:13 PM Avraham Adler >> wrote: >> >>> Try following the directions here. They have worked for me for years. >>> Please see the comments too. >>> >>> https://www.avrahamadler.com/r-tips/build-openblas-for-windows-r64/ >>> >>> Hope that helps, >>> >>> Avi >>> >>> On Fri, Sep 14, 2018 at 2:34 PM Erin Hodgess >>> wrote: >>> >>>> Hello! >>>> >>>> I'm building a package that needs Openblas for matrix manipulation >>>> speed up. >>>> >>>> I built Openblas on Windows 10. I updated the MkRules.local, >>>> src/extra/blas/Makefile.win, etc. Things are working with "make all". >>>> >>>> However, when I run "make recommended", I have trouble with the Matrix >>>> package build. The components of the Cholesky all appear as >>>> unreferenced. >>>> >>>> Has anyone else run into this, please? I'm working with R-3.5.1 source. >>>> >>>> Thanks, >>>> Erin >>>> >>>> Erin Hodgess, PhD >>>> mailto: erinm.hodg...@gmail.com >>>> >>>> [[alternative HTML version deleted]] >>>> >>>> __ >>>> R-package-devel@r-project.org mailing list >>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel >>>> >>> -- >>> Sent from Gmail Mobile >>> >> -- > Sent from Gmail Mobile > [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Trying to compile R-3.5.1 with openblas for windows
I have a snag on regular BLAS as well. I feel better about the Open BLAS On Fri, Sep 14, 2018 at 2:47 PM Erin Hodgess wrote: > That is my next thing to try. Thanks for your help! > > > Erin Hodgess, PhD > mailto: erinm.hodg...@gmail.com > > > On Fri, Sep 14, 2018 at 2:46 PM Avraham Adler > wrote: > >> No, I’m sorry, I haven’t seen that and I built R 3.5.1 with OpenBLAS >> recently. Does it work if you use the vanilla BLAS? >> >> Avi >> >> On Fri, Sep 14, 2018 at 4:14 PM Erin Hodgess >> wrote: >> >>> Hi again! >>> >>> I checked everything, did "make distribution" and the same thing >>> occurred. >>> >>> >>> d:/Rtools/mingw_64/bin/ar -rucs ../SuiteSparse_config.a >>> SuiteSparse_config.o >>> D:\Rtools\mingw_64\bin\nm.exe: 'sublibs': No such file >>> d:/Rtools/mingw_64/bin/gcc -shared -s -static-libgcc -o Matrix.dll >>> tmp.def CHMfactor.o Csparse.o TMatrix_as.o Tsparse.o init.o Mutils.o >>> chm_common.o cs.o cs_utils.o dense.o dgCMatrix.o dgTMatrix.o dgeMatrix.o >>> dpoMatrix.o dppMatrix.o dsCMatrix.o dsyMatrix.o dspMatrix.o dtCMatrix.o >>> dtTMatrix.o dtrMatrix.o dtpMatrix.o factorizations.o ldense.o lgCMatrix.o >>> sparseQR.o abIndex.o -LD:/erinm/R-3.5.1/bin/x64 -lRlapack >>> -LD:/erinm/R-3.5.1/bin/x64 -lRblas -LD:/erinm/R-3.5.1/extsoft/lib/x64 >>> -LD:/erinm/R-3.5.1/extsoft/lib -LD:/erinm/R-3.5.1/bin/x64 -lR >>> CHMfactor.o:CHMfactor.c:(.text+0x3b): undefined reference to >>> `cholmod_copy_factor' >>> CHMfactor.o:CHMfactor.c:(.text+0x7b): undefined reference to >>> `cholmod_change_factor' >>> CHMfactor.o:CHMfactor.c:(.text+0x92): undefined reference to >>> `cholmod_factor_to_sparse' >>> CHMfactor.o:CHMfactor.c:(.text+0xa5): undefined reference to >>> `cholmod_free_factor' >>> CHMfactor.o:CHMfactor.c:(.text+0x18e): undefined reference to >>> `cholmod_solve' >>> CHMfactor.o:CHMfactor.c:(.text+0x267): undefined reference to >>> `cholmod_copy_factor' >>> CHMfactor.o:CHMfactor.c:(.text+0x27e): undefined reference to >>> `cholmod_updown' >>> CHMfactor.o:CHMfactor.c:(.text+0x396): undefined reference to >>> `cholmod_spsolve' >>> CHMfactor.o:CHMfactor.c:(.text+0x620): undefined reference to >>> `cholmod_factorize_p' >>> CHMfactor.o:CHMfactor.c:(.text+0x658): undefined reference to >>> `cholmod_change_factor' >>> CHMfactor.o:CHMfactor.c:(.text+0x720): undefined reference to >>> `cholmod_copy_factor' >>> CHMfactor.o:CHMfactor.c:(.text+0x87b): undefined reference to >>> `cholmod_copy_factor' >>> CHMfactor.o:CHMfactor.c:(.text+0x8c3): undefined reference to >>> `cholmod_free_factor' >>> Csparse.o:Csparse.c:(.text+0x9f1): undefined reference to >>> `cholmod_sparse_to_dense' >>> Csparse.o:Csparse.c:(.text+0xcd6): undefined reference to `cholmod_speye' >>> Csparse.o:Csparse.c:(.text+0xd21): undefined reference to `cholmod_add' >>> Csparse.o:Csparse.c:(.text+0xd31): undefined reference to >>> `cholmod_free_sparse' >>> Csparse.o:Csparse.c:(.text+0xd3d): undefined reference to >>> `cholmod_copy_sparse' >>> Csparse.o:Csparse.c:(.text+0xd4c): undefined reference to >>> `cholmod_free_sparse' >>> Csparse.o:Csparse.c:(.text+0xdf9): undefined reference to `cholmod_copy' >>> >>> Does this look familiar, please? >>> >>> Thanks, >>> Erin >>> >>> Erin Hodgess, PhD >>> mailto: erinm.hodg...@gmail.com >>> >>> >>> On Fri, Sep 14, 2018 at 1:13 PM Avraham Adler >>> wrote: >>> >>>> Try following the directions here. They have worked for me for years. >>>> Please see the comments too. >>>> >>>> https://www.avrahamadler.com/r-tips/build-openblas-for-windows-r64/ >>>> >>>> Hope that helps, >>>> >>>> Avi >>>> >>>> On Fri, Sep 14, 2018 at 2:34 PM Erin Hodgess >>>> wrote: >>>> >>>>> Hello! >>>>> >>>>> I'm building a package that needs Openblas for matrix manipulation >>>>> speed up. >>>>> >>>>> I built Openblas on Windows 10. I updated the MkRules.local, >>>>> src/extra/blas/Makefile.win, etc. Things are working with "make all". >>>>> >>>>> However, when I run "make recommended", I have trouble with the Matrix >>>>> package build. The components of the Cholesky all appear as >>>>> unreferenced. >>>>> >>>>> Has anyone else run into this, please? I'm working with R-3.5.1 >>>>> source. >>>>> >>>>> Thanks, >>>>> Erin >>>>> >>>>> Erin Hodgess, PhD >>>>> mailto: erinm.hodg...@gmail.com >>>>> >>>>> [[alternative HTML version deleted]] >>>>> >>>>> __ >>>>> R-package-devel@r-project.org mailing list >>>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel >>>>> >>>> -- >>>> Sent from Gmail Mobile >>>> >>> -- >> Sent from Gmail Mobile >> > -- Erin Hodgess, PhD mailto: erinm.hodg...@gmail.com [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Trying to compile R-3.5.1 with openblas for windows
That is my next thing to try. Thanks for your help! Erin Hodgess, PhD mailto: erinm.hodg...@gmail.com On Fri, Sep 14, 2018 at 2:46 PM Avraham Adler wrote: > No, I’m sorry, I haven’t seen that and I built R 3.5.1 with OpenBLAS > recently. Does it work if you use the vanilla BLAS? > > Avi > > On Fri, Sep 14, 2018 at 4:14 PM Erin Hodgess > wrote: > >> Hi again! >> >> I checked everything, did "make distribution" and the same thing occurred. >> >> >> d:/Rtools/mingw_64/bin/ar -rucs ../SuiteSparse_config.a >> SuiteSparse_config.o >> D:\Rtools\mingw_64\bin\nm.exe: 'sublibs': No such file >> d:/Rtools/mingw_64/bin/gcc -shared -s -static-libgcc -o Matrix.dll >> tmp.def CHMfactor.o Csparse.o TMatrix_as.o Tsparse.o init.o Mutils.o >> chm_common.o cs.o cs_utils.o dense.o dgCMatrix.o dgTMatrix.o dgeMatrix.o >> dpoMatrix.o dppMatrix.o dsCMatrix.o dsyMatrix.o dspMatrix.o dtCMatrix.o >> dtTMatrix.o dtrMatrix.o dtpMatrix.o factorizations.o ldense.o lgCMatrix.o >> sparseQR.o abIndex.o -LD:/erinm/R-3.5.1/bin/x64 -lRlapack >> -LD:/erinm/R-3.5.1/bin/x64 -lRblas -LD:/erinm/R-3.5.1/extsoft/lib/x64 >> -LD:/erinm/R-3.5.1/extsoft/lib -LD:/erinm/R-3.5.1/bin/x64 -lR >> CHMfactor.o:CHMfactor.c:(.text+0x3b): undefined reference to >> `cholmod_copy_factor' >> CHMfactor.o:CHMfactor.c:(.text+0x7b): undefined reference to >> `cholmod_change_factor' >> CHMfactor.o:CHMfactor.c:(.text+0x92): undefined reference to >> `cholmod_factor_to_sparse' >> CHMfactor.o:CHMfactor.c:(.text+0xa5): undefined reference to >> `cholmod_free_factor' >> CHMfactor.o:CHMfactor.c:(.text+0x18e): undefined reference to >> `cholmod_solve' >> CHMfactor.o:CHMfactor.c:(.text+0x267): undefined reference to >> `cholmod_copy_factor' >> CHMfactor.o:CHMfactor.c:(.text+0x27e): undefined reference to >> `cholmod_updown' >> CHMfactor.o:CHMfactor.c:(.text+0x396): undefined reference to >> `cholmod_spsolve' >> CHMfactor.o:CHMfactor.c:(.text+0x620): undefined reference to >> `cholmod_factorize_p' >> CHMfactor.o:CHMfactor.c:(.text+0x658): undefined reference to >> `cholmod_change_factor' >> CHMfactor.o:CHMfactor.c:(.text+0x720): undefined reference to >> `cholmod_copy_factor' >> CHMfactor.o:CHMfactor.c:(.text+0x87b): undefined reference to >> `cholmod_copy_factor' >> CHMfactor.o:CHMfactor.c:(.text+0x8c3): undefined reference to >> `cholmod_free_factor' >> Csparse.o:Csparse.c:(.text+0x9f1): undefined reference to >> `cholmod_sparse_to_dense' >> Csparse.o:Csparse.c:(.text+0xcd6): undefined reference to `cholmod_speye' >> Csparse.o:Csparse.c:(.text+0xd21): undefined reference to `cholmod_add' >> Csparse.o:Csparse.c:(.text+0xd31): undefined reference to >> `cholmod_free_sparse' >> Csparse.o:Csparse.c:(.text+0xd3d): undefined reference to >> `cholmod_copy_sparse' >> Csparse.o:Csparse.c:(.text+0xd4c): undefined reference to >> `cholmod_free_sparse' >> Csparse.o:Csparse.c:(.text+0xdf9): undefined reference to `cholmod_copy' >> >> Does this look familiar, please? >> >> Thanks, >> Erin >> >> Erin Hodgess, PhD >> mailto: erinm.hodg...@gmail.com >> >> >> On Fri, Sep 14, 2018 at 1:13 PM Avraham Adler >> wrote: >> >>> Try following the directions here. They have worked for me for years. >>> Please see the comments too. >>> >>> https://www.avrahamadler.com/r-tips/build-openblas-for-windows-r64/ >>> >>> Hope that helps, >>> >>> Avi >>> >>> On Fri, Sep 14, 2018 at 2:34 PM Erin Hodgess >>> wrote: >>> >>>> Hello! >>>> >>>> I'm building a package that needs Openblas for matrix manipulation >>>> speed up. >>>> >>>> I built Openblas on Windows 10. I updated the MkRules.local, >>>> src/extra/blas/Makefile.win, etc. Things are working with "make all". >>>> >>>> However, when I run "make recommended", I have trouble with the Matrix >>>> package build. The components of the Cholesky all appear as >>>> unreferenced. >>>> >>>> Has anyone else run into this, please? I'm working with R-3.5.1 source. >>>> >>>> Thanks, >>>> Erin >>>> >>>> Erin Hodgess, PhD >>>> mailto: erinm.hodg...@gmail.com >>>> >>>> [[alternative HTML version deleted]] >>>> >>>> __ >>>> R-package-devel@r-project.org mailing list >>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel >>>> >>> -- >>> Sent from Gmail Mobile >>> >> -- > Sent from Gmail Mobile > [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Trying to compile R-3.5.1 with openblas for windows
Hi again! I checked everything, did "make distribution" and the same thing occurred. d:/Rtools/mingw_64/bin/ar -rucs ../SuiteSparse_config.a SuiteSparse_config.o D:\Rtools\mingw_64\bin\nm.exe: 'sublibs': No such file d:/Rtools/mingw_64/bin/gcc -shared -s -static-libgcc -o Matrix.dll tmp.def CHMfactor.o Csparse.o TMatrix_as.o Tsparse.o init.o Mutils.o chm_common.o cs.o cs_utils.o dense.o dgCMatrix.o dgTMatrix.o dgeMatrix.o dpoMatrix.o dppMatrix.o dsCMatrix.o dsyMatrix.o dspMatrix.o dtCMatrix.o dtTMatrix.o dtrMatrix.o dtpMatrix.o factorizations.o ldense.o lgCMatrix.o sparseQR.o abIndex.o -LD:/erinm/R-3.5.1/bin/x64 -lRlapack -LD:/erinm/R-3.5.1/bin/x64 -lRblas -LD:/erinm/R-3.5.1/extsoft/lib/x64 -LD:/erinm/R-3.5.1/extsoft/lib -LD:/erinm/R-3.5.1/bin/x64 -lR CHMfactor.o:CHMfactor.c:(.text+0x3b): undefined reference to `cholmod_copy_factor' CHMfactor.o:CHMfactor.c:(.text+0x7b): undefined reference to `cholmod_change_factor' CHMfactor.o:CHMfactor.c:(.text+0x92): undefined reference to `cholmod_factor_to_sparse' CHMfactor.o:CHMfactor.c:(.text+0xa5): undefined reference to `cholmod_free_factor' CHMfactor.o:CHMfactor.c:(.text+0x18e): undefined reference to `cholmod_solve' CHMfactor.o:CHMfactor.c:(.text+0x267): undefined reference to `cholmod_copy_factor' CHMfactor.o:CHMfactor.c:(.text+0x27e): undefined reference to `cholmod_updown' CHMfactor.o:CHMfactor.c:(.text+0x396): undefined reference to `cholmod_spsolve' CHMfactor.o:CHMfactor.c:(.text+0x620): undefined reference to `cholmod_factorize_p' CHMfactor.o:CHMfactor.c:(.text+0x658): undefined reference to `cholmod_change_factor' CHMfactor.o:CHMfactor.c:(.text+0x720): undefined reference to `cholmod_copy_factor' CHMfactor.o:CHMfactor.c:(.text+0x87b): undefined reference to `cholmod_copy_factor' CHMfactor.o:CHMfactor.c:(.text+0x8c3): undefined reference to `cholmod_free_factor' Csparse.o:Csparse.c:(.text+0x9f1): undefined reference to `cholmod_sparse_to_dense' Csparse.o:Csparse.c:(.text+0xcd6): undefined reference to `cholmod_speye' Csparse.o:Csparse.c:(.text+0xd21): undefined reference to `cholmod_add' Csparse.o:Csparse.c:(.text+0xd31): undefined reference to `cholmod_free_sparse' Csparse.o:Csparse.c:(.text+0xd3d): undefined reference to `cholmod_copy_sparse' Csparse.o:Csparse.c:(.text+0xd4c): undefined reference to `cholmod_free_sparse' Csparse.o:Csparse.c:(.text+0xdf9): undefined reference to `cholmod_copy' Does this look familiar, please? Thanks, Erin Erin Hodgess, PhD mailto: erinm.hodg...@gmail.com On Fri, Sep 14, 2018 at 1:13 PM Avraham Adler wrote: > Try following the directions here. They have worked for me for years. > Please see the comments too. > > https://www.avrahamadler.com/r-tips/build-openblas-for-windows-r64/ > > Hope that helps, > > Avi > > On Fri, Sep 14, 2018 at 2:34 PM Erin Hodgess > wrote: > >> Hello! >> >> I'm building a package that needs Openblas for matrix manipulation speed >> up. >> >> I built Openblas on Windows 10. I updated the MkRules.local, >> src/extra/blas/Makefile.win, etc. Things are working with "make all". >> >> However, when I run "make recommended", I have trouble with the Matrix >> package build. The components of the Cholesky all appear as unreferenced. >> >> Has anyone else run into this, please? I'm working with R-3.5.1 source. >> >> Thanks, >> Erin >> >> Erin Hodgess, PhD >> mailto: erinm.hodg...@gmail.com >> >> [[alternative HTML version deleted]] >> >> __ >> R-package-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-package-devel >> > -- > Sent from Gmail Mobile > [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Trying to compile R-3.5.1 with openblas for windows
Hello! I'm building a package that needs Openblas for matrix manipulation speed up. I built Openblas on Windows 10. I updated the MkRules.local, src/extra/blas/Makefile.win, etc. Things are working with "make all". However, when I run "make recommended", I have trouble with the Matrix package build. The components of the Cholesky all appear as unreferenced. Has anyone else run into this, please? I'm working with R-3.5.1 source. Thanks, Erin Erin Hodgess, PhD mailto: erinm.hodg...@gmail.com [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Making adjustments to the R CMD check/install commands
Yay! I got it to work! I used the ~/.R/Makevars, and all is well. Thanks again, Erin Erin Hodgess, PhD mailto: erinm.hodg...@gmail.com On Mon, Aug 27, 2018 at 2:29 PM Kevin Ushey wrote: > Hi Erin, > > The R extensions manual should be helpful here -- in particular, see the > sections on the 'src/Makevars' file and configuration of the Fortran > compiler: > > https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Using-Makevars > > In particular, in your 'src/Makevars' file, you'll likely want to set the > FC variable to choose the Fortran compiler, and FCFLAGS to choose the > appropriate compilation flags. As an example, you can see how one might set > these flags to compile code with the address sanitizer active: > > > https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Using-Address-Sanitizer > > (Note that this example uses the user-level '~/.R/Makevars' file rather > than the package-level 'src/Makevars' file, but the crux is the same) > > Hope this gets you on the right track, > Kevin > > On Mon, Aug 27, 2018 at 1:15 PM Erin Hodgess > wrote: > >> Hello! >> >> I'm building a package on Windows 10 which uses the PGI Fortran compiler. >> I have a Makefile set up in the src directory, and when I run "make all", >> the subroutines compile beautifully. >> >> Now I want to create my package. When I run R CMD check, naturally, >> gfortran is called. Is there a way that I can direct the check function >> to >> just use the make/Makefile, please? >> >> Or am I out of luck, please? (highly probable) >> >> Thanks, >> Erin >> >> Erin Hodgess, PhD >> mailto: erinm.hodg...@gmail.com >> >> [[alternative HTML version deleted]] >> >> __ >> R-package-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-package-devel >> > [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Making adjustments to the R CMD check/install commands
Thank you, Kevin! I put together the Makevars file: PKG_LIBS = $(LAPACK_LIBS) $(BLAS_LIBS) FC=c:/progra~1/PGICE/win64/18.4/bin/pgf90 SAFE_FFLAGS="-Lc:/progra~1/PGICE/win64/18.4/lib/pgf90.dll -Lc:/progra~1/PGICE/win64/18.4/lib/pgc14.dll" rmpiFort.obj: rmpiFort.f90 $(FC) $(SAFE_FFLAGS) -Mmpi=msmpi -c rmpiFort.f90 -o rmpiFort.obj rmpiFort.dll: rmpiFort.obj $(FC) $(SAFE_FFLAGS) rmpiFort.obj -Mmpi=msmpi -Mmakedll -o rmpiFort.dll But when I run R CMD check, the 00install file shows that the gfortran compile is used, rather than the PGI compiler: * installing *source* package 'rmpiFort' ...^M ** libs^M ^M *** arch - i386^M C:/progra~1/R/R-35~1.1/share/make/winshlib.mk:13: warning: overriding commands for target `rmpiFort.dll' Makevars:10: warning: ignoring old commands for target `rmpiFort.dll' c:/Rtools/mingw_32/bin/gfortran -O2 -msse2 -mfpmath=sse -Mmpi=msmpi -c rmpiFort.f90 -o rmpiFort.obj gfortran.exe: error: unrecognized command line option '-Mmpi=msmpi'^M make: *** [rmpiFort.obj] Error 1 ERROR: compilation failed for package 'rmpiFort'^M * removing 'C:/Users/erinm/rmpiFort.Rcheck/rmpiFort'^M In R CMD INSTALL^M So I'm still puzzled. Any help much appreciated. Sincerely, Erin Erin Hodgess, PhD mailto: erinm.hodg...@gmail.com On Mon, Aug 27, 2018 at 2:29 PM Kevin Ushey wrote: > Hi Erin, > > The R extensions manual should be helpful here -- in particular, see the > sections on the 'src/Makevars' file and configuration of the Fortran > compiler: > > https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Using-Makevars > > In particular, in your 'src/Makevars' file, you'll likely want to set the > FC variable to choose the Fortran compiler, and FCFLAGS to choose the > appropriate compilation flags. As an example, you can see how one might set > these flags to compile code with the address sanitizer active: > > > https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Using-Address-Sanitizer > > (Note that this example uses the user-level '~/.R/Makevars' file rather > than the package-level 'src/Makevars' file, but the crux is the same) > > Hope this gets you on the right track, > Kevin > > On Mon, Aug 27, 2018 at 1:15 PM Erin Hodgess > wrote: > >> Hello! >> >> I'm building a package on Windows 10 which uses the PGI Fortran compiler. >> I have a Makefile set up in the src directory, and when I run "make all", >> the subroutines compile beautifully. >> >> Now I want to create my package. When I run R CMD check, naturally, >> gfortran is called. Is there a way that I can direct the check function >> to >> just use the make/Makefile, please? >> >> Or am I out of luck, please? (highly probable) >> >> Thanks, >> Erin >> >> Erin Hodgess, PhD >> mailto: erinm.hodg...@gmail.com >> >> [[alternative HTML version deleted]] >> >> __ >> R-package-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-package-devel >> > [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Making adjustments to the R CMD check/install commands
Hello! I'm building a package on Windows 10 which uses the PGI Fortran compiler. I have a Makefile set up in the src directory, and when I run "make all", the subroutines compile beautifully. Now I want to create my package. When I run R CMD check, naturally, gfortran is called. Is there a way that I can direct the check function to just use the make/Makefile, please? Or am I out of luck, please? (highly probable) Thanks, Erin Erin Hodgess, PhD mailto: erinm.hodg...@gmail.com [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] compiling a Windows package with the PGI compiler
Hello! I am building a new package with source code that requires the Portland group compiler. How would I go about building the package with this compiler rather than gfortran, please? Thank you in advance. Sincerely, Erin PS. Windows 10, and R-3.5.1. Erin Hodgess, PhD mailto: erinm.hodg...@gmail.com [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] trouble with R check
Hi Duncan
That was exactly it. Thank you very much
Erin
On Thu, May 31, 2018 at 7:50 AM, Duncan Murdoch
wrote:
> On 31/05/2018 8:35 AM, Erin Hodgess wrote:
>
>> Hello!
>>
>>
>> I'm working with R-3.4.3 and when I run R CMD check
>> rmpiFort_0.0.0.9000.tar.gz, here is the output file.
>>
>>
>> * installing *source* package ‘rmpiFort’ ...
>>
>> ** libs
>>
>> ** arch -
>>
>> make: Nothing to be done for `all'.
>>
>> installing to /home/hodgess/R-3.4.3/bin/rmpiFort.Rcheck/rmpiFort/libs
>>
>> ** R
>>
>> ** preparing package for lazy loading
>>
>> Error : package or namespace load failed for ‘rmpiFort’ in
>> loadNamespace(packag\
>>
>> e, lib.loc):
>>
>> cyclic namespace dependency detected when loading ‘rmpiFort’, already
>> loading \
>>
>> ‘rmpiFort’
>>
>> Error : unable to load R code in package ‘rmpiFort’
>>
>> ERROR: lazy loading failed for package ‘rmpiFort’
>>
>> * removing ‘/home/hodgess/R-3.4.3/bin/rmpiFort.Rcheck/rmpiFort’
>>
>
> Sounds as though something in the package says it depends on itself.
> Possibilities off the top of my head:
>
> You have Depends: rmpiFort or Imports: rmpiFort (or even Suggests:
> rmpiFort, or LinkingTo: rmpiFort) in your DESCRIPTION file.
>
> You have importFrom(rmpiFort, ...) or import(rmpiFort) in your NAMESPACE
> file.
>
> You have requireNamespace("rmpiFort") (or require("rmpiFort"), or
> library("rmpiFort")) in your R source.
>
> Duncan Murdoch
>
--
Erin Hodgess
Associate Professor
Department of Mathematical and Statistics
University of Houston - Downtown
mailto: erinm.hodg...@gmail.com
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] trouble with R check
Hello! I'm working with R-3.4.3 and when I run R CMD check rmpiFort_0.0.0.9000.tar.gz, here is the output file. * installing *source* package ‘rmpiFort’ ... ** libs ** arch - make: Nothing to be done for `all'. installing to /home/hodgess/R-3.4.3/bin/rmpiFort.Rcheck/rmpiFort/libs ** R ** preparing package for lazy loading Error : package or namespace load failed for ‘rmpiFort’ in loadNamespace(packag\ e, lib.loc): cyclic namespace dependency detected when loading ‘rmpiFort’, already loading \ ‘rmpiFort’ Error : unable to load R code in package ‘rmpiFort’ ERROR: lazy loading failed for package ‘rmpiFort’ * removing ‘/home/hodgess/R-3.4.3/bin/rmpiFort.Rcheck/rmpiFort’ This is done on the Bridges Supercomputer at the Pittsburgh Supercomputing Center. Thanks, Erin PS. OS is Centos 6. -- Erin Hodgess Associate Professor Department of Mathematical and Statistics University of Houston - Downtown mailto: erinm.hodg...@gmail.com [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Compiling with more than one compiler in package development
Hello!
I'm not sure if this appeared, so I thought I would try again. I am
building a package on a RedHat supercomputer, using the gcc/gfortran and
the accompanying mpi (MPICH) compilers. Here is the Makefile:
PKG_LIBS = $(LAPACK_LIBS) $(BLAS_LIBS) $(FLIBS)
all: rmpigFortr.so tria.so
rmpigFortr.so:
mpifort -fPIC -c rmpigFortr.f90 -ormpigFortr.o
mpifort -shared rmpigFortr.o -o rmpigFortr.so
tria.so:
gfortran -m64 -fpic -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2
-fexcep\
tions -fstack-protector-strong --param=ssp-buffer-size=4
-grecord-gcc-switches \
-m64 -mtune=generic -c tria.f90 -o tria.o
gfortran -m64 -shared -L/usr/lib64/R/lib -Wl,-z,relro -o tria.so
tria.o\
-L/usr/lib64/R/lib -lR
Here is the NAMESPACE:
# Generated by roxygen2: fake comment so roxygen2 overwrites silently.
exportPattern("^[^\\.]")
useDynLib(rmpigFortr)
useDynLib(tria)
When I build, check, and install the package, it seems to be fine.
However, I have an R function that calls that "tria" Fortran subroutine.
Here are the results:
> library(rmpigFortr)
> za <- tri(n=1000)
Error in .Fortran("tria", as.single(y), as.integer(n)) :
"tria" not resolved from current namespace (rmpigFortr)
>
But if I type in the call to .Fortran myself, it works.
Any idea what I might be doing wrong, please?
Thanks in advance,
Sincerely,
Erin
--
Erin Hodgess
Associate Professor
Department of Mathematical and Statistics
University of Houston - Downtown
mailto: erinm.hodg...@gmail.com
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [Rd] Building R from source with the PGI compiler
Hello! I’m working on a supercomputer and will be tying into some FORTRAN programs. Those programs use OpenACC, which must be compiled with PGI. In case you are wondering, Why don’t I use C? I actually started with C and FORTRAN is faster. Thanks for listening, Erin On Thu, Dec 21, 2017 at 6:58 PM Michael Hannon <jmhannon.ucda...@gmail.com> wrote: > Hi, Erin. Please feel free to ignore this, but I'm curious: what is > the advantage to using the PGI compiler? > > -- Mike > > > On Wed, Dec 20, 2017 at 5:03 PM, Erin Hodgess <erinm.hodg...@gmail.com> > wrote: > > Hello > > > > I would like to build R from source and use the PGI compiler, rather than > > the GCC compiler. > > > > I saw the instructions for the Intel compiler in the R Installation > Manual, > > but I didn't see the PGI. I tried a few times without instructions, but > > without success. > > > > Any suggestions would be most welcome. Also, I hope this is the right > > group for the question. > > > > Sincerely, > > Erin > > > > > > > > -- > > Erin Hodgess > > Associate Professor > > Department of Mathematical and Statistics > > University of Houston - Downtown > > mailto: erinm.hodg...@gmail.com > > > > [[alternative HTML version deleted]] > > > > __ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Erin Hodgess Associate Professor Department of Mathematical and Statistics University of Houston - Downtown mailto: erinm.hodg...@gmail.com [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Building R from source with the PGI compiler
Hello I would like to build R from source and use the PGI compiler, rather than the GCC compiler. I saw the instructions for the Intel compiler in the R Installation Manual, but I didn't see the PGI. I tried a few times without instructions, but without success. Any suggestions would be most welcome. Also, I hope this is the right group for the question. Sincerely, Erin -- Erin Hodgess Associate Professor Department of Mathematical and Statistics University of Houston - Downtown mailto: erinm.hodg...@gmail.com [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
