From adik at ilovebacon.org  Fri May 16 23:54:21 2008
From: adik at ilovebacon.org (Adam D. I. Kramer)
Date: Fri, 16 May 2008 14:54:21 -0700 (PDT)
Subject: [Rd] Configure errors say to report here... (PR#11470)
In-Reply-To: <8EAFC807-FCB2-4BCD-B92F-EB5082550DD2@r-project.org>
References: <20080516044025.294D52834170@mail.pubhealth.ku.dk>
	<8EAFC807-FCB2-4BCD-B92F-EB5082550DD2@r-project.org>
Message-ID: <Pine.LNX.4.64.0805161452100.3325@parser.ilovebacon.org>

Simon,

I apologize for wasting your time. When a configure script sets three lines
of text apart to say, "Report this to r-bugs at R-project.org" on three
different occasions, I figured it was polite to do so...but I do thank you
for your help, which with Dr. Ripley's was sufficient to get me compiled and
speedy. Thanks again!

--Adam

On Fri, 16 May 2008, Simon Urbanek wrote:

> Adam,
>
> this it not a bug in R, this is merely a user error. Please don't file 
> self-inflicted problems as bugs (see posting guide). For Mac-related 
> questions there is R-SIG-Mac. Brian's response was to the point - you break 
> the compilation with the custom flags you use. See details below.
>
> On May 16, 2008, at 12:40 AM, adik at ilovebacon.org wrote:
>
>> Hi,
>>
>> 	I'm attempting to compile R 2.7.0 on my G5, which is running OSX 
>> 10.5.2. Yes, I know there is a precompiled binary, but my experience has 
>> shown that if I hand-compile ATLAS on my machine and then link R against it 
>> when compiling, R runs faster, hence me compiling it myself.
>> 
>
> FWIW that is not necessary in general, you can plug in any BLAS by pointing 
> the libRblas.dylib symlink at it (or an umbrella stub created for it if it's 
> incomplete).
>
>
>> Anyway, I have this set of errors:
>> 
>> checking X11/Intrinsic.h usability... no
>> checking X11/Intrinsic.h presence... yes
>> configure: WARNING: X11/Intrinsic.h: present but cannot be compiled
>
> This is likely a mess up of your headers and libraries. It's not causing the 
> error, but still you're heading for trouble.
>
>
>> configure: WARNING: X11/Intrinsic.h:     check for missing prerequisite 
>> headers?
>> configure: WARNING: X11/Intrinsic.h: see the Autoconf documentation
>> configure: WARNING: X11/Intrinsic.h:     section "Present But Cannot Be 
>> Compiled"
>> configure: WARNING: X11/Intrinsic.h: proceeding with the preprocessor's 
>> result
>> configure: WARNING: X11/Intrinsic.h: in the future, the compiler will take 
>> precedence
>> configure: WARNING:     ## ----------------------------------- ##
>> configure: WARNING:     ## Report this to r-bugs at R-project.org ##
>> configure: WARNING:     ## ----------------------------------- ##
>> ...
>> checking X11/Xmu/Atoms.h usability... no
>> checking X11/Xmu/Atoms.h presence... yes
>> configure: WARNING: X11/Xmu/Atoms.h: present but cannot be compiled
>> configure: WARNING: X11/Xmu/Atoms.h:     check for missing prerequisite 
>> headers?
>> configure: WARNING: X11/Xmu/Atoms.h: see the Autoconf documentation
>> configure: WARNING: X11/Xmu/Atoms.h:     section "Present But Cannot Be 
>> Compiled"
>> configure: WARNING: X11/Xmu/Atoms.h: proceeding with the preprocessor's 
>> result
>> configure: WARNING: X11/Xmu/Atoms.h: in the future, the compiler will take 
>> precedence
>> configure: WARNING:     ## ----------------------------------- ##
>> configure: WARNING:     ## Report this to r-bugs at R-project.org ##
>> configure: WARNING:     ## ----------------------------------- ##
>> ...
>> checking tk.h usability... no
>> checking tk.h presence... yes
>> configure: WARNING: tk.h: present but cannot be compiled
>> configure: WARNING: tk.h:     check for missing prerequisite headers?
>> configure: WARNING: tk.h: see the Autoconf documentation
>> configure: WARNING: tk.h:     section "Present But Cannot Be Compiled"
>> configure: WARNING: tk.h: proceeding with the preprocessor's result
>> configure: WARNING: tk.h: in the future, the compiler will take precedence
>> configure: WARNING:     ## ----------------------------------- ##
>> configure: WARNING:     ## Report this to r-bugs at R-project.org ##
>> configure: WARNING:     ## ----------------------------------- ##
>> 
>> ...the command line item I pass to configure is this:
>> 
>> feta:R-2.7.0> ./configure --prefix=/usr/local --with-x 
>> --without-R-framework --without-aqua 
>> --with-blas="/usr/local/lib/libptf77blas.a /usr/local/lib/libatlas.a" 
>> --with-lapack="/usr/local/lib/liblapack.a /usr/local/lib/libptf77blas.a 
>> /usr/local/lib/libatlas.a" CFLAGS="-maltivec -mabi=altivec -mtune=970 
>> -faltivec -O3" CXXFLAGS="-maltivec -mabi=altivec -mtune=970 -faltivec -O3"
>> 
>
> Depending on your compiler this may not work, because you're forcing altivec 
> constructs which introduces new keywords to the C language. R doesn't use any 
> altivec commands so it will break the compilation (as you can see below). 
> [This is based on my memory - I cannot reproduce the problem on my G5, but 
> then I'm using more recent tools and OS, so your milleage may vary].
>
> BTW: I have no idea what you're trying to achieve with those flags, they are 
> essentially no-ops, because R doesn't contain any altivec code (and reals are 
> "double" in R and thus AltiVec is of no use anyway). If you want to optimize 
> for speed, have a look at posts by Jan de Leeuw and the old OptimizingR wiki 
> page (also see -fast in gcc and what it implies, although you need dynamic).
>
>
>> ...the rest of configure completes fine, though when I try to build R, I
>> make eventually ends up failing in this manner:
>> 
>> gcc -std=gnu99 -I. -I../../src/include -I../../src/include -I/sw/include 
>> -I/usr/local/include -DHAVE_CONFIG_H   -fPIC  -maltivec -mabi=altivec 
>> -mtune=970 -faltivec -O3 -c cpoly.c -o cpoly.o
>
> You're including /sw (Fink) - this is asking for trouble, because Fink 
> contains incompatible versions of system libraries and headers (likely this 
> causes the cpp problems above). Again, this is not the primary reason for the 
> failure, but I hope you won't ask for help with that binary ;).
>
> Cheers,
> Simon
>
>
>> 
>> 
>> cpoly.c: In function 'fxshft':
>> cpoly.c:299: error: expected identifier or '(' before 'unsigned'
>> cpoly.c:310: error: 'test' undeclared (first use in this function)
>> cpoly.c:310: error: (Each undeclared identifier is reported only once
>> cpoly.c:310: error: for each function it appears in.)
>> cpoly.c:315: error: expected expression before '__attribute__'
>> cpoly.c:326: error: expected expression before '__attribute__'
>> cpoly.c:327: error: expected expression before '__attribute__'
>> cpoly.c:334: error: expected expression before '__attribute__'
>> cpoly.c:370: error: expected expression before '__attribute__'
>> cpoly.c: In function 'vrshft':
>> cpoly.c:394: error: two or more data types in declaration specifiers
>> cpoly.c:394: error: expected identifier or '(' before ',' token
>> cpoly.c:399: error: 'b' undeclared (first use in this function)
>> cpoly.c:439: error: expected expression before '__attribute__'
>> cpoly.c:440: error: expected expression before '__attribute__'
>> cpoly.c:459: error: expected expression before '__attribute__'
>> cpoly.c:460: error: expected expression before '__attribute__'
>> cpoly.c:461: error: expected expression before '__attribute__'
>> cpoly.c:462: error: expected expression before '__attribute__'
>> cpoly.c: At top level:
>> cpoly.c:476: error: expected ';', ',' or ')' before 'unsigned'
>> cpoly.c:498: error: two or more data types in declaration specifiers
>> cpoly.c:498: error: conflicting types for 'nexth'
>> cpoly.c:81: error: previous declaration of 'nexth' was here
>> cpoly.c: In function 'nexth':
>> cpoly.c:498: error: parameter name omitted
>> cpoly.c:506: error: expected expression before '__attribute__'
>> make[3]: *** [cpoly.o] Error 1
>> make[2]: *** [R] Error 2
>> make[1]: *** [R] Error 1
>> make: *** [R] Error 1
>> 
>> ...the one reference to a problem like this I could find via google 
>> searches
>> is the post at
>> 
>> http://osdir.com/ml/lang.r.mac/2006-10/msg00016.html
>> 
>> regarding R 2.4.0, which I could not find a response to.
>> 
>
> You found the right thread with the right hint, except you interpreted it the 
> wrong way - altivec was needed by the Apple's Carbon headers (which are no 
> longer used), but in R itself it caused the problem you see in the post (and 
> thus yours).
>
>
>
>> Any help is appreciated!
>> 
>> Thanks,
>> Adam Kramer
>> 
>> ______________________________________________
>> R-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>> 
>> 
>



[Rd] Configure errors say to report here... (PR#11470)
Adam D. I. Kramer