similar to: -malign-double

aa056@chebucto.ca wrote: > > Using the same settings in config.site as were used for R-1.4.1, > R-1.5.0 fails to build. > > ./configure --enable-R-shlib > > Using defaults and using PPro optimizations, the build failed in > package methods: > > dumping R code in package 'methods' > gmake[4]: *** [../../../library/methods/R/all.rda] Error 139 >

Using the same settings in config.site as were used for R-1.4.1, R-1.5.0 fails to build. ./configure --enable-R-shlib Using defaults and using PPro optimizations, the build failed in package methods: dumping R code in package 'methods' gmake[4]: *** [../../../library/methods/R/all.rda] Error 139 gmake[4]: Leaving directory `/mnt/Data/src/install/R-1.5.0/src/library/methods' The

to> A short time ago I recieved a reply to a query to> about compiling samba with the freeware gcc under to> sco unix. Im sorry, Ive misplaced your Email to> address and WEB address (which was in italian). to> Sorry to use this forum as a contact point, but to> can you contact me again? Thanks. to> to> Tony Nichols The WEB page is at

I am running two Red Hat 6.2 servers with the 2.2.16 kernel. I am running OpenSSH_2.9.9p2 (SSH proto 2) and OpenSSL 0.9.5a 1 on both with no problems. I am having problems upgrading to OpenSSH 3.0.2p1 on both systems. After doing a gnu make installation, ssh works fine, but sftp displays fourteen digit numbers instead of file names when you do an ls listing of directory contents. File transfers

I am running Linux Mandrake 7.2 with the following: platform i586-pc-linux-gnu arch i586 os linux-gnu system i586, linux-gnu status major 1 minor 2.3 year 2001 month 04 day 26 language R To build a package I ran R CMD build Hmisc, apparently with success: * checking for file `Hmisc/DESCRIPTION' ... OK * preparing `Hmisc': * cleaning src * checking

I am having trouble installing cluster from R-1.5.0-recommended : R CMD INSTALL *.tar.gz ... g77 -fPIC -g -O2 -c pam.f -o pam.o g77 -fPIC -g -O2 -c spannel.f -o spannel.o g77 -fPIC -g -O2 -c twins.f -o twins.o cp: cannot access *.so ERROR: compilation failed for package 'cluster' [34] /home/com1/gilp/Rlibs/R-1.5.0-recommended : This is with R-1.5.0 on Solaris 5.8 using gcc

>R INSTALL dse rlibs >Installing package `dse' ... >libs >gcc -g -fpic -I/usr/local/R-0.61/include -c dsefor.c -o dsefor.o >/tmp/cca02533.i:1: numeric constant with no digits >/tmp/cca02533.i:1: numeric constant with no digits >... >is there something wrong with my gcc or is there some >option missing somewhere? >I suspect the problem might have to do with

>R INSTALL dse rlibs >Installing package `dse' ... >libs >gcc -g -fpic -I/usr/local/R-0.61/include -c dsefor.c -o dsefor.o >/tmp/cca02533.i:1: numeric constant with no digits >/tmp/cca02533.i:1: numeric constant with no digits >... >is there something wrong with my gcc or is there some >option missing somewhere? >I suspect the problem might have to do with

My library uses compiled code which I converted from fortran to C with f2c. I put copies of the same Makefile in the both dse/src and dse/src-c. (I'm not sure why, but I niavely assumed the same Makefile might work.) Now, I haven't tried the fortran version with R. But of course the first person (as far as I know) to actually try and use the package defaulted to compiling the fortran

This might more properly be filed as a bug report, but ... I came upon the following problem while trying to dyn.load a library of Fortran code into R. I'm running RedHat 7.1 on a Pentium III laptop, with R version 1.3.1 (latest rpm from CRAN) and gcc/g77 version 2.96. My library has a number of Fortran subroutines that have underscores in their names for readability. By default g77

I am trying to compile R 1.6.1 with gcc 3.2 on Solaris (Sun OS 5.8) and configure gives me: checking whether g77 and gcc agree on int and double... configure: WARNING: g77 and gcc disagree on int and double configure: error: Maybe change CFLAGS or FFLAGS? Complete output from configure is below. I am not setting CFLAGS or FFLAGS, but can someone suggest what I should set them to (or is this some

I remember someone saying that compiling flac with gcc 3.0 yields a broken executable. I saw this on the Lame list that might explain the problem. I don't have a gcc 3.0 setup yet but somebody may be able to verify this... --- Alexander Leidinger <Alexander@Leidinger.net> wrote: > From: Alexander Leidinger <Alexander@Leidinger.net> > Subject: Re: [MP3 ENCODER] Lame and

I have now tested R 1.3.1 compiled with GCC 3.0.2 on Solaris and the example I previously posted (repeated below) still gives a segmentation fault, as it does with GCC 3.0.1 but not with 2.95.2. The eigen calculation sometimes needs to be repeated several times before the segmentation fault occurs. La.eigen does not cause a problem. (The problem occurred with R-devel too, but I have not tested

As of quite recently I experience failures to compile source packages. Messages like * Installing *source* package 'dse1' ... ** libs g77 -mieee-fp -fPIC -g -O2 -c dsefor.f -o dsefor.o gcc -shared -o dse1.so dsefor.o -L/usr/lib/gcc-lib/i486-linux/3.3.3 -L/usr/lib/gcc-lib/i486-linux/3.3.3/../../.. -lfrtbegin -lg2c-pic -lm -lgcc_s -L/usr/lib/R/bin -lR /usr/bin/ld: no se puede

Please include a testcase with the patch. gas uses " nopl 0x0(%eax)" for k6_2. Are you sure it is a gas bug? On 3 November 2013 13:50, Mikulas Patocka <mikulas at artax.karlin.mff.cuni.cz> wrote: > Hi > > This patch fixes code generation bug - 586-class CPUs don't support the > nopl instruction and some 686-class CPUs don't support it too. > > I

Hello Laurent, Ray and Greg, I tried the gmake settings. Yet, I still got an Error code 1 message when I run the test. running regression tests don't know how to make ../library/base/R/base (bu42). *** Error code 1 (bu21) Thanks you if you have any idea. Manuel -----Message d'origine----- De : Laurent Gautier [ mailto:laurent at genome.cbs.dtu.dk <mailto:laurent at

Hi This patch fixes code generation bug - 586-class CPUs don't support the nopl instruction and some 686-class CPUs don't support it too. I created bug 17792 for that. BTW. I think you should also optimize padding on these CPUs - instead of a stream of 0x90 nops, you should generate variants of "lea (%esi), %esi" instruction like gcc. This patch disables generation of

On Mon, Feb 24, 2003 at 05:26:32PM -0800, H. Peter Anvin wrote: > Greg has taken on the job of integrating klibc with the kernel, but > please post klibc bug reports to the klibc mailing list at > <klibc@zytor.com>. To avoid annoying warning from gcc I had to check for compatibility with -falign-* like we do in arch/i386/Makefile. check_usergcc located in top-level makefile to

On FreeBSD 4.7 I noticed that when compiling kernel modules, the kernel options are not available to the modules. For example, my if_em.ko is not being compiled with the DEVICE_POLLING configuration It looks like "-include opt_global.h" is not being applied when compiling the module. Kernel compilation of if_em.c: cc -c -O2 -pipe -malign-loops=4 -malign-jumps=4 -malign-functions=4

I'm having trouble with make at the documentation. (R 0.63.2 on Solaris) Paul Gilbert ______ g77 -O2 -fPIC -c kmns.f -o kmns.o ld -G -o mva.so dblcen.o hclust.o kmns.o mkdir ../../../../library/mva/libs mkdir ../../../library/stepfun mkdir ../../../library/stepfun/R Building system startup profile You should `make docs' now ... make: Fatal error: Don't know how to make target