Re: [R-pkg-devel] Compiling 32-bit on Windows using 64-bit gcc and -m32

2020-09-09 Thread Dirk Eddelbuettel 


On 9 September 2020 at 10:33, Tomas Kalibera wrote:
| Spending much more time for optimizing of the 32-bit builds may not be 
| worth the effort (and neither on the R/CRAN side).

As we are in conditional mode: maybe that could be recognized by adding an
explicit flag allowing us to disable 32-bit builds on a case by case basis?

And it would be nice to be able to do this for that other OS none of us have
access too (outside of a win-builder instance that differs subtly in setup
from the CRAN one).

Dirk

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Compiling 32-bit on Windows using 64-bit gcc and -m32

2020-09-09 Thread Tomas Kalibera 

On 9/7/20 7:07 PM, b...@denney.ws wrote:

Hello,

  


My question is:

Can I use the 64-bit gcc to build a 32-bit package with the -m32 command
line option with Rtools?  And, can that work for CRAN?  Or more generally,
is there a work-around for needing lots of RAM during compilation with the
32-bit compiler?

The background is:

I'm trying to compile a the development version of RxODE
(https://github.com/nlmixrdevelopment/RxODE/issues/278), but I'm hitting
32-bit memory limits (using >3GB and possibly >4GB RAM during compilation)
using the 32-bit version of gcc.  Specifically,


I think this is too much memory to be used for compilation. I think it 
would be best to simplify the code, possibly split it, or just reduce 
the optimization level, as I read you have done already anyway. Maybe it 
doesn't have to be -O0, maybe you can enable some. In the past I've seen 
similar cases when inlining too aggressively in large files, maybe you 
could just reduce that a bit. It may very well be that reducing the 
optimization level just a little bit will provide about the same 
performance, but require far less memory at compile time (in the past 
there have been cases when -O3 did not produce faster code than -O2 on a 
set of standard benchmarks, of course that may be different in today's 
compilers).


Spending much more time for optimizing of the 32-bit builds may not be 
worth the effort (and neither on the R/CRAN side).


Best
Tomas




  


"C:/rtools40/mingw32/bin/"gcc [etc., see the link above for the full command
line]

  


yields the error

  


cc1.exe: out of memory allocating 65536 bytes

  


There is no problem building with mingw64, and I played around to confirm
that by using:

  


Sys.setenv(BINPREF="c:/rtools40/mingw64/bin/")

  


And compilation completed successfully (though installation failed as
expected because the compiled .dll couldn't load on 32-bit R).

  


Thanks,

  


Bill


[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel


__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

[R-pkg-devel] Compiling 32-bit on Windows using 64-bit gcc and -m32

2020-09-07 Thread bill 
Hello,

 

My question is:

Can I use the 64-bit gcc to build a 32-bit package with the -m32 command
line option with Rtools?  And, can that work for CRAN?  Or more generally,
is there a work-around for needing lots of RAM during compilation with the
32-bit compiler?

 

The background is:

I'm trying to compile a the development version of RxODE
(https://github.com/nlmixrdevelopment/RxODE/issues/278), but I'm hitting
32-bit memory limits (using >3GB and possibly >4GB RAM during compilation)
using the 32-bit version of gcc.  Specifically, 

 

"C:/rtools40/mingw32/bin/"gcc [etc., see the link above for the full command
line]

 

yields the error

 

cc1.exe: out of memory allocating 65536 bytes

 

There is no problem building with mingw64, and I played around to confirm
that by using:

 

Sys.setenv(BINPREF="c:/rtools40/mingw64/bin/")

 

And compilation completed successfully (though installation failed as
expected because the compiled .dll couldn't load on 32-bit R).

 

Thanks,

 

Bill


[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel