[Rd] Snapshot server down?

[Rainer Hurling]

Hi maintainers,

When I try to download the tarball of the daily snapshot from 
https://stat.ethz.ch/R/daily, I get a


  '403 Forbidden'
  'You don't have permission to access this resource'.

It seems that the permissions were accidentally tightened?

Greetings,
Rainer Hurling

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

Re: [Rd] packageDate() segfaults, if used without argument

[Rainer Hurling]

Hi Martin,

Am 16.04.2018 um 09:03 schrieb Martin Maechler:

Rainer Hurling <rhur...@gwdg.de>
 on Sun, 15 Apr 2018 11:01:59 +0200 writes:


 > Out of curiosity, I played a bit with the new function
 > packageDate() from April, 4th. All works fine, except
 > using it without any argument.  In this case, it
 > segfaults:

Thank you, Rainer, for the report -- about the *development* version of R


Yupp.



Note that the segfault would not have happened in  'R 3.5.0 beta'
(today turning to be 'R 3.5.0 RC'  : RC := Release Candidate )
which we'd be very happy if you used extensively.


Ah, interesting news, that this does not occur with beta and RC.



 > #> packageDate() Error in packageDescription(pkg, lib.loc
 > = lib.loc, fields = date.fields) : argument "pkg" is
 > missing, with no default

 >  *** caught segfault *** address 0x77bc3c0, cause 'memory
 > not mapped' Segmentation fault (core dumped)

 > My system is FreeBSD 12.0-CURRENT amd64 with R-devel
 > (r74601).

It was a lapsus -- of mine -- not at all related to packageDate(),
corrected yesterday (svn r 74604).


Nice to here. Thanks for the fast response and greetings,
Rainer



Martin



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

[Rd] packageDate() segfaults, if used without argument

[Rainer Hurling]

Out of curiosity, I played a bit with the new function packageDate()
from April, 4th. All works fine, except using it without any argument.
In this case, it segfaults:


#> packageDate()
Error in packageDescription(pkg, lib.loc = lib.loc, fields = date.fields) :
  argument "pkg" is missing, with no default

 *** caught segfault ***
address 0x77bc3c0, cause 'memory not mapped'
Segmentation fault (core dumped)


My system is FreeBSD 12.0-CURRENT amd64 with R-devel (r74601).

Regards,
Rainer Hurling

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

Re: [Rd] changes in src/unix/system.c break builds on FreeBSD

[Rainer Hurling]

Am 09.02.2017 um 13:14 schrieb Prof Brian Ripley:
> On 09/02/2017 11:44, Rainer Hurling wrote:
>> Dear R devs,
>>
>> For some days now (~ February, 4th), I am not able to build the recent
>> tarballs of R-devel on a FreeBSD test box anymore. The breakage seems to
>> be related to the newest overhaul of src/unix/system.c:
>>
>>
>> [..snip..]
>> gcc49 -std=gnu99 -I. -I../../src/include -I../../src/include
>> -I/usr/local/include -DLIBICONV_PLUG -I/usr/local/include -isystem
>> /usr/local/include -DHAVE_CONFIG_H  -fopenmp -fpic  -O2 -pipe
>> -DLIBICONV_PLUG -fstack-protector -Wl,-rpath=/usr/local/lib/gcc49
>> -isystem /usr/local/include -fno-strict-aliasing -c system.c -o system.o
>> system.c: In function 'Rf_initialize_R':
>> system.c:213:13: error: 'RLIM_SAVED_CUR' undeclared (first use in this
>> function)
>>   if (lim == RLIM_SAVED_CUR || lim == RLIM_SAVED_MAX)
>>  ^
>> system.c:213:13: note: each undeclared identifier is reported only once
>> for each function it appears in
>> system.c:213:38: error: 'RLIM_SAVED_MAX' undeclared (first use in this
>> function)
>>   if (lim == RLIM_SAVED_CUR || lim == RLIM_SAVED_MAX)
>>   ^
>> system.c: In function 'R_GetFDLimit':
>> system.c:509:13: error: 'RLIM_SAVED_CUR' undeclared (first use in this
>> function)
>>   if (lim == RLIM_SAVED_CUR || lim == RLIM_SAVED_MAX)
>>  ^
>> system.c:509:38: error: 'RLIM_SAVED_MAX' undeclared (first use in this
>> function)
>>   if (lim == RLIM_SAVED_CUR || lim == RLIM_SAVED_MAX)
>>   ^
>> *** Error code 1
>>
>> Stop.
>> make[5]: stopped in /usr/ports/math/R-devel/work/R-devel/src/unix
>>
>>
>> Perhaps someone can give me a hint, want to do next?
> 
> Let us know (which you have).  This appears to be a lack of POSIX
> compliance on FreeBSD (even POSIX 2004, the current link being
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/getrlimit.html),
> so was unexpected and you ought to file a FreeBSD bug report.

This is a valuable hint for me, thanks.

In the meantime Mikko Korpela noted, that there already exists a FreeBSD
bugzilla report, which tries to implement the two missing definitions.
But there seems to be a problem with the 64 bit signed format of
RLIM_INFINITY, which was discussed, but not solved.

I will try to restart the discussion of that report and to push it
towards a solution.

> 
> I'll add a workaround in R-devel in r72147: let us know if that does not
> suffice.

Many thanks for the very quick help with this workaround. It works for
me at a recent FreeBSD 12.0-CURRENT amd64 box.

First small tests do not indicate, that there is a regression with it.

> 
>>
>> Please let me know, if I should provide more information or can test
>> something.
>>
>> Many thanks in advance,
>> Rainer Hurling

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

[Rd] changes in src/unix/system.c break builds on FreeBSD

[Rainer Hurling]

Dear R devs,

For some days now (~ February, 4th), I am not able to build the recent
tarballs of R-devel on a FreeBSD test box anymore. The breakage seems to
be related to the newest overhaul of src/unix/system.c:


[..snip..]
gcc49 -std=gnu99 -I. -I../../src/include -I../../src/include
-I/usr/local/include -DLIBICONV_PLUG -I/usr/local/include -isystem
/usr/local/include -DHAVE_CONFIG_H  -fopenmp -fpic  -O2 -pipe
-DLIBICONV_PLUG -fstack-protector -Wl,-rpath=/usr/local/lib/gcc49
-isystem /usr/local/include -fno-strict-aliasing -c system.c -o system.o
system.c: In function 'Rf_initialize_R':
system.c:213:13: error: 'RLIM_SAVED_CUR' undeclared (first use in this
function)
  if (lim == RLIM_SAVED_CUR || lim == RLIM_SAVED_MAX)
 ^
system.c:213:13: note: each undeclared identifier is reported only once
for each function it appears in
system.c:213:38: error: 'RLIM_SAVED_MAX' undeclared (first use in this
function)
  if (lim == RLIM_SAVED_CUR || lim == RLIM_SAVED_MAX)
  ^
system.c: In function 'R_GetFDLimit':
system.c:509:13: error: 'RLIM_SAVED_CUR' undeclared (first use in this
function)
  if (lim == RLIM_SAVED_CUR || lim == RLIM_SAVED_MAX)
 ^
system.c:509:38: error: 'RLIM_SAVED_MAX' undeclared (first use in this
function)
  if (lim == RLIM_SAVED_CUR || lim == RLIM_SAVED_MAX)
  ^
*** Error code 1

Stop.
make[5]: stopped in /usr/ports/math/R-devel/work/R-devel/src/unix


Perhaps someone can give me a hint, want to do next?

Please let me know, if I should provide more information or can test
something.

Many thanks in advance,
Rainer Hurling

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

Re: [Rd] No new daily R-devel tarball since r69202?

[Rainer Hurling]

Am 05.09.2015 um 19:09 schrieb peter dalgaard:
> 
>> On 05 Sep 2015, at 13:54 , Rainer Hurling <rhur...@gwdg.de> wrote:
>>
>> Am 05.09.2015 um 10:18 schrieb peter dalgaard:
>>>
>>>> On 05 Sep 2015, at 08:28 , Rainer Hurling <rhur...@gwdg.de> wrote:
>>>>
>>>> Is there any reason that the R-devel tarball at [1] stucks on r69202?
>>>>
>>>> It seems, that newer R-devel versions are now published on
>>>> /pub/misc/cran/src/base-prerelease, for example at
>>>> http://ftp5.gwdg.de/pub/misc/cran/, but without an R-devel.tar.gz
>>>> tarball ...
>>>>
>>>> Is this intended? Any clarification would be appreciated.
>>>
>>> Probably not (it is on Martin Maechler's turf, though). These things are 
>>> run by cron jobs, and sometimes they get stalled. It is also possible that 
>>> a change to the build tools on that machine caused the tarballs to fail 
>>> their builds (the way things work, you need to build R before you can build 
>>> the tarball.)
>>
>> Yes, I am aware of the build process before the tarball. The mail should
>> only take some attention on it ;)
>>
>> Since end of August, there had been a change of the location, where
>> devel and patched sources are located: from
>> https://stat.ethz.ch/R/daily/ to
>> ::mirror::/pub/misc/cran/src/base-prerelease/
> 
> There is no change, there has been two locations for a while now. One is an 
> extension of the alpha/beta/RC-releases built by me, leading up to the 
> release tarballs, the other maintained by Martin/ETHZ for a much longer time. 
> The issue is just that Martin's updates seem to have been stalled for some 
> reason.
> 
> This configuration sort of came sneaking up on us (long story...), so the 
> CRAN descriptions are not completely precise.

Thanks for the clarification. So it was intended to have two different
places with (slightly) different aims.

> It's not a big deal for me to set up so that there is also an 
> R-devel-latest.tar.gz or so in base-prerelease.

This would be nice, but it only should be necessary, if the ETHZ server
would not come up again with this service.

Many thanks again for your answer and for the proposal.

Greetings,
Rainer Hurling

> 
> -pd
> 
>>
>> Perhaps something with the cron jobs did not follow these changes?
>>
>>> Is there a need for an R-devel.tar.gz in src/base-prerelease? It would just 
>>> be a copy of the most recent one.
>>
>> I prefer the R-devel.tar.gz without date and version number for
>> automated fetching and building R-devel on FreeBSD on an almost daily basis.
>>
>> Many thanks for your answer.
>>
>> Regards,
>> Rainer Hurling
>>
>>>
>>> -pd
>>>
>>>>
>>>> Thanks and greetings,
>>>> Rainer Hurling
>>>>
>>>>
>>>> [1] https://stat.ethz.ch/R/daily/R-devel.tar.gz
>

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

[Rd] No new daily R-devel tarball since r69202?

[Rainer Hurling]

Is there any reason that the R-devel tarball at [1] stucks on r69202?

It seems, that newer R-devel versions are now published on
/pub/misc/cran/src/base-prerelease, for example at
http://ftp5.gwdg.de/pub/misc/cran/, but without an R-devel.tar.gz
tarball ...

Is this intended? Any clarification would be appreciated.

Thanks and greetings,
Rainer Hurling


[1] https://stat.ethz.ch/R/daily/R-devel.tar.gz

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

Re: [Rd] No new daily R-devel tarball since r69202?

[Rainer Hurling]

Am 05.09.2015 um 10:18 schrieb peter dalgaard:
> 
>> On 05 Sep 2015, at 08:28 , Rainer Hurling <rhur...@gwdg.de> wrote:
>>
>> Is there any reason that the R-devel tarball at [1] stucks on r69202?
>>
>> It seems, that newer R-devel versions are now published on
>> /pub/misc/cran/src/base-prerelease, for example at
>> http://ftp5.gwdg.de/pub/misc/cran/, but without an R-devel.tar.gz
>> tarball ...
>>
>> Is this intended? Any clarification would be appreciated.
> 
> Probably not (it is on Martin Maechler's turf, though). These things are run 
> by cron jobs, and sometimes they get stalled. It is also possible that a 
> change to the build tools on that machine caused the tarballs to fail their 
> builds (the way things work, you need to build R before you can build the 
> tarball.)

Yes, I am aware of the build process before the tarball. The mail should
only take some attention on it ;)

Since end of August, there had been a change of the location, where
devel and patched sources are located: from
https://stat.ethz.ch/R/daily/ to
::mirror::/pub/misc/cran/src/base-prerelease/

Perhaps something with the cron jobs did not follow these changes?

> Is there a need for an R-devel.tar.gz in src/base-prerelease? It would just 
> be a copy of the most recent one.

I prefer the R-devel.tar.gz without date and version number for
automated fetching and building R-devel on FreeBSD on an almost daily basis.

Many thanks for your answer.

Regards,
Rainer Hurling

> 
> -pd
> 
>>
>> Thanks and greetings,
>> Rainer Hurling
>>
>>
>> [1] https://stat.ethz.ch/R/daily/R-devel.tar.gz
>>

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

Re: [Rd] Building r-devel fails on Ubuntu (old and new as well)

[Rainer Hurling]

Am 16.07.2015 um 14:08 schrieb Martin Maechler:
 Gábor Csárdi csardi.ga...@gmail.com
 on Thu, 16 Jul 2015 07:18:00 -0400 writes:
 
  ...
  making array.d from array.c
  array.c:33:23: fatal error: duplicate.h: No such file or directory
  compilation terminated.
  ...
 
  https://travis-ci.org/metacran/r-builder/builds/71225331#L7405
 
 Yes.  That's what R-devel is: in development and so, human errors do happen.
 ...  and are corrected. ... already more than half an hour ago.

Hmm, I'm a bit confused. Now we can find duplicate.h in trunk, but it
still seems to be missing in the devel tarballs. (At least until
R-devel_2015-07.18.tar.gz)

 
 No need to trumpet to the world... I think
 (R-core would have been sufficient (and unnecessary this time)).

?? I also would have reported it on R-devel. Is this a special case with
special handling?

Sorry, when I have missed something.

Best wishes,
Rainer Hurling

 
 Martin

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

Re: [Rd] Building r-devel fails on Ubuntu (old and new as well)

[Rainer Hurling]

Am 19.07.2015 um 10:19 schrieb peter dalgaard:
 An updated tarball should be available in $CRAN/src/base/pre-release soon. 
 (For CRAN=https://cran.r-project.org, immediately. Other mirrors need 
 mirroring.)

Wow, that's fast! Many thanks for the update.

Greetings,
Rainer Hurling


 
 -pd
 
 On 19 Jul 2015, at 10:01 , peter dalgaard pda...@gmail.com wrote:

 Looks like someone forgot to update the DISTFILES (specifically the HEADERS) 
 in src/main/Makefile.in...

 -pd

 On 19 Jul 2015, at 09:42 , Rainer Hurling rhur...@gwdg.de wrote:

 Hmm, I'm a bit confused. Now we can find duplicate.h in trunk, but it
 still seems to be missing in the devel tarballs. (At least until
 R-devel_2015-07.18.tar.gz)

 -- 
 Peter Dalgaard, Professor,
 Center for Statistics, Copenhagen Business School
 Solbjerg Plads 3, 2000 Frederiksberg, Denmark
 Phone: (+45)38153501
 Email: pd@cbs.dk  Priv: pda...@gmail.com

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

Re: [Rd] Small typo in german translation

[Rainer Hurling]

Am 16.02.2015 um 15:03 schrieb Uwe Ligges:
 Please send comments related to transaltions to the corresponding
 translation teams:
 
 http://developer.r-project.org/TranslationTeams.html
 In this case I am CCIng Detlef Steuer.

Of course, you are right. Next time, I will do so.

Thanks for your hint, and also to Detlef for taking it.

Greetings,
Rainer Hurling

 
 Best,
 Uwe Ligges
 
 
 
 On 16.02.2015 09:29, Rainer Hurling wrote:
 Dear developers,

 I found a small typo in the german translation for the aggregate()
 function:

 In the string keine Zeile für die Aggragation it should be spelled
 'Aggregation' instead of 'Aggragation' (e instead a).

 After a quick look into the sources, I found two places for it:

 #grep -r -e Aggragation *
 src/library/stats/po/R-de.po:msgstr keine Zeile für die Aggragation
 Binary file src/library/translations/inst/de/LC_MESSAGES/R-stats.mo
 matches

 This is (at least) on R-devel, I did not look into other versions. Hope,
 it is ok to not offer a diff for it.

 Thanks for all your work.

 Best regards,
 Rainer Hurling

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

[Rd] Small typo in german translation

[Rainer Hurling]

Dear developers,

I found a small typo in the german translation for the aggregate() function:

In the string keine Zeile für die Aggragation it should be spelled 
'Aggregation' instead of 'Aggragation' (e instead a).


After a quick look into the sources, I found two places for it:

#grep -r -e Aggragation *
src/library/stats/po/R-de.po:msgstr keine Zeile für die Aggragation
Binary file src/library/translations/inst/de/LC_MESSAGES/R-stats.mo matches

This is (at least) on R-devel, I did not look into other versions. Hope, 
it is ok to not offer a diff for it.


Thanks for all your work.

Best regards,
Rainer Hurling

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

[Rd] Daily snapshots of sources do not work?

[Rainer Hurling]

For some days now there had been no more daily snapshots on

ftp://ftp.stat.math.ethz.ch/Software/R/ .

The latest sources are from 07/26/2012. I think this is not indented?

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

Re: [Rd] R-devel on FreeBSD: new C99 functions don't build

[Rainer Hurling]

On 18.05.2012 16:15 (UTC+1), Prof Brian Ripley wrote:

On 15/05/2012 20:45, Rainer Hurling wrote:

On 15.05.2012 20:49 (UTC+1), Murray Stokely wrote:

On Tue, May 15, 2012 at 10:05 AM, Rainer Hurlingrhur...@gwdg.de wrote:

About April 25th, there had been some changes within R-devel's
src/nmath/pnbeta.c (and probably some other relevant places) and now
building R-devel on FreeBSD 10.0-CURRENT (amd64) with gcc-4.6.4 and
math/R-devel (selfmade forked port from math/R) fails like this:



It seems, that at least one new C99 function (log1pl) is introduced in
R-devel, see

src/nmath/pnbeta.c:l95
return (double) (log_p ? log1pl(-ans) : (1 - ans));


AFAIK, Bruce Evans is not happy with the numerical accuracy of other
open-source implementations of log1pl and so has blocked their
inclusion in FreeBSD pending work on a better implementation.

Can you put a conditional FreeBSD check here and use log1p instead of
log1pl instead as a workaround?

I can admire the insistence on correctness from the FreeBSD libm
maintainers for their technical purity, but it can be a bit of a pain
for things like this.

- Murray


I read about this discussion and in principle I concur with your
opinion. As a scientist I tend to expect greatest possible correctness
from a statistical routine, especially when it uses long double format.

As a quick and dirty workaround I applied the following patch:


--- src/nmath/pnbeta.c.orig 2012-04-25 17:55:14.0 +0200
+++ src/nmath/pnbeta.c 2012-05-15 20:58:26.0 +0200
@@ -92,7 +92,11 @@
else {
if(ans  1 - 1e-10) ML_ERROR(ME_PRECISION, pnbeta);
if (ans  1.0) ans = 1.0; /* Precaution */
+#if !defined(__FreeBSD__)
return (double) (log_p ? log1pl(-ans) : (1 - ans));
+#else
+ return (double) (log_p ? log1p(-ans) : (1 - ans));
+#endif /* FreeBSD */
}
}


It builds and installs fine now and I hope there are no side effects ...


Note though that R has *required* C99 compliance for quite a while, and
that is not now even the current C standard. Using an OS that fails to
comply to a 12-year-old standard is your own choice ... and you get the
choice of using an equally old version of R.


Of course you are right with C99 compliance on FreeBSD. It is a long 
outstanding issue to get these long double functions in.


For me personally there are *many* reasons to use FreeBSD and at the 
moment R is one of only very few software packages we have serious 
trouble with C99 functions.


As you know, using an old version of R is not a real options. Because of 
that, we are looking at R-devel to find problems with FreeBSD in good time.



I've added log1pl to the depressing list of FreeBSD workarounds:
untested as I currently don't have access to a FreeBSD setup.


Many thanks for the patch. I built it and it is much more elegant than 
my workaround (HAVE_LOG1PL, log1p with double). And yes, the list is 
depressing.



However, I think this has to come to an end: if a project such as
Mingw-w64 can make the effort to supply a great deal of the C99
functions missing from their OS then we must expect FreeBSD to do likewise.


As I said before, I agree with this point of view. But I am not a 
developer and a am not standing for the FreeBSD project. I am only an 
interested user and a maintainer for a few small FreeBSD ports 
(adaptions of third party software).


I will ask the FreeBSD people again for better C99 compliance ...

I really appreciate your help on this annoying issues and hope we will 
find a solution on FreeBSD in the near future.


Regards,
Rainer Hurling

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

[Rd] R-devel on FreeBSD: new C99 functions don't build

[Rainer Hurling]

About April 25th, there had been some changes within R-devel's 
src/nmath/pnbeta.c (and probably some other relevant places) and now 
building R-devel on FreeBSD 10.0-CURRENT (amd64) with gcc-4.6.4 and 
math/R-devel (selfmade forked port from math/R) fails like this:


[..snip..]
mkdir /usr/ports/math/R-devel/work/R-devel/bin/exec
gcc46 -std=gnu99 -I../../src/extra   -I. -I../../src/include 
-I../../src/include -I/usr/local/include -DHAVE_CONFIG_H  -fopenmp -fpic 
   -O2 -pipe -O2 -fno-strict-aliasing -pipe -msse3 
-Wl,-rpath=/usr/local/lib/gcc46 -c Rmain.c -o Rmain.o
gcc46 -std=gnu99 -export-dynamic -fopenmp -L/usr/local/lib 
-Wl,-rpath=/usr/local/lib/gcc46 -o R.bin Rmain.o -L../../lib -lR -lRblas

../../lib/libR.so: undefined reference to `log1pl'
collect2: ld returned 1 exit status
*** [R.bin] Error code 1
Stop in /usr/ports/math/R-devel/work/R-devel/src/main.
*** [R] Error code 1
Stop in /usr/ports/math/R-devel/work/R-devel/src/main.
*** [R] Error code 1
Stop in /usr/ports/math/R-devel/work/R-devel/src.
*** [R] Error code 1
Stop in /usr/ports/math/R-devel/work/R-devel.
*** [do-build] Error code 1
Stop in /usr/ports/math/R-devel.
*** [build] Error code 1
Stop in /usr/ports/math/R-devel.
=== make failed for math/R-devel


It seems, that at least one new C99 function (log1pl) is introduced in 
R-devel, see


src/nmath/pnbeta.c:l95
return (double) (log_p ? log1pl(-ans) : (1 - ans));

for which there is only a declaration in FreeBSDs math.h, but no full 
implementation in libm (see http://wiki.freebsd.org/MissingMathStuff).


Is there any chance to get at least rudimentary replacement functions in 
R-devel for systems with missing or defective C99 math functions?


(For example, in the similar case of log1p(), see the RMATH_HAVE_LOG1P 
and RMATH_HAVE_WORKING_LOG1P bits in the configure script, 
src/include/Rmath.h0.in, and src/nmath/log1p.c; thanks to b.f. for 
pointing me out to this).


Thanks for any help,
Rainer Hurling


CC'ed to b.f. as the maintainer of the math/R port on FreeBSD.

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

Re: [Rd] R-devel on FreeBSD: new C99 functions don't build

[Rainer Hurling]

On 15.05.2012 20:49 (UTC+1), Murray Stokely wrote:

On Tue, May 15, 2012 at 10:05 AM, Rainer Hurlingrhur...@gwdg.de  wrote:

About April 25th, there had been some changes within R-devel's
src/nmath/pnbeta.c (and probably some other relevant places) and now
building R-devel on FreeBSD 10.0-CURRENT (amd64) with gcc-4.6.4 and
math/R-devel (selfmade forked port from math/R) fails like this:



It seems, that at least one new C99 function (log1pl) is introduced in
R-devel, see

src/nmath/pnbeta.c:l95
return (double) (log_p ? log1pl(-ans) : (1 - ans));


AFAIK, Bruce Evans is not happy with the numerical accuracy of other
open-source implementations of log1pl and so has blocked their
inclusion in FreeBSD pending work on a better implementation.

Can you put a conditional FreeBSD check here and use log1p instead of
log1pl instead as a workaround?

I can admire the insistence on correctness from the FreeBSD libm
maintainers for their technical purity, but it can be a bit of a pain
for things like this.

  - Murray


I read about this discussion and in principle I concur with your 
opinion. As a scientist I tend to expect greatest possible correctness 
from a statistical routine, especially when it uses long double format.


As a quick and dirty workaround I applied the following patch:


--- src/nmath/pnbeta.c.orig 2012-04-25 17:55:14.0 +0200
+++ src/nmath/pnbeta.c  2012-05-15 20:58:26.0 +0200
@@ -92,7 +92,11 @@
 else {
if(ans  1 - 1e-10) ML_ERROR(ME_PRECISION, pnbeta);
if (ans  1.0) ans = 1.0;  /* Precaution */
+#if !defined(__FreeBSD__)
return (double) (log_p ? log1pl(-ans) : (1 - ans));
+#else
+return (double) (log_p ? log1p(-ans) : (1 - ans));
+#endif /* FreeBSD */
 }
 }


It builds and installs fine now and I hope there are no side effects ...

Thank you for the quick answer and your advice,
Rainer

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

Re: [Rd] lubridate does not install on FreeBSD any more

[Rainer Hurling]

Am 11.01.2012 11:58 (UTC+1) schrieb Rainer Hurling:

On 11.01.2012 11:32 (UTC+1), Uwe Ligges wrote:

On 11.01.2012 11:13, Rainer Hurling wrote:

With newest R devel

#sessionInfo()
R Under development (unstable) (2012-01-10 r58085)
Platform: amd64-portbld-freebsd10.0 (64-bit)
locale:
[1]
de_DE.ISO8859-15/de_DE.ISO8859-15/de_DE.ISO8859-15/C/de_DE.ISO8859-15/de_DE.ISO8859-15



attached base packages:
[1] stats graphics grDevices utils datasets methods base

I get the following error when I try to build and install lubridate from
sources on FreeBSD 10.0-CURRENT (amd64):

#R CMD INSTALL lubridate_0.2.6.tar.gz
* installing to library '/usr/local/lib/R/library'
* installing *source* package 'lubridate' ...
** package 'lubridate' successfully unpacked and MD5 sums checked
** R
** data
** moving datasets to lazyload DB
** inst
** preparing package for lazy loading
** help
*** installing help indices
** building package indices
** testing if installed package can be loaded
During startup - Warning messages:
1: Setting LC_CTYPE failed, using C
2: Setting LC_TIME failed, using C
3: Setting LC_MESSAGES failed, using C
4: Setting LC_PAPER failed, using C
Error : .onLoad failed in loadNamespace() for 'lubridate', details:
call: utils::assignInNamespace(+.Date, add_dates, base)
error: locked binding of '+.Date' cannot be changed
Error: loading failed
Execution halted
ERROR: loading failed
* removing '/usr/local/lib/R/library/lubridate'
* restoring previous '/usr/local/lib/R/library/lubridate'


Do you have any idea what is going on here?


Yes: locked bindings cannot be changed in R-devel any more, and
lubridate does that. The maintainer has been asked for an update already.

Uwe Ligges


Thanks in advance,
Rainer Hurling


Thanks, Uwe Ligges and Peter Dalgaard, for clarifying this. So we have
to wait for an update ...


Just for the record. With the new version 1.1.0 I am able to build and 
install lubridate on FreeBSD again.


Thanks for the work,
Rainer Hurling

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

[Rd] lubridate does not install on FreeBSD any more

[Rainer Hurling]

With newest R devel

#sessionInfo()
R Under development (unstable) (2012-01-10 r58085)
Platform: amd64-portbld-freebsd10.0 (64-bit)
locale:
[1] 
de_DE.ISO8859-15/de_DE.ISO8859-15/de_DE.ISO8859-15/C/de_DE.ISO8859-15/de_DE.ISO8859-15

attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base

I get the following error when I try to build and install lubridate from 
sources on FreeBSD 10.0-CURRENT (amd64):


#R CMD INSTALL lubridate_0.2.6.tar.gz
* installing to library '/usr/local/lib/R/library'
* installing *source* package 'lubridate' ...
** package 'lubridate' successfully unpacked and MD5 sums checked
** R
** data
**  moving datasets to lazyload DB
** inst
** preparing package for lazy loading
** help
*** installing help indices
** building package indices
** testing if installed package can be loaded
During startup - Warning messages:
1: Setting LC_CTYPE failed, using C
2: Setting LC_TIME failed, using C
3: Setting LC_MESSAGES failed, using C
4: Setting LC_PAPER failed, using C
Error : .onLoad failed in loadNamespace() for 'lubridate', details:
  call: utils::assignInNamespace(+.Date, add_dates, base)
  error: locked binding of '+.Date' cannot be changed
Error: loading failed
Execution halted
ERROR: loading failed
* removing '/usr/local/lib/R/library/lubridate'
* restoring previous '/usr/local/lib/R/library/lubridate'


Do you have any idea what is going on here?

Thanks in advance,
Rainer Hurling

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

Re: [Rd] lubridate does not install on FreeBSD any more

[Rainer Hurling]

On 11.01.2012 11:32 (UTC+1), Uwe Ligges wrote:

On 11.01.2012 11:13, Rainer Hurling wrote:

With newest R devel

#sessionInfo()
R Under development (unstable) (2012-01-10 r58085)
Platform: amd64-portbld-freebsd10.0 (64-bit)
locale:
[1]
de_DE.ISO8859-15/de_DE.ISO8859-15/de_DE.ISO8859-15/C/de_DE.ISO8859-15/de_DE.ISO8859-15


attached base packages:
[1] stats graphics grDevices utils datasets methods base

I get the following error when I try to build and install lubridate from
sources on FreeBSD 10.0-CURRENT (amd64):

#R CMD INSTALL lubridate_0.2.6.tar.gz
* installing to library '/usr/local/lib/R/library'
* installing *source* package 'lubridate' ...
** package 'lubridate' successfully unpacked and MD5 sums checked
** R
** data
** moving datasets to lazyload DB
** inst
** preparing package for lazy loading
** help
*** installing help indices
** building package indices
** testing if installed package can be loaded
During startup - Warning messages:
1: Setting LC_CTYPE failed, using C
2: Setting LC_TIME failed, using C
3: Setting LC_MESSAGES failed, using C
4: Setting LC_PAPER failed, using C
Error : .onLoad failed in loadNamespace() for 'lubridate', details:
call: utils::assignInNamespace(+.Date, add_dates, base)
error: locked binding of '+.Date' cannot be changed
Error: loading failed
Execution halted
ERROR: loading failed
* removing '/usr/local/lib/R/library/lubridate'
* restoring previous '/usr/local/lib/R/library/lubridate'


Do you have any idea what is going on here?


Yes: locked bindings cannot be changed in R-devel any more, and
lubridate does that. The maintainer has been asked for an update already.

Uwe Ligges


Thanks in advance,
Rainer Hurling


Thanks, Uwe Ligges and Peter Dalgaard, for clarifying this. So we have 
to wait for an update ...


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

Re: [Rd] Problem with creating default NAMESPACE on FreeBSD

[Rainer Hurling]

On 22.07.2011 14:50 (UTC+1), Prof Brian Ripley wrote:

One possibility is that you are building from a tarball snapshot without
mentioning it, and the (unspecified) tarball is incomplete.

For R-devel using tarballs is not a wise idea: they are really only
checked carefully in pre-release periods. (One of the checks is that
AFAIR CRAN builds from the tarballs, but CRAN is not manned at present.)

But as far as I can the 'make dist' procedure does work now and did at
some point in the last week.

On Fri, 22 Jul 2011, Prof Brian Ripley wrote:


It does not seem to happen to anyone else, including me on FreeBSD. Is
this a completely clean install? src/library/datasets/Makefile
definitely installs a NAMESPACE file as part of the mkR1 target, so I
would check that you have a src/library/datasets/NAMESPACE file in
your sources.

(There was a short window on the 16th when it happened as a commit for
src/library/datasets/NAMESPACE was missed at first.)


Many thanks for answering and sorry for the late reaction. We had some 
trouble in business yesterday.


It was not a totally clean installation before. I only deinstalled the 
old R version before installing the new one in the same place (make 
deinstall / make reinstall with a selfmade port math/R-devel for testing 
purposes). Other packages etc. had not been deleted before.


I forgot to mention that there were warnings in the build for several 
packages, like that:


installing to /usr/ports/math/R-devel/work/R-devel/library/mgcv/libs
** R
** data
** inst
** byte-compile and prepare package for lazy loading
** help
*** installing help indices
** building package indices ...
** testing if installed package can be loaded
During startup - Warning message:
package 'datasets' in options(defaultPackages) was not found

BUT:
Today I tried again with newest version r56478 and surprisingly, all 
that problems disappeared. Even no more warnings at build time.


For sureness I checked again older versions (between 15.07. and 21.07) 
but the build warnings there exist, with version r56478 they went away.


Rainer Hurling


P.S.: Thanks for the hint with the problems of the tarball. I had not 
been aware of it. In this case here it (mostly) also works with the 
tarball version.





On Fri, 22 Jul 2011, Rainer Hurling wrote:


After building and installing R-devel from 21/07/2011 on FreeBSD
9.0-CURRENT (amd64), starting R gives the following warning:

[..snip..]
Beim Start - Warnmeldung:
package 'datasets' in options(defaultPackages) was not found

This happens with all versions after 14/07/2011. I think it is
related to

NEWS Sat, 16 Jul 2011
CHANGES IN R-devel PACKAGE INSTALLATION
Packages without explicit ‘NAMESPACE’ files will have a default one
created at build or INSTALL time, so all packages will have
namespaces. A consequence of this is that ‘.First.lib’ functions need
to be renamed, usually as ‘.onLoad’ but sometimes as ‘.onAttach’.


Package 'datasets' seems to be installed correctly under
/usr/local/lib/R/library/:

ls -l datasets/
total 18
-rw-r--r-- 1 root wheel - 289 22 Jul 08:12:04 2011 DESCRIPTION
-rw-r--r-- 1 root wheel - 5547 22 Jul 08:12:04 2011 INDEX
drwxr-xr-x 2 root wheel - 512 22 Jul 08:12:04 2011 Meta
drwxr-xr-x 2 root wheel - 512 22 Jul 08:12:04 2011 R
drwxr-xr-x 2 root wheel - 512 22 Jul 08:12:04 2011 data
drwxr-xr-x 2 root wheel - 512 22 Jul 08:12:04 2011 help
drwxr-xr-x 2 root wheel - 512 22 Jul 08:12:04 2011 html


Calling options(defaultPackages) shows all relevant packages:

$defaultPackages
[1] datasets utils grDevices graphics stats methods


But trying to load library 'datasets' fails with the following message:

library(datasets)
Fehler in library(datasets) :
package 'datasets' does not have a NAMESPACE and should be re-installed


Googling around for some days now it looks like this does not happen
to anyone else (at least there are no infos). Does anybody knows what
is going on here?

Any help would be appreciated,
Rainer Hurling



sessionInfo()
R Under development (unstable) (2011-07-21 r56467)
Platform: amd64-portbld-freebsd9.0 (64-bit)

locale:
[1]
de_DE.ISO8859-15/de_DE.ISO8859-15/de_DE.ISO8859-15/C/de_DE.ISO8859-15/de_DE.ISO8859-15


attached base packages:
[1] stats graphics grDevices utils methods base


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

[Rd] Problem with creating default NAMESPACE on FreeBSD

[Rainer Hurling]

After building and installing R-devel from 21/07/2011 on FreeBSD 
9.0-CURRENT (amd64), starting R gives the following warning:


[..snip..]
Beim Start - Warnmeldung:
package 'datasets' in options(defaultPackages) was not found

This happens with all versions after 14/07/2011. I think it is related to

NEWS Sat, 16 Jul 2011
CHANGES IN R-devel PACKAGE INSTALLATION
Packages without explicit ‘NAMESPACE’ files will have a default one 
created at build or INSTALL time, so all packages will have namespaces. 
A consequence of this is that ‘.First.lib’ functions need to be renamed, 
usually as ‘.onLoad’ but sometimes as ‘.onAttach’.



Package 'datasets' seems to be installed correctly under 
/usr/local/lib/R/library/:


ls -l datasets/
total 18
-rw-r--r--  1 root  wheel  -  289 22 Jul 08:12:04 2011 DESCRIPTION
-rw-r--r--  1 root  wheel  - 5547 22 Jul 08:12:04 2011 INDEX
drwxr-xr-x  2 root  wheel  -  512 22 Jul 08:12:04 2011 Meta
drwxr-xr-x  2 root  wheel  -  512 22 Jul 08:12:04 2011 R
drwxr-xr-x  2 root  wheel  -  512 22 Jul 08:12:04 2011 data
drwxr-xr-x  2 root  wheel  -  512 22 Jul 08:12:04 2011 help
drwxr-xr-x  2 root  wheel  -  512 22 Jul 08:12:04 2011 html


Calling options(defaultPackages) shows all relevant packages:

$defaultPackages
[1] datasets  utils grDevices graphics  stats methods


But trying to load library 'datasets' fails with the following message:

library(datasets)
Fehler in library(datasets) :
  package 'datasets' does not have a NAMESPACE and should be re-installed


Googling around for some days now it looks like this does not happen to 
anyone else (at least there are no infos). Does anybody knows what is 
going on here?


Any help would be appreciated,
Rainer Hurling



sessionInfo()
R Under development (unstable) (2011-07-21 r56467)
Platform: amd64-portbld-freebsd9.0 (64-bit)

locale:
[1] 
de_DE.ISO8859-15/de_DE.ISO8859-15/de_DE.ISO8859-15/C/de_DE.ISO8859-15/de_DE.ISO8859-15


attached base packages:
[1] stats graphics  grDevices utils methods   base

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

[Rd] Undefined symbol Rf_pythag while loading spatstat

[Rainer Hurling]

Today I installed the newest R develepment branch
R version 2.14.0 Under development (unstable) (2011-03-18 r54866)
on FreeBSD 9.0-CURRENT (amd64). All seems fine so far.

After that I updated my R packages with option 'checkBuilt=TRUE'. There 
are four packages (spatstat, pscl, adehabitatLT, adehabitatHR) which 
gives an error like this:


Error in dyn.load(file, DLLpath = DLLpath, ...) :
  kann shared object 
'/usr/local/lib/R/library/spatstat/libs/spatstat.so' nicht laden:
  /usr/local/lib/R/library/spatstat/libs/spatstat.so: Undefined symbol 
Rf_pythag

Fehler: loading failed
Ausführung angehalten
Fehler: loading failed


Searching around I found a hint in 
http://developer.r-project.org/R_svnlog_2011 about upcoming changes with 
'Rf_pythag':



r54767 | ripley | 2011-03-13 07:30:32 -0400 (Sun, 13 Mar 2011) | 1 line
Changed paths:
   M /trunk/doc/NEWS.Rd
   M /trunk/src/include/Rmath.h0.in
   M /trunk/src/nmath/imax2.c

keep Rf_pythag for a little longer



R News of newest devel has three entries about the change:

CHANGES IN R VERSION 2.14.0:
  DEPRECATED AND DEFUNCT:
o The entry point pythag formerly in Rmath.h is defunct: use
  instead the C99 function hypot.
CHANGES IN R VERSION 2.13.0:
  C-LEVEL FACILITIES:
o pythag duplicated the C99 function hypot.  It is no longer
  provided, but is used a substitute for hypot in the very unlikely
  event that the latter is not available.
  DEPRECATED  DEFUNCT:
o The entry point pythag in Rmath.h is deprecated in favour of the
  C99 function hypot.  A wrapper for hypot is provided for R 2.13.x
  only.


Because of that informations I attempted to change 'pythag' against 
'hypot' in spatstat/src/lookup.c and it works. Is this the only required 
adaption which has to be done on the four named packages?


Thanks in advance,
Rainer Hurling

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

Re: [Rd] Undefined symbol Rf_pythag while loading spatstat

[Rainer Hurling]

On 19.03.2011 15:52 (UTC+1), Prof Brian Ripley wrote:

On Sat, 19 Mar 2011, Rainer Hurling wrote:


Today I installed the newest R develepment branch
R version 2.14.0 Under development (unstable) (2011-03-18 r54866)
on FreeBSD 9.0-CURRENT (amd64). All seems fine so far.


But that is very raw: testing on 2.13.0 alpha would be more useful at
this point.


Yes, it is raw. But I need it for some reason.

Testing of 2.13.0 alpha (r54865) on FreeBSD 9.0-CURRENT (amd64) shows no 
problems so far. For testing purposes, I customized the port math/R from 
b.f. and built from that port, so R installed correct on FreeBSD with 
gcc45 and gfortran45.


As to be expected, I had no problems with R packages using pythag on 
2.13.0 alpha. All needed packages could beinstalled. Also, some of my 
more complicated R scripts (with database access, spatial computings and 
pdf production) work fine.



After that I updated my R packages with option 'checkBuilt=TRUE'.
There are four packages (spatstat, pscl, adehabitatLT, adehabitatHR)
which gives an error like this:

Error in dyn.load(file, DLLpath = DLLpath, ...) :
kann shared object
'/usr/local/lib/R/library/spatstat/libs/spatstat.so' nicht laden:
/usr/local/lib/R/library/spatstat/libs/spatstat.so: Undefined symbol
Rf_pythag
Fehler: loading failed
Ausführung angehalten
Fehler: loading failed


Searching around I found a hint in
http://developer.r-project.org/R_svnlog_2011 about upcoming changes
with 'Rf_pythag':


r54767 | ripley | 2011-03-13 07:30:32 -0400 (Sun, 13 Mar 2011) | 1 line
Changed paths:
M /trunk/doc/NEWS.Rd
M /trunk/src/include/Rmath.h0.in
M /trunk/src/nmath/imax2.c

keep Rf_pythag for a little longer



R News of newest devel has three entries about the change:

CHANGES IN R VERSION 2.14.0:
DEPRECATED AND DEFUNCT:
o The entry point pythag formerly in Rmath.h is defunct: use
instead the C99 function hypot.
CHANGES IN R VERSION 2.13.0:
C-LEVEL FACILITIES:
o pythag duplicated the C99 function hypot. It is no longer
provided, but is used a substitute for hypot in the very unlikely
event that the latter is not available.
DEPRECATED  DEFUNCT:
o The entry point pythag in Rmath.h is deprecated in favour of the
C99 function hypot. A wrapper for hypot is provided for R 2.13.x
only.


Because of that informations I attempted to change 'pythag' against
'hypot' in spatstat/src/lookup.c and it works. Is this the only
required adaption which has to be done on the four named packages?


For adehabitatLT, adehabitatHR, simply update. For pscl, spatstat,
change pythag to hypot -- the maintainers have been asked for updates.


Ok, as I suspected. You had been aware of these packages before ;-)


You can see CRAN R-devel test results on the CRAN check page. There are
a number of other failures due to deprecated - defunct changes (we make
them very early in the development cycle).


I know of this page. It is very useful for identifying problems with 
packages, especially on Windows, Linux, OSX and Solaris. Understandably 
it does not support my 'rare' platform FreeBSD directly ;-)


Thanks for anwsering and clearing up my request,
Rainer Hurling

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

Re: [Rd] R-devel on FreeBSD: Support for C99 complex type is required

[Rainer Hurling]

On 07.02.2011 23:45 (UTC+1), Prof Brian Ripley wrote:

A follow-up on this.

Cygwin has recently[*] added support for C99 complex math, taken from
NetBSD with code that is very similar to that from Steven Moshier
available via http://www.moshier.net/c9x_readme.html.

That code isn't entirely right, especially not at the cuts on the
inverse functions where C99 mandates what cut is used (and neither glibc
nor Mac OS X have it correct).

I would expect that the current R-devel (I mean an SVN checkout now)
should build on your platform, substituting the missing functions by
ones based on earlier code. There may be a few more tweaks required, but
I have corrected several errors in the versions FreeBSD would have used
in R 2.12.1.


On FreeBSD 9.0-CURRENT (amd64) I have done a

  svn co https://svn.r-project.org/R/trunk r-devel/R

and after that

  configure --without-recommended-packages

The configure script does not complain any more about missing C99 
complex support. I was able to build and install R (without recommended 
packages).


Starting R and doing examples on ?complex seems to work correct.

sessionInfo()
R version 2.13.0 Under development (unstable) (2011-02-08 r54279)
Platform: x86_64-unknown-freebsd9.0 (64-bit)
locale:
[1] de_DE.ISO8859-15/de_DE.ISO8859-15/C/C/de_DE.ISO8859-15/de_DE.ISO8859-15
attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base
loaded via a namespace (and not attached):
[1] tools_2.13.0

Thank you very much for this work. Will it exist in some way in the next 
release?



[*] AFAICS not yet released in Cygwin, but in newlib 1.19.0.



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

Re: [Rd] R-devel on FreeBSD: Support for C99 complex type is required

[Rainer Hurling]

On 08.02.2011 22:10 (UTC+1), Prof Brian Ripley wrote:

On Tue, 8 Feb 2011, Rainer Hurling wrote:

On 07.02.2011 23:45 (UTC+1), Prof Brian Ripley wrote:

A follow-up on this.

Cygwin has recently[*] added support for C99 complex math, taken from
NetBSD with code that is very similar to that from Steven Moshier
available via http://www.moshier.net/c9x_readme.html.

That code isn't entirely right, especially not at the cuts on the
inverse functions where C99 mandates what cut is used (and neither glibc
nor Mac OS X have it correct).

I would expect that the current R-devel (I mean an SVN checkout now)
should build on your platform, substituting the missing functions by
ones based on earlier code. There may be a few more tweaks required, but
I have corrected several errors in the versions FreeBSD would have used
in R 2.12.1.


On FreeBSD 9.0-CURRENT (amd64) I have done a

svn co https://svn.r-project.org/R/trunk r-devel/R

and after that

configure --without-recommended-packages

The configure script does not complain any more about missing C99
complex support. I was able to build and install R (without
recommended packages).

Starting R and doing examples on ?complex seems to work correct.

sessionInfo()
R version 2.13.0 Under development (unstable) (2011-02-08 r54279)
Platform: x86_64-unknown-freebsd9.0 (64-bit)
locale:
[1]
de_DE.ISO8859-15/de_DE.ISO8859-15/C/C/de_DE.ISO8859-15/de_DE.ISO8859-15
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] tools_2.13.0

Thank you very much for this work. Will it exist in some way in the
next release?


Just to be clear, the next release will almost certainly be 2.12.2
(currently R-patched). That will use pre-C99 complex as 2.12.1 did, but
with several bugs fixed. Then we would expect a 2.13.0 in April, and
that will require C99 complex in the compiler plus some version of the
current substitutes for csin etc.


Sorry, my last question was imprecise. Of course I meant 2.13.x.


My sysadmins have updated a FreeBSD virtual machine for me (to 8.2-rc3):
hopefully I will be able to test R-devel on it in future.


Wow, that's interesting. Please let me know if I could test something on 
FreeBSD 9.0-CURRENT (the amd64 development version).


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

[Rd] R-devel on FreeBSD: Support for C99 complex type is required

[Rainer Hurling]

Today I tried two build R-devel_2011-02-06.tar.gz from sources on 
FreeBSD 9.0-CURRENT (amd64) with gcc-4.5.2 and I got the following 
messages when configuring:



./configure
[..SNIP..]
checking whether C99 double complex is supported...
checking complex.h usability... yes
checking complex.h presence... yes
checking for complex.h... yes
checking for double complex... yes
checking whether cexp exists and is declared... no
checking whether clog exists and is declared... no
checking whether csqrt exists and is declared... yes
checking whether cpow exists and is declared... no
checking whether ccos exists and is declared... no
checking whether csin exists and is declared... no
checking whether ctan exists and is declared... no
checking whether cacos exists and is declared... no
checking whether casin exists and is declared... no
checking whether catan exists and is declared... no
checking whether ccosh exists and is declared... no
checking whether csinh exists and is declared... no
checking whether ctanh exists and is declared... no
checking whether cacosh exists and is declared... no
checking whether casinh exists and is declared... no
checking whether catanh exists and is declared... no
configure: error: Support for C99 complex type is required.
[..script stops here..]

Until 2.12.1 this works for me. In the NEWS file of 2.13.0 I found in 
the INSTALLATION section:


'A C99 compiler is now required, and more C99 language features will be 
used in the R sources.'


What exactly characterizes a C99 compiler? Does gcc-4.5.2 belongs to 
this? Are the special arguments or knobs to consider? Any other ideas?


Please let me know if more infos are needed.

Thanks in advance for any help,
Rainer Hurling

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

Re: [Rd] R-devel on FreeBSD: Support for C99 complex type is required

[Rainer Hurling]

On 06.02.2011 16:22 (UTC+1), Prof Brian Ripley wrote:

On Sun, 6 Feb 2011, Rainer Hurling wrote:


Today I tried two build R-devel_2011-02-06.tar.gz from sources on
FreeBSD 9.0-CURRENT (amd64) with gcc-4.5.2 and I got the following
messages when configuring:


./configure
[..SNIP..]
checking whether C99 double complex is supported...
checking complex.h usability... yes
checking complex.h presence... yes
checking for complex.h... yes
checking for double complex... yes
checking whether cexp exists and is declared... no
checking whether clog exists and is declared... no
checking whether csqrt exists and is declared... yes
checking whether cpow exists and is declared... no
checking whether ccos exists and is declared... no
checking whether csin exists and is declared... no
checking whether ctan exists and is declared... no
checking whether cacos exists and is declared... no
checking whether casin exists and is declared... no
checking whether catan exists and is declared... no
checking whether ccosh exists and is declared... no
checking whether csinh exists and is declared... no
checking whether ctanh exists and is declared... no
checking whether cacosh exists and is declared... no
checking whether casinh exists and is declared... no
checking whether catanh exists and is declared... no
configure: error: Support for C99 complex type is required.
[..script stops here..]

Until 2.12.1 this works for me. In the NEWS file of 2.13.0 I found in
the INSTALLATION section:

'A C99 compiler is now required, and more C99 language features will
be used in the R sources.'


But that was against R 2.12.0!


Yes, but emulation code was not removed until R-2.13.0?


What exactly characterizes a C99 compiler? Does gcc-4.5.2 belongs to
this?


Yes with flag -std=c99, but it also needs a runtime complying with C99.
Those missing functions are part of C99.


Probably a stupid question because I am not a programmer: Is this 
'runtime complying with C99' a compilers binary or something else?



Are the special arguments or knobs to consider? Any other ideas?

Please let me know if more infos are needed.


I think this is really a FreeBSD support question. In 2011, an OS really
should have support for a 1999 standard. Darwin, a FreeBSD derivative,
does and its help page says


Hmm, on FreeBSD I really have no other piece of software which complains 
about lack of C99.



4th Berkeley Distribution December 11, 2006 4th Berkeley Distribution


In 2006 we had already Darwin 8.x in Mac OS X 10.4.


which suggests that is part of BSD.

We are not going to put back the emulation code used: we simply don't
have the resources to fix up its problems (nor do we have a platform
which needs it). The alternative I will look into is allowing R to be
compiled without support for complex arithmetic.


Ok, I understand. This seems consistent. I will try to contact FreeBSD 
support about it. Please do not change back the behaviour for FreeBSD 
(towards emulation code) until this is clarified.



Thanks in advance for any help,
Rainer Hurling


Thanks for answering and clearing this up,
Rainer Hurling

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

Re: [Rd] R-devel on FreeBSD: Support for C99 complex type is required

[Rainer Hurling]

On 06.02.2011 18:24 (UTC+1), Murray Stokely wrote:

On Sun, Feb 6, 2011 at 8:50 AM, Rainer Hurlingrhur...@gwdg.de  wrote:

I think this is really a FreeBSD support question. In 2011, an OS really
should have support for a 1999 standard. Darwin, a FreeBSD derivative,
does and its help page says


Hmm, on FreeBSD I really have no other piece of software which complains
about lack of C99.


FreeBSD is planning on switching to a different compiler, llvm/clang,
and so the version of gcc is stale, but still it should be more than
sufficient to support C99.  FreeBSD started a C99 effort a decade ago
and I haven't heard from this initiative in a long time as I thought
it was completed.

 http://www.freebsd.org/projects/c99/index.html


As far as I understand these initiative was/is for the built in gcc 
4.2.1. When building a port newer ones like 4.5.3 can be used. The newer 
gcc versions made a lot of progress, see


http://gcc.gnu.org/gcc-4.2/c99status.html

http://gcc.gnu.org/gcc-4.5/c99status.html

Especially the complex support in complex.h of version 4.2.1 is broken.


There is I believe experimental support for llvm/clang built into
FreeBSD 9, so you could try compiling with that instead of gcc.


This is not an option at the moment, because I have to work with my 
system (desktop).



Ok, I understand. This seems consistent. I will try to contact FreeBSD
support about it. Please do not change back the behaviour for FreeBSD
(towards emulation code) until this is clarified.


Yes, please mail freebsd-standa...@google.com


I will mail freebsd-standa...@freebsd.org as you suggested.


I haven't looked at what autoconf is testing exactly but I suspect
simply another argument must be provided in the autoconf script to get
it to pull up the C99 math functions its looking for.


Perhaps there is a way to use gcc's 4.5.3 C99 functionality instead of 
4.2.1 ones. The c99 wrapper at /usr/bin/c99 enforces the use of the 
built in compiler (hardcoded path).



   - Murray


Thanks for the answer,
Rainer

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

Re: [Rd] R-devel on FreeBSD: Support for C99 complex type is required

[Rainer Hurling]

On 06.02.2011 18:24 (UTC+1), Prof Brian Ripley wrote:

On Sun, 6 Feb 2011, Rainer Hurling wrote:


On 06.02.2011 16:22 (UTC+1), Prof Brian Ripley wrote:

On Sun, 6 Feb 2011, Rainer Hurling wrote:


Today I tried two build R-devel_2011-02-06.tar.gz from sources on
FreeBSD 9.0-CURRENT (amd64) with gcc-4.5.2 and I got the following
messages when configuring:


./configure
[..SNIP..]
checking whether C99 double complex is supported...
checking complex.h usability... yes
checking complex.h presence... yes
checking for complex.h... yes
checking for double complex... yes
checking whether cexp exists and is declared... no
checking whether clog exists and is declared... no
checking whether csqrt exists and is declared... yes
checking whether cpow exists and is declared... no
checking whether ccos exists and is declared... no
checking whether csin exists and is declared... no
checking whether ctan exists and is declared... no
checking whether cacos exists and is declared... no
checking whether casin exists and is declared... no
checking whether catan exists and is declared... no
checking whether ccosh exists and is declared... no
checking whether csinh exists and is declared... no
checking whether ctanh exists and is declared... no
checking whether cacosh exists and is declared... no
checking whether casinh exists and is declared... no
checking whether catanh exists and is declared... no
configure: error: Support for C99 complex type is required.
[..script stops here..]

Until 2.12.1 this works for me. In the NEWS file of 2.13.0 I found in
the INSTALLATION section:

'A C99 compiler is now required, and more C99 language features will
be used in the R sources.'


But that was against R 2.12.0!


Yes, but emulation code was not removed until R-2.13.0?


Not really: there was an alternative not using C99 double complex prior
to R-devel (there is no 'R-2.13.0').


Sorry for the naming, R-devel of course.


What exactly characterizes a C99 compiler? Does gcc-4.5.2 belongs to
this?


Yes with flag -std=c99, but it also needs a runtime complying with C99.
Those missing functions are part of C99.


Probably a stupid question because I am not a programmer: Is this
'runtime complying with C99' a compilers binary or something else?


The C99 standard requires more than a compiler. It is usual (but not
compulsory) to provide the runtime support in libraries such as libc and
libm: so on Linux these functions are in glibc, on Windows most are in
MSVCRT.dll and some in libmingwex.a 


Ok, so only changing the compiler might be not enough. We have to try out.


Are the special arguments or knobs to consider? Any other ideas?

Please let me know if more infos are needed.


I think this is really a FreeBSD support question. In 2011, an OS really
should have support for a 1999 standard. Darwin, a FreeBSD derivative,
does and its help page says


Hmm, on FreeBSD I really have no other piece of software which
complains about lack of C99.


Maybe you use no other piece of software relying on C99's complex
functions?


That is possible. But I have more than 1300 ports (FreeBSD packages) 
installed. And some of them are quite sophisticated.



4th Berkeley Distribution December 11, 2006 4th Berkeley Distribution


In 2006 we had already Darwin 8.x in Mac OS X 10.4.


which suggests that is part of BSD.

We are not going to put back the emulation code used: we simply don't
have the resources to fix up its problems (nor do we have a platform
which needs it). The alternative I will look into is allowing R to be
compiled without support for complex arithmetic.


Ok, I understand. This seems consistent. I will try to contact FreeBSD
support about it. Please do not change back the behaviour for FreeBSD
(towards emulation code) until this is clarified.


As I said, we are never going to do that. The usual Open Source way to
solve problems like this is for substitute functions to be provided on
the deficient platform. We do that for several functions that used not
to be common: see src/main/Makefile.


I had a look at src/main/complex.c. There is a comment which describes 
the failure for gcc 4.2.1 on some systems.


This gives me the idea that perhaps FreeBSD is using the wrong complex.h 
file. The old one is in /usr/include, the newer one (4.5.3) in 
/usr/local/lib/gcc45/include/c++. But obviously the older header is 
used. I have to clear up this.



Thanks in advance for any help,
Rainer Hurling


Thanks for answering and clearing this up,
Rainer Hurling


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

Re: [Rd] R-2.12.0 hangs while loading RGtk2 on FreeBSD

[Rainer Hurling]

On 28.10.2010 20:07 (UTC+1), Michael Lawrence wrote:

On Wed, Oct 27, 2010 at 12:09 PM, Rainer Hurling rhur...@gwdg.de
mailto:rhur...@gwdg.de wrote:

On 27.10.2010 15:07 (UTC+1), Michael Lawrence wrote:

On Sat, Oct 23, 2010 at 2:49 AM, Rainer Hurling rhur...@gwdg.de
mailto:rhur...@gwdg.de
mailto:rhur...@gwdg.de mailto:rhur...@gwdg.de wrote:
On 22.10.2010 22:10 (UTC+1), Rainer Hurling wrote:
On 22.10.2010 16:18 (UTC+2), Rainer Hurling wrote:
On 22.10.2010 14:57 (UTC+1), Michael Lawrence wrote:

On Thu, Oct 21, 2010 at 9:42 AM, Rainer Hurling
rhur...@gwdg.de mailto:rhur...@gwdg.de
mailto:rhur...@gwdg.de mailto:rhur...@gwdg.de
mailto:rhur...@gwdg.de mailto:rhur...@gwdg.de
mailto:rhur...@gwdg.de mailto:rhur...@gwdg.de wrote:

[moved from R-help]

On 21.10.2010 18:09 (UTC+1), Prof Brian Ripley
wrote:

If you do R CMD INSTALL --no-test-load this will
skip
the part
that is
hanging and you can try loading in stages (e.g.
dyn.load
on the
RGtk2.so).

With '--no-test-load' it installs and ends normal.
Loading per
dyn.load(RGtk2.so) works, just as
dyn.load(RGtk2.so,F) and
dyn.load(RGtk2.so,,F). Unloading works, too.

Normal loading over library(RGtk2) within R does not
work. R than is
hanging.

It seems the problem is not with the library itself?

It looks like something is happening when
initializing
GTK+ and the
event loop. This happens in the function
R_gtkInit in
Rgtk.c. If you
could run R -d gdb and break on that function,
perhaps
you could step
through until it hangs.

Michael, thank you for answering. As I wrote earlier (on
R-help@),
unfortunately I have no experience with debugging (I
am not a
programmer). So I would need some more assistence.

Is there a difference between 'library(RGtk2)' and
'dyn.load(RGtk2)' in
initializing GTK+? I am able to dyn.load, but
library does
not work.

After starting with 'R -d gdb' is the following right?

(gdb) break R_gtkInit
Function R_gtkInit not defined.
Make breakpoint pending on future shared library
load? (y or
[n]) y
Breakpoint 1 (R_gtkInit) pending.

When I try to proceed, it gives me the following message

(gdb) run
Starting program: /usr/local/lib/R/bin/exec/R
/libexec/ld-elf.so.1: Shared object libRblas.so
not found,
required by R
Program exited with code 01.

Ok, I am one step further now:

(gdb) run
Starting program: /usr/local/lib/R/bin/exec/R
[..SNIP..]
  library(RGtk2)
[New LWP 100174]
Breakpoint 2 at 0x318bd490: file Rgtk.c, line 104.
Pending breakpoint R_gtkInit resolved
[New Thread 2f408b00 (LWP 100174)]
[Switching to Thread 2f408b00 (LWP 100174)]

Breakpoint 2, R_gtkInit (rargc=0x30b11d10, rargv=0x30a98458,
success=0x30afbad0) at Rgtk.c:104
104 Rgtk.c: No such file or directory.
in Rgtk.c
(gdb)

What do you suggest I should do next?

Rgtk.c was not found from gdb because RGtk2 was not build with
DEBUG=T and R_KEEP_PKG_SOURCE=yes.

So this is the next try. I can trace the code until it hangs:

library(RGtk2)
[New LWP 100250]
Breakpoint 2 at 0x458bd490: file Rgtk.c, line 104.

Pending breakpoint R_gtkInit resolved
[New Thread 4322ef00 (LWP 100250)]
[Switching to Thread 4322ef00 (LWP 100250)]

Breakpoint 2, R_gtkInit (rargc=0x446d0980, rargv=0x44698618,
success=0x446d09e0) at Rgtk.c:104
104 {
(gdb) n
107   argc = (int) *rargc;
(gdb) n
104 {
(gdb) n
107   argc = (int) *rargc;
(gdb) n
109

Re: [Rd] R-2.12.0 hangs while loading RGtk2 on FreeBSD

[Rainer Hurling]

On 27.10.2010 15:07 (UTC+1), Michael Lawrence wrote:

On Sat, Oct 23, 2010 at 2:49 AM, Rainer Hurling rhur...@gwdg.de
mailto:rhur...@gwdg.de wrote:
On 22.10.2010 22:10 (UTC+1), Rainer Hurling wrote:
On 22.10.2010 16:18 (UTC+2), Rainer Hurling wrote:
On 22.10.2010 14:57 (UTC+1), Michael Lawrence wrote:

On Thu, Oct 21, 2010 at 9:42 AM, Rainer Hurling
rhur...@gwdg.de mailto:rhur...@gwdg.de
mailto:rhur...@gwdg.de mailto:rhur...@gwdg.de wrote:

[moved from R-help]

On 21.10.2010 18:09 (UTC+1), Prof Brian Ripley wrote:

If you do R CMD INSTALL --no-test-load this will skip
the part
that is
hanging and you can try loading in stages (e.g. dyn.load
on the
RGtk2.so).

With '--no-test-load' it installs and ends normal.
Loading per
dyn.load(RGtk2.so) works, just as
dyn.load(RGtk2.so,F) and
dyn.load(RGtk2.so,,F). Unloading works, too.

Normal loading over library(RGtk2) within R does not
work. R than is
hanging.

It seems the problem is not with the library itself?

It looks like something is happening when initializing
GTK+ and the
event loop. This happens in the function R_gtkInit in
Rgtk.c. If you
could run R -d gdb and break on that function, perhaps
you could step
through until it hangs.

Michael, thank you for answering. As I wrote earlier (on
R-help@),
unfortunately I have no experience with debugging (I am not a
programmer). So I would need some more assistence.

Is there a difference between 'library(RGtk2)' and
'dyn.load(RGtk2)' in
initializing GTK+? I am able to dyn.load, but library does
not work.

After starting with 'R -d gdb' is the following right?

(gdb) break R_gtkInit
Function R_gtkInit not defined.
Make breakpoint pending on future shared library load? (y or
[n]) y
Breakpoint 1 (R_gtkInit) pending.

When I try to proceed, it gives me the following message

(gdb) run
Starting program: /usr/local/lib/R/bin/exec/R
/libexec/ld-elf.so.1: Shared object libRblas.so not found,
required by R
Program exited with code 01.

Ok, I am one step further now:

(gdb) run
Starting program: /usr/local/lib/R/bin/exec/R
[..SNIP..]
  library(RGtk2)
[New LWP 100174]
Breakpoint 2 at 0x318bd490: file Rgtk.c, line 104.
Pending breakpoint R_gtkInit resolved
[New Thread 2f408b00 (LWP 100174)]
[Switching to Thread 2f408b00 (LWP 100174)]

Breakpoint 2, R_gtkInit (rargc=0x30b11d10, rargv=0x30a98458,
success=0x30afbad0) at Rgtk.c:104
104 Rgtk.c: No such file or directory.
in Rgtk.c
(gdb)

What do you suggest I should do next?

Rgtk.c was not found from gdb because RGtk2 was not build with
DEBUG=T and R_KEEP_PKG_SOURCE=yes.

So this is the next try. I can trace the code until it hangs:

library(RGtk2)
[New LWP 100250]
Breakpoint 2 at 0x458bd490: file Rgtk.c, line 104.

Pending breakpoint R_gtkInit resolved
[New Thread 4322ef00 (LWP 100250)]
[Switching to Thread 4322ef00 (LWP 100250)]

Breakpoint 2, R_gtkInit (rargc=0x446d0980, rargv=0x44698618,
success=0x446d09e0) at Rgtk.c:104
104 {
(gdb) n
107   argc = (int) *rargc;
(gdb) n
104 {
(gdb) n
107   argc = (int) *rargc;
(gdb) n
109   if (!gdk_display_get_default()) {
(gdb) n
110 gtk_disable_setlocale();
(gdb) n
111 if (!gtk_init_check(argc, rargv)) {
(gdb) n
121 if (!GDK_DISPLAY()) {
(gdb) n
127 addInputHandler(R_InputHandlers,
ConnectionNumber(GDK_DISPLAY()),
(gdb) n
132 if (!pipe(fds)) {
(gdb) n
133   ifd = fds[0];
(gdb) n
134   ofd = fds[1];
(gdb) n
135   addInputHandler(R_InputHandlers, ifd,
R_gtk_timerInputHandler, 32);
(gdb) n
133   ifd = fds[0];
(gdb) n
134   ofd = fds[1];
(gdb) n
135   addInputHandler(R_InputHandlers, ifd,
R_gtk_timerInputHandler, 32);
(gdb) n
136   if (!g_thread_supported ()) g_thread_init (NULL);
(gdb) n
137   g_thread_create(R_gtk_timerThreadFunc, NULL, FALSE, NULL);
(gdb) n

Line 138 (R_CStackLimit = -1;) is hanging. It seems there is
something wrong with piping the file descriptor?

Thanks for looking into this. It looks

Re: [Rd] R-2.12.0 hangs while loading RGtk2 on FreeBSD

[Rainer Hurling]

On 22.10.2010 22:10 (UTC+1), Rainer Hurling wrote:

On 22.10.2010 16:18 (UTC+2), Rainer Hurling wrote:

On 22.10.2010 14:57 (UTC+1), Michael Lawrence wrote:



On Thu, Oct 21, 2010 at 9:42 AM, Rainer Hurling rhur...@gwdg.de
mailto:rhur...@gwdg.de wrote:

[moved from R-help]

On 21.10.2010 18:09 (UTC+1), Prof Brian Ripley wrote:

If you do R CMD INSTALL --no-test-load this will skip the part
that is
hanging and you can try loading in stages (e.g. dyn.load on the
RGtk2.so).


With '--no-test-load' it installs and ends normal. Loading per
dyn.load(RGtk2.so) works, just as dyn.load(RGtk2.so,F) and
dyn.load(RGtk2.so,,F). Unloading works, too.

Normal loading over library(RGtk2) within R does not work. R than is
hanging.

It seems the problem is not with the library itself?


It looks like something is happening when initializing GTK+ and the
event loop. This happens in the function R_gtkInit in Rgtk.c. If you
could run R -d gdb and break on that function, perhaps you could step
through until it hangs.


Michael, thank you for answering. As I wrote earlier (on R-help@),
unfortunately I have no experience with debugging (I am not a
programmer). So I would need some more assistence.

Is there a difference between 'library(RGtk2)' and 'dyn.load(RGtk2)' in
initializing GTK+? I am able to dyn.load, but library does not work.

After starting with 'R -d gdb' is the following right?

(gdb) break R_gtkInit
Function R_gtkInit not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (R_gtkInit) pending.

When I try to proceed, it gives me the following message

(gdb) run
Starting program: /usr/local/lib/R/bin/exec/R
/libexec/ld-elf.so.1: Shared object libRblas.so not found,
required by R
Program exited with code 01.


Ok, I am one step further now:


(gdb) run
Starting program: /usr/local/lib/R/bin/exec/R
[..SNIP..]
  library(RGtk2)
[New LWP 100174]
Breakpoint 2 at 0x318bd490: file Rgtk.c, line 104.
Pending breakpoint R_gtkInit resolved
[New Thread 2f408b00 (LWP 100174)]
[Switching to Thread 2f408b00 (LWP 100174)]

Breakpoint 2, R_gtkInit (rargc=0x30b11d10, rargv=0x30a98458,
success=0x30afbad0) at Rgtk.c:104
104 Rgtk.c: No such file or directory.
in Rgtk.c
(gdb)


What do you suggest I should do next?


Rgtk.c was not found from gdb because RGtk2 was not build with DEBUG=T 
and R_KEEP_PKG_SOURCE=yes.


So this is the next try. I can trace the code until it hangs:


library(RGtk2)
[New LWP 100250]
Breakpoint 2 at 0x458bd490: file Rgtk.c, line 104.
Pending breakpoint R_gtkInit resolved
[New Thread 4322ef00 (LWP 100250)]
[Switching to Thread 4322ef00 (LWP 100250)]

Breakpoint 2, R_gtkInit (rargc=0x446d0980, rargv=0x44698618, 
success=0x446d09e0) at Rgtk.c:104

104 {
(gdb) n
107   argc = (int) *rargc;
(gdb) n
104 {
(gdb) n
107   argc = (int) *rargc;
(gdb) n
109   if (!gdk_display_get_default()) {
(gdb) n
110 gtk_disable_setlocale();
(gdb) n
111 if (!gtk_init_check(argc, rargv)) {
(gdb) n
121 if (!GDK_DISPLAY()) {
(gdb) n
127 addInputHandler(R_InputHandlers, 
ConnectionNumber(GDK_DISPLAY()),

(gdb) n
132 if (!pipe(fds)) {
(gdb) n
133   ifd = fds[0];
(gdb) n
134   ofd = fds[1];
(gdb) n
135   addInputHandler(R_InputHandlers, ifd, 
R_gtk_timerInputHandler, 32);

(gdb) n
133   ifd = fds[0];
(gdb) n
134   ofd = fds[1];
(gdb) n
135   addInputHandler(R_InputHandlers, ifd, 
R_gtk_timerInputHandler, 32);

(gdb) n
136   if (!g_thread_supported ()) g_thread_init (NULL);
(gdb) n
137   g_thread_create(R_gtk_timerThreadFunc, NULL, FALSE, NULL);
(gdb) n

Line 138 (R_CStackLimit = -1;) is hanging. It seems there is something 
wrong with piping the file descriptor?




Thanks again,
Rainer



Thanks,
Michael

I think this is rather technical for R-help, so maybe move to
R-devel?


I moved to R-devel.

And can you check the RGtk2 version? A recent but not current
version
(2.12.17?) did hang initializing Gtk+ on some platforms and Michael
Lawrence had to be involved.


I am using RGtk2_2.12.18.tar.gz for month now.


On Thu, 21 Oct 2010, Rainer Hurling wrote:

Am 21.10.2010 16:12 (UTC+1) schrieb Prof Brian Ripley:

On Thu, 21 Oct 2010, Rainer Hurling wrote:

I am working with R-2.12.0 on FreeBSD 9.0-CURRENT
for a while now. I
successfully installed more than 300 packages (most
as dependencies of
others).

There are two packages I am not able to install:
RGtk2 and rggobi.

For example rggobi builds fine and after that it
wants to load:

--
# R CMD INSTALL rggobi_2.1.16.tar.gz
[..SNIP..]
gcc -std=gnu99 -shared -L/usr/local/lib -o rggobi.so
RSEval.o brush.o
colorSchemes.o conversion.o data.o dataset.o
display.o displays.o
edges.o ggobi.o identify.o init.o io.o keyHandlers.o
longitudinal.o
modes.o plot.o plots.o plugins.o print.o session.o
smooth.o ui.o
utils.o -pthread -L/usr/local/lib -lggobi
-lgtk-x11-2.0 -lxml2
-lgdk-x11-2.0 -latk-1.0

Re: [Rd] [R] R-2.12.0 hangs while loading RGtk2 on FreeBSD

[Rainer Hurling]

On 22.10.2010 14:57 (UTC+1), Michael Lawrence wrote:



On Thu, Oct 21, 2010 at 9:42 AM, Rainer Hurling rhur...@gwdg.de
mailto:rhur...@gwdg.de wrote:

[moved from R-help]

On 21.10.2010 18:09 (UTC+1), Prof Brian Ripley wrote:

If you do R CMD INSTALL --no-test-load this will skip the part
that is
hanging and you can try loading in stages (e.g. dyn.load on the
RGtk2.so).


With '--no-test-load' it installs and ends normal. Loading per
dyn.load(RGtk2.so) works, just as dyn.load(RGtk2.so,F) and
dyn.load(RGtk2.so,,F). Unloading works, too.

Normal loading over library(RGtk2) within R does not work. R than is
hanging.

It seems the problem is not with the library itself?


It looks like something is happening when initializing GTK+ and the
event loop. This happens in the function R_gtkInit in Rgtk.c. If you
could run R -d gdb and break on that function, perhaps you could step
through until it hangs.


Michael, thank you for answering. As I wrote earlier (on R-help@), 
unfortunately I have no experience with debugging (I am not a 
programmer). So I would need some more assistence.


Is  there a difference between 'library(RGtk2)' and 'dyn.load(RGtk2)' in 
initializing GTK+? I am able to dyn.load, but library does not work.


After starting with 'R -d gdb' is the following right?

  (gdb) break R_gtkInit
  Function R_gtkInit not defined.
  Make breakpoint pending on future shared library load? (y or [n]) y
  Breakpoint 1 (R_gtkInit) pending.

When I try to proceed, it gives me the following message

  (gdb) run
  Starting program: /usr/local/lib/R/bin/exec/R
  /libexec/ld-elf.so.1: Shared object libRblas.so not found,
  required by R
  Program exited with code 01.

Obviously there is some wrong with my try?

Thanks again,
Rainer



Thanks,
Michael

I think this is rather technical for R-help, so maybe move to
R-devel?


I moved to R-devel.

And can you check the RGtk2 version? A recent but not current
version
(2.12.17?) did hang initializing Gtk+ on some platforms and Michael
Lawrence had to be involved.


I am using RGtk2_2.12.18.tar.gz for month now.


On Thu, 21 Oct 2010, Rainer Hurling wrote:

Am 21.10.2010 16:12 (UTC+1) schrieb Prof Brian Ripley:

On Thu, 21 Oct 2010, Rainer Hurling wrote:

I am working with R-2.12.0 on FreeBSD 9.0-CURRENT
for a while now. I
successfully installed more than 300 packages (most
as dependencies of
others).

There are two packages I am not able to install:
RGtk2 and rggobi.

For example rggobi builds fine and after that it
wants to load:

--
# R CMD INSTALL rggobi_2.1.16.tar.gz
[..SNIP..]
gcc -std=gnu99 -shared -L/usr/local/lib -o rggobi.so
RSEval.o brush.o
colorSchemes.o conversion.o data.o dataset.o
display.o displays.o
edges.o ggobi.o identify.o init.o io.o keyHandlers.o
longitudinal.o
modes.o plot.o plots.o plugins.o print.o session.o
smooth.o ui.o
utils.o -pthread -L/usr/local/lib -lggobi
-lgtk-x11-2.0 -lxml2
-lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0
-lpangocairo-1.0 -lXext
-lXrender -lXinerama -lXi -lXrandr -lXcursor
-lXcomposite -lXdamage
-lpangoft2-1.0 -lgio-2.0 -lXfixes -lcairo -lX11
-lpango-1.0 -lm
-lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0
-lgthread-2.0
-lglib-2.0
installiert nach /usr/local/lib/R/library/rggobi/libs
** R
** data
** moving datasets to lazyload DB
** demo
** preparing package for lazy loading
--

At this point the install process is hanging, R
utilises no more CPU
time. Same with package RGtk2.

Is this a known error? Please let me know if I can
give more
information or try something different.


Well, those are exactly the two packages using Gtk+.

There is no known general problem, and as you could have
checked from
the CRAN check pages, those packages install without
problems on several
platforms. (Not Solaris, where ggobi does

Re: [Rd] [R] R-2.12.0 hangs while loading RGtk2 on FreeBSD

[Rainer Hurling]

On 22.10.2010 16:18 (UTC+2), Rainer Hurling wrote:

On 22.10.2010 14:57 (UTC+1), Michael Lawrence wrote:



On Thu, Oct 21, 2010 at 9:42 AM, Rainer Hurling rhur...@gwdg.de
mailto:rhur...@gwdg.de wrote:

[moved from R-help]

On 21.10.2010 18:09 (UTC+1), Prof Brian Ripley wrote:

If you do R CMD INSTALL --no-test-load this will skip the part
that is
hanging and you can try loading in stages (e.g. dyn.load on the
RGtk2.so).


With '--no-test-load' it installs and ends normal. Loading per
dyn.load(RGtk2.so) works, just as dyn.load(RGtk2.so,F) and
dyn.load(RGtk2.so,,F). Unloading works, too.

Normal loading over library(RGtk2) within R does not work. R than is
hanging.

It seems the problem is not with the library itself?


It looks like something is happening when initializing GTK+ and the
event loop. This happens in the function R_gtkInit in Rgtk.c. If you
could run R -d gdb and break on that function, perhaps you could step
through until it hangs.


Michael, thank you for answering. As I wrote earlier (on R-help@),
unfortunately I have no experience with debugging (I am not a
programmer). So I would need some more assistence.

Is there a difference between 'library(RGtk2)' and 'dyn.load(RGtk2)' in
initializing GTK+? I am able to dyn.load, but library does not work.

After starting with 'R -d gdb' is the following right?

(gdb) break R_gtkInit
Function R_gtkInit not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (R_gtkInit) pending.

When I try to proceed, it gives me the following message

(gdb) run
Starting program: /usr/local/lib/R/bin/exec/R
/libexec/ld-elf.so.1: Shared object libRblas.so not found,
required by R
Program exited with code 01.


Ok, I am one step further now:


(gdb) run
Starting program: /usr/local/lib/R/bin/exec/R
[..SNIP..]
 library(RGtk2)
[New LWP 100174]
Breakpoint 2 at 0x318bd490: file Rgtk.c, line 104.
Pending breakpoint R_gtkInit resolved
[New Thread 2f408b00 (LWP 100174)]
[Switching to Thread 2f408b00 (LWP 100174)]

Breakpoint 2, R_gtkInit (rargc=0x30b11d10, rargv=0x30a98458, 
success=0x30afbad0) at Rgtk.c:104

104 Rgtk.c: No such file or directory.
in Rgtk.c
(gdb)


What do you suggest I should do next?



Thanks again,
Rainer



Thanks,
Michael

I think this is rather technical for R-help, so maybe move to
R-devel?


I moved to R-devel.

And can you check the RGtk2 version? A recent but not current
version
(2.12.17?) did hang initializing Gtk+ on some platforms and Michael
Lawrence had to be involved.


I am using RGtk2_2.12.18.tar.gz for month now.


On Thu, 21 Oct 2010, Rainer Hurling wrote:

Am 21.10.2010 16:12 (UTC+1) schrieb Prof Brian Ripley:

On Thu, 21 Oct 2010, Rainer Hurling wrote:

I am working with R-2.12.0 on FreeBSD 9.0-CURRENT
for a while now. I
successfully installed more than 300 packages (most
as dependencies of
others).

There are two packages I am not able to install:
RGtk2 and rggobi.

For example rggobi builds fine and after that it
wants to load:

--
# R CMD INSTALL rggobi_2.1.16.tar.gz
[..SNIP..]
gcc -std=gnu99 -shared -L/usr/local/lib -o rggobi.so
RSEval.o brush.o
colorSchemes.o conversion.o data.o dataset.o
display.o displays.o
edges.o ggobi.o identify.o init.o io.o keyHandlers.o
longitudinal.o
modes.o plot.o plots.o plugins.o print.o session.o
smooth.o ui.o
utils.o -pthread -L/usr/local/lib -lggobi
-lgtk-x11-2.0 -lxml2
-lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0
-lpangocairo-1.0 -lXext
-lXrender -lXinerama -lXi -lXrandr -lXcursor
-lXcomposite -lXdamage
-lpangoft2-1.0 -lgio-2.0 -lXfixes -lcairo -lX11
-lpango-1.0 -lm
-lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0
-lgthread-2.0
-lglib-2.0
installiert nach /usr/local/lib/R/library/rggobi/libs
** R
** data
** moving datasets to lazyload DB
** demo
** preparing package for lazy loading
--

At this point the install process is hanging, R
utilises no more CPU
time. Same with package RGtk2.

Is this a known error? Please let me know if I can
give more
information or try something different.


Well, those are exactly the two packages using Gtk+.

There is no known general problem, and as you could have
checked from
the CRAN check pages, those packages install without
problems on several
platforms. (Not Solaris, where ggobi does not install
and RGtk2 requires
gcc, and not x64 Windows where both need to be patched.)

So it does look very like there is a problem with
loading against the
Gtk+ system libraries on your system.


I think you are right. With previous versions of R (until
R-2.10.x) I
did not have this hanging when loading RGtk2 ... And I am
pretty sure
that I have no problems with gtk2 outside of R on my FreeBSD
system.

In the meantime I found out that the reported loading error
of rggobi
is a loading error of RGtk2, which fails (hangs). So there
remains
only a loading error with RGtk2. (Because of that I changed
the subject.)

After building

Re: [Rd] [R] R-2.12.0 hangs while loading RGtk2 on FreeBSD

[Rainer Hurling]

[moved from R-help]

On 21.10.2010 18:09 (UTC+1), Prof Brian Ripley wrote:

If you do R CMD INSTALL --no-test-load this will skip the part that is
hanging and you can try loading in stages (e.g. dyn.load on the RGtk2.so).


With '--no-test-load' it installs and ends normal. Loading per 
dyn.load(RGtk2.so) works, just as dyn.load(RGtk2.so,F) and 
dyn.load(RGtk2.so,,F). Unloading works, too.


Normal loading over library(RGtk2) within R does not work. R than is 
hanging.


It seems the problem is not with the library itself?


I think this is rather technical for R-help, so maybe move to R-devel?


I moved to R-devel.


And can you check the RGtk2 version? A recent but not current version
(2.12.17?) did hang initializing Gtk+ on some platforms and Michael
Lawrence had to be involved.


I am using RGtk2_2.12.18.tar.gz for month now.


On Thu, 21 Oct 2010, Rainer Hurling wrote:


Am 21.10.2010 16:12 (UTC+1) schrieb Prof Brian Ripley:

On Thu, 21 Oct 2010, Rainer Hurling wrote:


I am working with R-2.12.0 on FreeBSD 9.0-CURRENT for a while now. I
successfully installed more than 300 packages (most as dependencies of
others).

There are two packages I am not able to install: RGtk2 and rggobi.

For example rggobi builds fine and after that it wants to load:

--
# R CMD INSTALL rggobi_2.1.16.tar.gz
[..SNIP..]
gcc -std=gnu99 -shared -L/usr/local/lib -o rggobi.so RSEval.o brush.o
colorSchemes.o conversion.o data.o dataset.o display.o displays.o
edges.o ggobi.o identify.o init.o io.o keyHandlers.o longitudinal.o
modes.o plot.o plots.o plugins.o print.o session.o smooth.o ui.o
utils.o -pthread -L/usr/local/lib -lggobi -lgtk-x11-2.0 -lxml2
-lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lXext
-lXrender -lXinerama -lXi -lXrandr -lXcursor -lXcomposite -lXdamage
-lpangoft2-1.0 -lgio-2.0 -lXfixes -lcairo -lX11 -lpango-1.0 -lm
-lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0
-lglib-2.0
installiert nach /usr/local/lib/R/library/rggobi/libs
** R
** data
** moving datasets to lazyload DB
** demo
** preparing package for lazy loading
--

At this point the install process is hanging, R utilises no more CPU
time. Same with package RGtk2.

Is this a known error? Please let me know if I can give more
information or try something different.


Well, those are exactly the two packages using Gtk+.

There is no known general problem, and as you could have checked from
the CRAN check pages, those packages install without problems on several
platforms. (Not Solaris, where ggobi does not install and RGtk2 requires
gcc, and not x64 Windows where both need to be patched.)

So it does look very like there is a problem with loading against the
Gtk+ system libraries on your system.


I think you are right. With previous versions of R (until R-2.10.x) I
did not have this hanging when loading RGtk2 ... And I am pretty sure
that I have no problems with gtk2 outside of R on my FreeBSD system.

In the meantime I found out that the reported loading error of rggobi
is a loading error of RGtk2, which fails (hangs). So there remains
only a loading error with RGtk2. (Because of that I changed the subject.)

After building/installing RGtk2, there are the following messages:

--
[..SNIP..]
gcc -std=gnu99 -shared -L/usr/local/lib -o RGtk2.so RGtkDataFrame.o
Rgtk.o atkAccessors.o atkClasses.o atkConversion.o atkFuncs.o
atkManuals.o atkUserFuncs.o cairo-enums.o cairoAccessors.o
cairoConversion.o cairoFuncs.o cairoManuals.o cairoUserFuncs.o
classes.o conversion.o eventLoop.o gdkAccessors.o gdkClasses.o
gdkConversion.o gdkFuncs.o gdkManuals.o gdkUserFuncs.o glib.o
gobject.o gtkAccessors.o gtkClasses.o gtkConversion.o gtkFuncs.o
gtkManuals.o gtkUserFuncs.o libgladeAccessors.o libgladeFuncs.o
libgladeManuals.o libgladeUserFuncs.o pangoAccessors.o pangoClasses.o
pangoConversion.o pangoFuncs.o pangoManuals.o pangoUserFuncs.o utils.o
zcompat.o -pthread -L/usr/local/lib -lglade-2.0 -lgtk-x11-2.0 -lxml2
-lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lXext
-lXrender -lXinerama -lXi -lXrandr -lXcursor -lXcomposite -lXdamage
-lpangoft2-1.0 -lgio-2.0 -lXfixes -lcairo -lX11 -lpango-1.0 -lm
-lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0
-lglib-2.0 -pthread -L/usr/local/lib -lgthread-2.0 -lglib-2.0
installiert nach /usr/local/lib/R/library/RGtk2/libs
** R
** demo
** inst
** preparing package for lazy loading
** help
*** installing help indices
** building package indices ...
** testing if installed package can be loaded [..hanging from here..]
--

Is there a chance to find out what is wrong with loading RGtk2 on my
system? Unfortunately I have almost no experience with real debugging
methods on R. But of course I am willing to help and try out ...


__
R-devel@r

[Rd] R-beta_2010-10-02_r53128 fails to compile on FreeBSD

[Rainer Hurling]

I tried to compile R-beta_2010-10-02_r53128 on FreeBSD 9.0-CURRENT 
(amd64) with gcc-4.4.5 and it fails:


-
gcc -std=gnu99 -I../../src/extra/zlib -I../../src/extra/bzip2 
-I../../src/extra/pcre  -I../../src/extra   -I. -I../../src/include 
-I../../src/include -I/usr/local/include -DHAVE_CONFIG_H   -g -O2 -c 
sysutils.c -o sysutils.o

sysutils.c: In function 'R_system':
sysutils.c:289: warning: implicit declaration of function 'WIFEXITED'
sysutils.c:289: warning: implicit declaration of function 'WEXITSTATUS'
gcc -std=gnu99 -I../../src/extra/zlib -I../../src/extra/bzip2 
-I../../src/extra/pcre  -I../../src/extra   -I. -I../../src/include 
-I../../src/include -I/usr/local/include -DHAVE_CONFIG_H   -g -O2 -c 
unique.c -o unique.o
gcc -std=gnu99 -I../../src/extra/zlib -I../../src/extra/bzip2 
-I../../src/extra/pcre  -I../../src/extra   -I. -I../../src/include 
-I../../src/include -I/usr/local/include -DHAVE_CONFIG_H   -g -O2 -c 
util.c -o util.o
gcc -std=gnu99 -I../../src/extra/zlib -I../../src/extra/bzip2 
-I../../src/extra/pcre  -I../../src/extra   -I. -I../../src/include 
-I../../src/include -I/usr/local/include -DHAVE_CONFIG_H   -g -O2 -c 
version.c -o version.o
gcc -std=gnu99 -I../../src/extra/zlib -I../../src/extra/bzip2 
-I../../src/extra/pcre  -I../../src/extra   -I. -I../../src/include 
-I../../src/include -I/usr/local/include -DHAVE_CONFIG_H   -g -O2 -c 
vfonts.c -o vfonts.o

gfortran   -g -O2 -c xxxpr.f -o xxxpr.o
ar cr libR.a CConverters.o CommandLineArgs.o Rdynload.o Renviron.o RNG.o 
agrep.o apply.o arithmetic.o array.o attrib.o base.o bind.o builtin.o 
character.o coerce.o colors.o complex.o connections.o context.o cov.o 
cum.o dcf.o datetime.o debug.o deparse.o deriv.o devices.o dotcode.o 
dounzip.o dstruct.o duplicate.o engine.o envir.o errors.o eval.o 
format.o fourier.o gevents.o gram.o gram-ex.o gramLatex.o gramRd.o 
graphics.o grep.o identical.o inlined.o inspect.o internet.o iosupport.o 
lapack.o list.o localecharset.o logic.o main.o mapply.o match.o memory.o 
model.o names.o objects.o optim.o optimize.o options.o par.o paste.o 
platform.o plot.o plot3d.o plotmath.o print.o printarray.o printvector.o 
printutils.o qsort.o random.o raw.o registration.o relop.o rlocale.o 
saveload.o scan.o seq.o serialize.o size.o sort.o source.o split.o 
sprintf.o startup.o subassign.o subscript.o subset.o summary.o 
sysutils.o unique.o util.o version.o vfonts.o xxxpr.o libs/*o

ranlib libR.a
gcc -std=gnu99 -export-dynamic -L/usr/local/lib -o R.bin Rmain.o libR.a 
-L../../lib -lRblas 
-L/usr/local/lib/gcc44/gcc/x86_64-portbld-freebsd9.0/4.4.5 
-L/usr/local/x86_64-portbld-freebsd9.0/lib -L/usr/local/lib/gcc44 
-lgfortran -lm  /usr/local/lib/libintl.so /usr/local/lib/libiconv.so 
-Wl,-rpath -Wl,/usr/local/lib -lreadline -llzma -lm -liconv -licuuc 
-licui18n

libR.a(sysutils.o)(.text+0x1d5d): In function `R_system':
/usr/local/R-beta/src/main/sysutils.c:289: undefined reference to 
`WIFEXITED'
libR.a(sysutils.o)(.text+0x1d76):/usr/local/R-beta/src/main/sysutils.c:289: 
undefined reference to `WEXITSTATUS'

libR.a(sys-unix.o)(.text+0x475): In function `do_system':
/usr/local/R-beta/src/unix/sys-unix.c:290: undefined reference to 
`WIFEXITED'
libR.a(sys-unix.o)(.text+0x551):/usr/local/R-beta/src/unix/sys-unix.c:290: 
undefined reference to `WEXITSTATUS'

*** Error code 1
Stop in /usr/local/R-beta/src/main.
*** Error code 1
Stop in /usr/local/R-beta/src/main.
*** Error code 1
Stop in /usr/local/R-beta/src.
*** Error code 1
Stop in /usr/local/R-beta.
-

Is this a known error? I would really appreciate if someone could give 
me a hint.


Please let me know if more information is needed.

Thanks in advance,
Rainer Hurling

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

Re: [Rd] R-beta_2010-10-02_r53128 fails to compile on FreeBSD

[Rainer Hurling]

On 03.10.2010 17:10 (UTC+1), Prof Brian Ripley wrote:

On Sun, 3 Oct 2010, Rainer Hurling wrote:


I tried to compile R-beta_2010-10-02_r53128 on FreeBSD 9.0-CURRENT
(amd64) with gcc-4.4.5 and it fails:

-
gcc -std=gnu99 -I../../src/extra/zlib -I../../src/extra/bzip2
-I../../src/extra/pcre -I../../src/extra -I. -I../../src/include
-I../../src/include -I/usr/local/include -DHAVE_CONFIG_H -g -O2 -c
sysutils.c -o sysutils.o
sysutils.c: In function 'R_system':
sysutils.c:289: warning: implicit declaration of function 'WIFEXITED'
sysutils.c:289: warning: implicit declaration of function 'WEXITSTATUS'
gcc -std=gnu99 -I../../src/extra/zlib -I../../src/extra/bzip2
-I../../src/extra/pcre -I../../src/extra -I. -I../../src/include
-I../../src/include -I/usr/local/include -DHAVE_CONFIG_H -g -O2 -c
unique.c -o unique.o
gcc -std=gnu99 -I../../src/extra/zlib -I../../src/extra/bzip2
-I../../src/extra/pcre -I../../src/extra -I. -I../../src/include
-I../../src/include -I/usr/local/include -DHAVE_CONFIG_H -g -O2 -c
util.c -o util.o
gcc -std=gnu99 -I../../src/extra/zlib -I../../src/extra/bzip2
-I../../src/extra/pcre -I../../src/extra -I. -I../../src/include
-I../../src/include -I/usr/local/include -DHAVE_CONFIG_H -g -O2 -c
version.c -o version.o
gcc -std=gnu99 -I../../src/extra/zlib -I../../src/extra/bzip2
-I../../src/extra/pcre -I../../src/extra -I. -I../../src/include
-I../../src/include -I/usr/local/include -DHAVE_CONFIG_H -g -O2 -c
vfonts.c -o vfonts.o
gfortran -g -O2 -c xxxpr.f -o xxxpr.o
ar cr libR.a CConverters.o CommandLineArgs.o Rdynload.o Renviron.o
RNG.o agrep.o apply.o arithmetic.o array.o attrib.o base.o bind.o
builtin.o character.o coerce.o colors.o complex.o connections.o
context.o cov.o cum.o dcf.o datetime.o debug.o deparse.o deriv.o
devices.o dotcode.o dounzip.o dstruct.o duplicate.o engine.o envir.o
errors.o eval.o format.o fourier.o gevents.o gram.o gram-ex.o
gramLatex.o gramRd.o graphics.o grep.o identical.o inlined.o inspect.o
internet.o iosupport.o lapack.o list.o localecharset.o logic.o main.o
mapply.o match.o memory.o model.o names.o objects.o optim.o optimize.o
options.o par.o paste.o platform.o plot.o plot3d.o plotmath.o print.o
printarray.o printvector.o printutils.o qsort.o random.o raw.o
registration.o relop.o rlocale.o saveload.o scan.o seq.o serialize.o
size.o sort.o source.o split.o sprintf.o startup.o subassign.o
subscript.o subset.o summary.o sysutils.o unique.o util.o version.o
vfonts.o xxxpr.o libs/*o
ranlib libR.a
gcc -std=gnu99 -export-dynamic -L/usr/local/lib -o R.bin Rmain.o
libR.a -L../../lib -lRblas
-L/usr/local/lib/gcc44/gcc/x86_64-portbld-freebsd9.0/4.4.5
-L/usr/local/x86_64-portbld-freebsd9.0/lib -L/usr/local/lib/gcc44
-lgfortran -lm /usr/local/lib/libintl.so /usr/local/lib/libiconv.so
-Wl,-rpath -Wl,/usr/local/lib -lreadline -llzma -lm -liconv -licuuc
-licui18n
libR.a(sysutils.o)(.text+0x1d5d): In function `R_system':
/usr/local/R-beta/src/main/sysutils.c:289: undefined reference to
`WIFEXITED'
libR.a(sysutils.o)(.text+0x1d76):/usr/local/R-beta/src/main/sysutils.c:289:
undefined reference to `WEXITSTATUS'
libR.a(sys-unix.o)(.text+0x475): In function `do_system':
/usr/local/R-beta/src/unix/sys-unix.c:290: undefined reference to
`WIFEXITED'
libR.a(sys-unix.o)(.text+0x551):/usr/local/R-beta/src/unix/sys-unix.c:290:
undefined reference to `WEXITSTATUS'
*** Error code 1
Stop in /usr/local/R-beta/src/main.
*** Error code 1
Stop in /usr/local/R-beta/src/main.
*** Error code 1
Stop in /usr/local/R-beta/src.
*** Error code 1
Stop in /usr/local/R-beta.
-

Is this a known error? I would really appreciate if someone could give
me a hint.


Not known, and as it is a POSIX construction almost all OSes have it.


Hmmm. It seems its implementation in FreeBSD (CURRENT) is a little 
different from other OSes?



Can you try (in sysutils.c and sys-unix.c) replacing

#ifdef HAVE_SYS_WAIT_H

by

#if defined(HAVE_SYS_WAIT_H)  defined(WEXITSTATUS)

?


Yes, with this patch in both files all works again. I tried it with 
gcc-4.4.5 and gcc-4.5.2. Is there any chance to get it in the release 
(R-2.12.0)?


As always you hit the goal. Thank you very much for the quick help,
Rainer Hurling

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

Re: [Rd] R-beta_2010-10-02_r53128 fails to compile on FreeBSD

[Rainer Hurling]

On 03.10.2010 17:08 (UTC+1), Peter Dalgaard wrote:

On 10/03/2010 04:24 PM, Rainer Hurling wrote:

I tried to compile R-beta_2010-10-02_r53128 on FreeBSD 9.0-CURRENT
(amd64) with gcc-4.4.5 and it fails:


Thanks for the report. WIFEXITED/WEXITSTATUS are usually defined in
sys/wait.h  (usually /usr/include/sys/wait.h). Do you have any
indication that this might be skipped? (configure output, etc.)


I think you are right, see the posting of Brian Ripley. With his 
suggested patch it works again.



I'm not quite sure by which mechanism gcc is expected to include
sys/wait.h, but the offending code is inside

#ifdef HAVE_SYS_WAIT_H

which configure is supposed to set only if it is available and POSIX
compatible.

Any chance you switched platform features (e.g. upgraded gcc) without
reconfiguring?


No, nothing I am aware of. But 9.0-CURRENT is the development platform 
of FreeBSD and my system is very recent ;-)



-pd


Many thanks for your answer,
Rainer Hurling



-
gcc -std=gnu99 -I../../src/extra/zlib -I../../src/extra/bzip2
-I../../src/extra/pcre  -I../../src/extra   -I. -I../../src/include
-I../../src/include -I/usr/local/include -DHAVE_CONFIG_H   -g -O2 -c
sysutils.c -o sysutils.o
sysutils.c: In function 'R_system':
sysutils.c:289: warning: implicit declaration of function 'WIFEXITED'
sysutils.c:289: warning: implicit declaration of function 'WEXITSTATUS'
gcc -std=gnu99 -I../../src/extra/zlib -I../../src/extra/bzip2
-I../../src/extra/pcre  -I../../src/extra   -I. -I../../src/include
-I../../src/include -I/usr/local/include -DHAVE_CONFIG_H   -g -O2 -c
unique.c -o unique.o
gcc -std=gnu99 -I../../src/extra/zlib -I../../src/extra/bzip2
-I../../src/extra/pcre  -I../../src/extra   -I. -I../../src/include
-I../../src/include -I/usr/local/include -DHAVE_CONFIG_H   -g -O2 -c
util.c -o util.o
gcc -std=gnu99 -I../../src/extra/zlib -I../../src/extra/bzip2
-I../../src/extra/pcre  -I../../src/extra   -I. -I../../src/include
-I../../src/include -I/usr/local/include -DHAVE_CONFIG_H   -g -O2 -c
version.c -o version.o
gcc -std=gnu99 -I../../src/extra/zlib -I../../src/extra/bzip2
-I../../src/extra/pcre  -I../../src/extra   -I. -I../../src/include
-I../../src/include -I/usr/local/include -DHAVE_CONFIG_H   -g -O2 -c
vfonts.c -o vfonts.o
gfortran   -g -O2 -c xxxpr.f -o xxxpr.o
ar cr libR.a CConverters.o CommandLineArgs.o Rdynload.o Renviron.o RNG.o
agrep.o apply.o arithmetic.o array.o attrib.o base.o bind.o builtin.o
character.o coerce.o colors.o complex.o connections.o context.o cov.o
cum.o dcf.o datetime.o debug.o deparse.o deriv.o devices.o dotcode.o
dounzip.o dstruct.o duplicate.o engine.o envir.o errors.o eval.o
format.o fourier.o gevents.o gram.o gram-ex.o gramLatex.o gramRd.o
graphics.o grep.o identical.o inlined.o inspect.o internet.o iosupport.o
lapack.o list.o localecharset.o logic.o main.o mapply.o match.o memory.o
model.o names.o objects.o optim.o optimize.o options.o par.o paste.o
platform.o plot.o plot3d.o plotmath.o print.o printarray.o printvector.o
printutils.o qsort.o random.o raw.o registration.o relop.o rlocale.o
saveload.o scan.o seq.o serialize.o size.o sort.o source.o split.o
sprintf.o startup.o subassign.o subscript.o subset.o summary.o
sysutils.o unique.o util.o version.o vfonts.o xxxpr.o libs/*o
ranlib libR.a
gcc -std=gnu99 -export-dynamic -L/usr/local/lib -o R.bin Rmain.o libR.a
-L../../lib -lRblas
-L/usr/local/lib/gcc44/gcc/x86_64-portbld-freebsd9.0/4.4.5
-L/usr/local/x86_64-portbld-freebsd9.0/lib -L/usr/local/lib/gcc44
-lgfortran -lm  /usr/local/lib/libintl.so /usr/local/lib/libiconv.so
-Wl,-rpath -Wl,/usr/local/lib -lreadline -llzma -lm -liconv -licuuc
-licui18n
libR.a(sysutils.o)(.text+0x1d5d): In function `R_system':
/usr/local/R-beta/src/main/sysutils.c:289: undefined reference to
`WIFEXITED'
libR.a(sysutils.o)(.text+0x1d76):/usr/local/R-beta/src/main/sysutils.c:289:
undefined reference to `WEXITSTATUS'
libR.a(sys-unix.o)(.text+0x475): In function `do_system':
/usr/local/R-beta/src/unix/sys-unix.c:290: undefined reference to
`WIFEXITED'
libR.a(sys-unix.o)(.text+0x551):/usr/local/R-beta/src/unix/sys-unix.c:290:
undefined reference to `WEXITSTATUS'
*** Error code 1
Stop in /usr/local/R-beta/src/main.
*** Error code 1
Stop in /usr/local/R-beta/src/main.
*** Error code 1
Stop in /usr/local/R-beta/src.
*** Error code 1
Stop in /usr/local/R-beta.
-

Is this a known error? I would really appreciate if someone could give
me a hint.

Please let me know if more information is needed.

Thanks in advance,
Rainer Hurling


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

Re: [Rd] R-beta_2010-10-02_r53128 fails to compile on FreeBSD

[Rainer Hurling]

On 03.10.2010 18:38 (UTC+1), Peter Dalgaard wrote:

On 10/03/2010 05:58 PM, Prof Brian Ripley wrote:

On Sun, 3 Oct 2010, Rainer Hurling wrote:

...

Is this a known error? I would really appreciate if someone could give
me a hint.


Not known, and as it is a POSIX construction almost all OSes have it.


Hmmm. It seems its implementation in FreeBSD (CURRENT) is a little different
from other OSes?


Can you try (in sysutils.c and sys-unix.c) replacing

#ifdef HAVE_SYS_WAIT_H

by

#if defined(HAVE_SYS_WAIT_H)  defined(WEXITSTATUS)

?


Yes, with this patch in both files all works again. I tried it with gcc-4.4.5
and gcc-4.5.2. Is there any chance to get it in the release (R-2.12.0)?


Yes, of course.  (After a little more testing on other platforms.)



Only it strikes me that it might be plugging the wrong hole. I.e., that
the real issue is that somehow we're not including sys/wait.h in all
cases. Would it perchance also work to have

#ifdef HAVE_SYS_WAIT_H
#includesys/wait.h
#endif


Just as a note. This (#includesys/wait.h) also works on FreeBSD.

Rainer Hurling



somewhere at the top of the files that use the two macros (sysutils.c
and sys-unix.c AFAICS).

  defined(WEXITSTATUS) probably won't break anything that wasn't
already broken, but it does insert a default definition that could
conflict with the one intended for the OS (that's what include files and
macros are for, after all).


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

Re: [Rd] R does not compile any more on FreeBSD 8.0-CURRENT

[Rainer Hurling]

On 19.03.2009 10:37 (UTC+1), Hiroyuki Kawakatsu wrote:

Rainer Hurling wrote:

On a recent FreeBSD 8.0-CURRENT (i386) building R (any version)
breaks with the following messages:

[...]

I run 7.1-RELEASE (amd64) so I cannot comment on any potential issues
with 8.0-CURRENT. On my machine the r-devel tarball (r48148) builds
without any problems but I use

./configure MAKE=gmake

Have you tried gmake?

h.


Yes, I tried gmake with same result. This behaviour is only with CURRENT 
from ~ 5th march 2009 on. Before that I have been able to compile with 
standard (bsd) make.


Thank you for this question,
Rainer

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

[Rd] [SOLVED] Re: R does not compile any more on FreeBSD 8.0-CURRENT

[Rainer Hurling]

Todays (03/20/2009) update of FreeBSD 8.0-CURRENT solved the problem. 
The two pathes are resolving again. So building and installing R on 
CURRENT works again :-)


Thanks for your patience,
Rainer


On 17.03.2009 16:11 (UTC+1), Rainer Hurling wrote:
On a recent FreeBSD 8.0-CURRENT (i386) building R (any version) breaks 
with the following messages:


--
[...snip...]
gcc -std=gnu99 -I. -I../../src/include -I../../src/include 
-I/usr/local/include -DHAVE_CONFIG_H   -g -O2 -c wilcox.c -o wilcox.o
gcc -std=gnu99 -I. -I../../src/include -I../../src/include 
-I/usr/local/include -DHAVE_CONFIG_H   -g -O2 -c signrank.c -o signrank.o

rm -rf libnmath.a
ar cr libnmath.a mlutils.o d1mach.o i1mach.o fmax2.o fmin2.o fprec.o 
fround.o ftrunc.o sign.o fsign.o imax2.o imin2.o chebyshev.o log1p.o 
expm1.o lgammacor.o gammalims.o stirlerr.o bd0.o gamma.o lgamma.o 
gamma_cody.o beta.o lbeta.o polygamma.o bessel_i.o bessel_j.o bessel_k.o

bessel_y.o choose.o snorm.o sexp.o dgamma.o pgamma.o qgamma.o rgamma.o
dbeta.o pbeta.o qbeta.o rbeta.o dunif.o punif.o qunif.o runif.o dnorm.o 
pnorm.o qnorm.o rnorm.o dlnorm.o plnorm.o qlnorm.o rlnorm.o df.o pf.o

qf.o rf.o dnf.o dt.o pt.o qt.o rt.o dnt.o dchisq.o pchisq.o qchisq.o
rchisq.o rnchisq.o dbinom.o pbinom.o qbinom.o rbinom.o rmultinom.o
dcauchy.o pcauchy.o qcauchy.o rcauchy.o dexp.o pexp.o qexp.o rexp.o 
dgeom.o pgeom.o qgeom.o rgeom.o dhyper.o phyper.o qhyper.o rhyper.o
dnbinom.o pnbinom.o qnbinom.o rnbinom.o dpois.o ppois.o qpois.o rpois.o 
dweibull.o pweibull.o qweibull.o rweibull.o dlogis.o plogis.o qlogis.o 
rlogis.o dnchisq.o pnchisq.o qnchisq.o dnbeta.o pnbeta.o qnbeta.o pnf.o 
pnt.o qnf.o qnt.o ptukey.o qtukey.o toms708.o wilcox.o signrank.o

ranlib libnmath.a
config.status: creating src/unix/Makefile
make: /usr/local/R-devel/srcunix: No such file or directory
*** Error code 2

Stop in /usr/local/R-devel/src/unix.
*** Error code 1

Stop in /usr/local/R-devel/src.
*** Error code 1

Stop in /usr/local/R-devel.
--

The path /usr/local/R-devel/srcunix does not exist but .../src/unix/ 
does. As a workaround I am able to do


cd src/unix
make
cd ../..
make

A second break with the same error does occur at 
/usr/local/R-devel/srcmain. Again this workaround works


cd src/main
make
cd ../..
make

Now the compilation finished without another break. What could be the 
reason for this 'path break'?  So long it seems that this error on 
FreeBSD 8.0-CURRENT only appears with R and no other third party software.


Potentially this is an error within latest FreeBSD code (?) and I have 
to ask on the FreeBSD mailing list. But before I wanted to ask on 
r-de...@. Perhaps someone here has an idea? Any hints are very welcome.


Thanks in advance,
Rainer Hurling


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

[Rd] R does not compile any more on FreeBSD 8.0-CURRENT

[Rainer Hurling]

On a recent FreeBSD 8.0-CURRENT (i386) building R (any version) breaks 
with the following messages:


--
[...snip...]
gcc -std=gnu99 -I. -I../../src/include -I../../src/include 
-I/usr/local/include -DHAVE_CONFIG_H   -g -O2 -c wilcox.c -o wilcox.o
gcc -std=gnu99 -I. -I../../src/include -I../../src/include 
-I/usr/local/include -DHAVE_CONFIG_H   -g -O2 -c signrank.c -o signrank.o

rm -rf libnmath.a
ar cr libnmath.a mlutils.o d1mach.o i1mach.o fmax2.o fmin2.o fprec.o 
fround.o ftrunc.o sign.o fsign.o imax2.o imin2.o chebyshev.o log1p.o 
expm1.o lgammacor.o gammalims.o stirlerr.o bd0.o gamma.o lgamma.o 
gamma_cody.o beta.o lbeta.o polygamma.o bessel_i.o bessel_j.o bessel_k.o

bessel_y.o choose.o snorm.o sexp.o dgamma.o pgamma.o qgamma.o rgamma.o
dbeta.o pbeta.o qbeta.o rbeta.o dunif.o punif.o qunif.o runif.o dnorm.o 
pnorm.o qnorm.o rnorm.o dlnorm.o plnorm.o qlnorm.o rlnorm.o df.o pf.o

qf.o rf.o dnf.o dt.o pt.o qt.o rt.o dnt.o dchisq.o pchisq.o qchisq.o
rchisq.o rnchisq.o dbinom.o pbinom.o qbinom.o rbinom.o rmultinom.o
dcauchy.o pcauchy.o qcauchy.o rcauchy.o dexp.o pexp.o qexp.o rexp.o 
dgeom.o pgeom.o qgeom.o rgeom.o dhyper.o phyper.o qhyper.o rhyper.o
dnbinom.o pnbinom.o qnbinom.o rnbinom.o dpois.o ppois.o qpois.o rpois.o 
dweibull.o pweibull.o qweibull.o rweibull.o dlogis.o plogis.o qlogis.o 
rlogis.o dnchisq.o pnchisq.o qnchisq.o dnbeta.o pnbeta.o qnbeta.o pnf.o 
pnt.o qnf.o qnt.o ptukey.o qtukey.o toms708.o wilcox.o signrank.o

ranlib libnmath.a
config.status: creating src/unix/Makefile
make: /usr/local/R-devel/srcunix: No such file or directory
*** Error code 2

Stop in /usr/local/R-devel/src/unix.
*** Error code 1

Stop in /usr/local/R-devel/src.
*** Error code 1

Stop in /usr/local/R-devel.
--

The path /usr/local/R-devel/srcunix does not exist but .../src/unix/ 
does. As a workaround I am able to do


cd src/unix
make
cd ../..
make

A second break with the same error does occur at 
/usr/local/R-devel/srcmain. Again this workaround works


cd src/main
make
cd ../..
make

Now the compilation finished without another break. What could be the 
reason for this 'path break'?  So long it seems that this error on 
FreeBSD 8.0-CURRENT only appears with R and no other third party software.


Potentially this is an error within latest FreeBSD code (?) and I have 
to ask on the FreeBSD mailing list. But before I wanted to ask on 
r-de...@. Perhaps someone here has an idea? Any hints are very welcome.


Thanks in advance,
Rainer Hurling

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

[Rd] Small typo in error message of R-devel

[Rainer Hurling]

Trying out some encodings and locales I just found a small typo in an 
error message of R 2.9.0 (2009-02-06 r47865).


In 'po/de.po' at line 5100 it has to be spelled 'Lokalisierung' instead 
of 'Lokilisierung'.


Rainer

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

Re: [Rd] Package Matrix does not compile in R-devel_2009-01-10

[Rainer Hurling]

Just some feedback for the record.

Since version R-devel_2009-01-20.tar.gz with Matrix_0.999375-18.tar.gz 
included I am able again to compile and install R on FreeBSD 8.0-CURRENT 
out of the box.


Many thanks to Martin Maechler and Brian Ripley for the help and work,

Rainer Hurling


Am 11.01.2009 23:13 (UTC+1) schrieb Rainer Hurling:

Dear developers,

today I tried to build and install R-devel_2009-01-10 on FreeBSD 
8.0-CURRENT (i386) for testing purposes.


All went well until compiling the now recommended (integrated) Matrix 
package. At this point the following break occured:



begin installing recommended package Matrix
* Installing *source* package 'Matrix' ...
** libs
gcc -std=gnu99 -I/usr/local/R-devel/include -I./UFconfig 
-I/usr/local/include-fpic  -g -O2 -c CHMfactor.c -o CHMfactor.o

[..snip..]
gcc -std=gnu99 -I/usr/local/R-devel/include -I../Include 
-I../../UFconfig -I/usr/local/include-fpic  -g -O2 -c 
colamd_global.c -o colamd_global.o
gcc -std=gnu99 -I/usr/local/R-devel/include -I../Include 
-I../../UFconfig -I/usr/local/include-fpic  -g -O2 -I../Include 
-DDLONG -c colamd.c -o colamd_l.o

ar -rucs ../../COLAMD.a colamd_global.o colamd_l.o # colamd.o
( cd Source ; make lib )
gcc -std=gnu99 -I/usr/local/R-devel/include -I../Include 
-I../../UFconfig -I/usr/local/include-fpic  -g -O2 -c amd_global.c 
-o amd_global.o

make: don't know how to make amd_l_1.o. Stop
*** Error code 2
Stop in /tmp/Rtmpx5nUS8/R.INSTALL10d63af1/Matrix/src/AMD.
*** Error code 1
Stop in /tmp/Rtmpx5nUS8/R.INSTALL10d63af1/Matrix/src.
ERROR: compilation failed for package 'Matrix'
* Removing '/usr/local/R-devel/library/Matrix'
*** Error code 1
Stop in /usr/local/R-devel/src/library/Recommended.
*** Error code 1
Stop in /usr/local/R-devel/src/library/Recommended.
*** Error code 1
Stop in /usr/local/R-devel.



Please note, that on FreeBSD there is a BSD 'make' as default. If I want 
to use gmake instead, I explicitly have to set it. Unfortunately this 
does not work within building the whole R-devel system.


With R-2.8.1 I have no problems installing and using R. When I want to 
build the (external) Matrix package I have to set an environment 
variable to gmake, found at /usr/local/bin/gmake and all works well.



Now my question: Is it possible to change the configure/build of the 
integrated Matrix package on R-devel? For all other packages there is no 
need to do so (at least for FreeBSD ;-)


Please let me know if I can help.

Thanks in advance,
Rainer Hurling


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

Re: [Rd] Package Matrix does not compile in R-devel_2009-01-10

[Rainer Hurling]

Thank you Brian,

for this detailed answer. I think you are right with the new rules.

Before contacting the maintainers I will try to collect some more 
information about the observed failure. Without setting the environment 
variable MAKE to gmake, I get excatly the same break when installing 
Matrix under R-2.8.1. So I can test it under 2.8.1.


Rainer


On 11.01.2009 23:42 (UTC+1), Prof Brian Ripley wrote:
You need to take this up with the package maintainers: although 
recommended packages are distributed with R,  they are still contributed 
packages with separate maintainers.


At one point Matrix did work with a non-GNU make (the Solaris one) after 
suggestions from R-core members on how to remove the obvious GNUisms.  
It would cetainly be helpful to let the package maintainers know what 
changes do work.  (I presume the issue is


amd_i_%.o: amd_%.c $(INC)
$(CC) $(ALL_CPPFLAGS) $(ALL_CFLAGS) -I../Include -DDINT -c $ -o $@
amd_l_%.o: amd_%.c $(INC)
$(CC) $(ALL_CPPFLAGS) $(ALL_CFLAGS) -I../Include -DDLONG -c $ 
-o $@


which are new rules since I was able to test.)

Unfortunately I can no longer build Matrix (and hence R-devel) on 
Solaris, as the Sun Studio compilers say some of the C++ code is invalid 
(and it looks so to me, and I reported it a while back): the file is 
spqr_front.cpp, so it has not got as far as the point that is giving you 
trouble.



On Sun, 11 Jan 2009, Rainer Hurling wrote:


Dear developers,

today I tried to build and install R-devel_2009-01-10 on FreeBSD 
8.0-CURRENT (i386) for testing purposes.


All went well until compiling the now recommended (integrated) Matrix 
package. At this point the following break occured:



begin installing recommended package Matrix
* Installing *source* package 'Matrix' ...
** libs
gcc -std=gnu99 -I/usr/local/R-devel/include -I./UFconfig 
-I/usr/local/include -fpic  -g -O2 -c CHMfactor.c -o CHMfactor.o

[..snip..]
gcc -std=gnu99 -I/usr/local/R-devel/include -I../Include 
-I../../UFconfig -I/usr/local/include-fpic  -g -O2 -c 
colamd_global.c -o colamd_global.o
gcc -std=gnu99 -I/usr/local/R-devel/include -I../Include 
-I../../UFconfig -I/usr/local/include-fpic  -g -O2 -I../Include 
-DDLONG -c colamd.c -o colamd_l.o

ar -rucs ../../COLAMD.a colamd_global.o colamd_l.o # colamd.o
( cd Source ; make lib )
gcc -std=gnu99 -I/usr/local/R-devel/include -I../Include 
-I../../UFconfig -I/usr/local/include-fpic  -g -O2 -c amd_global.c 
-o amd_global.o

make: don't know how to make amd_l_1.o. Stop
*** Error code 2
Stop in /tmp/Rtmpx5nUS8/R.INSTALL10d63af1/Matrix/src/AMD.
*** Error code 1
Stop in /tmp/Rtmpx5nUS8/R.INSTALL10d63af1/Matrix/src.
ERROR: compilation failed for package 'Matrix'
* Removing '/usr/local/R-devel/library/Matrix'
*** Error code 1
Stop in /usr/local/R-devel/src/library/Recommended.
*** Error code 1
Stop in /usr/local/R-devel/src/library/Recommended.
*** Error code 1
Stop in /usr/local/R-devel.



Please note, that on FreeBSD there is a BSD 'make' as default. If I 
want to use gmake instead, I explicitly have to set it. Unfortunately 
this does not work within building the whole R-devel system.


It would be helpful to know why not.  AFAIK GNU make works on other 
platforms with their own make.


With R-2.8.1 I have no problems installing and using R. When I want to 
build the (external) Matrix package I have to set an environment 
variable to gmake, found at /usr/local/bin/gmake and all works well.



Now my question: Is it possible to change the configure/build of the 
integrated Matrix package on R-devel? For all other packages there is 
no need to do so (at least for FreeBSD ;-)


Please let me know if I can help.

Thanks in advance,
Rainer Hurling


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

[Rd] Package Matrix does not compile in R-devel_2009-01-10

[Rainer Hurling]

Dear developers,

today I tried to build and install R-devel_2009-01-10 on FreeBSD 
8.0-CURRENT (i386) for testing purposes.


All went well until compiling the now recommended (integrated) Matrix 
package. At this point the following break occured:



begin installing recommended package Matrix
* Installing *source* package 'Matrix' ...
** libs
gcc -std=gnu99 -I/usr/local/R-devel/include -I./UFconfig 
-I/usr/local/include-fpic  -g -O2 -c CHMfactor.c -o CHMfactor.o

[..snip..]
gcc -std=gnu99 -I/usr/local/R-devel/include -I../Include 
-I../../UFconfig -I/usr/local/include-fpic  -g -O2 -c 
colamd_global.c -o colamd_global.o
gcc -std=gnu99 -I/usr/local/R-devel/include -I../Include 
-I../../UFconfig -I/usr/local/include-fpic  -g -O2 -I../Include 
-DDLONG -c colamd.c -o colamd_l.o

ar -rucs ../../COLAMD.a colamd_global.o colamd_l.o # colamd.o
( cd Source ; make lib )
gcc -std=gnu99 -I/usr/local/R-devel/include -I../Include 
-I../../UFconfig -I/usr/local/include-fpic  -g -O2 -c amd_global.c 
-o amd_global.o

make: don't know how to make amd_l_1.o. Stop
*** Error code 2
Stop in /tmp/Rtmpx5nUS8/R.INSTALL10d63af1/Matrix/src/AMD.
*** Error code 1
Stop in /tmp/Rtmpx5nUS8/R.INSTALL10d63af1/Matrix/src.
ERROR: compilation failed for package 'Matrix'
* Removing '/usr/local/R-devel/library/Matrix'
*** Error code 1
Stop in /usr/local/R-devel/src/library/Recommended.
*** Error code 1
Stop in /usr/local/R-devel/src/library/Recommended.
*** Error code 1
Stop in /usr/local/R-devel.



Please note, that on FreeBSD there is a BSD 'make' as default. If I want 
to use gmake instead, I explicitly have to set it. Unfortunately this 
does not work within building the whole R-devel system.


With R-2.8.1 I have no problems installing and using R. When I want to 
build the (external) Matrix package I have to set an environment 
variable to gmake, found at /usr/local/bin/gmake and all works well.



Now my question: Is it possible to change the configure/build of the 
integrated Matrix package on R-devel? For all other packages there is no 
need to do so (at least for FreeBSD ;-)


Please let me know if I can help.

Thanks in advance,
Rainer Hurling

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

[Rd] R-beta does not install on FreeBSD

[Rainer Hurling]

I am trying to install R-beta_2008-08-16_r46368.tar.gz on FreeBSD 
8.0-CURRENT (i386). The code stops compiling with the following message:




[.. snip ..]
building package 'tcltk'
mkdir ../../../library/tcltk
mkdir ../../../library/tcltk/R
mkdir ../../../library/tcltk/demo
mkdir ../../../library/tcltk/exec
mkdir ../../../library/tcltk/po
mkdir ../../../library/tcltk/man
making init.d from init.c
making tcltk.d from tcltk.c
making tcltk_unix.d from tcltk_unix.c
`Makedeps' is up to date.
gcc -std=gnu99 -I../../../../include -I/usr/local/include/tcl8.4 
-I/usr/local/include/tk8.4 -I/usr/local/include -I/usr/local/include 
-fpic  -g -O2 -c init.c -o init.o
gcc -std=gnu99 -I../../../../include -I/usr/local/include/tcl8.4 
-I/usr/local/include/tk8.4 -I/usr/local/include -I/usr/local/include 
-fpic  -g -O2 -c tcltk.c -o tcltk.o
gcc -std=gnu99 -I../../../../include -I/usr/local/include/tcl8.4 
-I/usr/local/include/tk8.4 -I/usr/local/include -I/usr/local/include 
-fpic  -g -O2 -c tcltk_unix.c -o tcltk_unix.o
gcc -std=gnu99 -shared -L/usr/local/lib -o tcltk.so init.o tcltk.o 
tcltk_unix.o  -L/usr/local/lib -ltcl84 -L/usr/local/lib -ltk84 
-L/usr/local/lib -lX11 -lm

mkdir ../../../../library/tcltk/libs
installing parsed NAMESPACE files
Makefile, line 28: Need an operator
make: fatal errors encountered -- cannot continue
*** Error code 1

Stop in /usr/local/R-beta.



This happens with all recent beta versions. R version 2.7.1 Patched 
(2008-08-10 r46284) installed and worked fine.


Could this be a bug with R-beta or is there something wrong with my 
FreeBSD version?


Any help is appreciated.

Thanks in advance,
Rainer Hurling

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

Re: [Rd] R-beta does not install on FreeBSD

[Rainer Hurling]

Direct hit! Your guess was right.

After removing line 24 in po/Makefile.in.in all went fine. 
R-beta_2008-08-16_r46368.tar.gz now compiles and installs perfect on 
FreeBSD 8.0-CURRENT.


Thank you very much for your response.

Rainer



On 17.08.2008 14:02 (UTC+1), Prof Brian Ripley wrote:

Can you track down which Makefile this is and what line 28 is?

My guess is that your make does not like the comment character at line 
24 in po/Makefile.in.in, in which case please delete the line.


But the BSD-like makes on Solaris and MacOS have no problem with it.

On Sun, 17 Aug 2008, Rainer Hurling wrote:

I am trying to install R-beta_2008-08-16_r46368.tar.gz on FreeBSD 
8.0-CURRENT (i386). The code stops compiling with the following message:




[.. snip ..]
building package 'tcltk'
mkdir ../../../library/tcltk
mkdir ../../../library/tcltk/R
mkdir ../../../library/tcltk/demo
mkdir ../../../library/tcltk/exec
mkdir ../../../library/tcltk/po
mkdir ../../../library/tcltk/man
making init.d from init.c
making tcltk.d from tcltk.c
making tcltk_unix.d from tcltk_unix.c
`Makedeps' is up to date.
gcc -std=gnu99 -I../../../../include -I/usr/local/include/tcl8.4 
-I/usr/local/include/tk8.4 -I/usr/local/include -I/usr/local/include 
-fpic -g -O2 -c init.c -o init.o
gcc -std=gnu99 -I../../../../include -I/usr/local/include/tcl8.4 
-I/usr/local/include/tk8.4 -I/usr/local/include -I/usr/local/include 
-fpic -g -O2 -c tcltk.c -o tcltk.o
gcc -std=gnu99 -I../../../../include -I/usr/local/include/tcl8.4 
-I/usr/local/include/tk8.4 -I/usr/local/include -I/usr/local/include 
-fpic -g -O2 -c tcltk_unix.c -o tcltk_unix.o
gcc -std=gnu99 -shared -L/usr/local/lib -o tcltk.so init.o tcltk.o 
tcltk_unix.o  -L/usr/local/lib -ltcl84 -L/usr/local/lib -ltk84 
-L/usr/local/lib -lX11 -lm

mkdir ../../../../library/tcltk/libs
installing parsed NAMESPACE files
Makefile, line 28: Need an operator
make: fatal errors encountered -- cannot continue
*** Error code 1

Stop in /usr/local/R-beta.



This happens with all recent beta versions. R version 2.7.1 Patched 
(2008-08-10 r46284) installed and worked fine.


Could this be a bug with R-beta or is there something wrong with my 
FreeBSD version?


Any help is appreciated.

Thanks in advance,
Rainer Hurling

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





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

Re: [Rd] Matrix package: compilation error

[Rainer Hurling]

Thank you Hin-Tak Leung,

on Saturday, 31th, Brian Ripley and Martin Maechler showed me the use of 
gmake without linking make against gmake:

   setenv MAKE gmake
   R CMD INSTALL Matrix_0.9975-11.tar.gz
   unsetenv MAKE
   R CMD INSTALL spdep_0.4-2.tar.gz

Everything works fine now. However, on my wishlist is a general way to 
integrate the search for gmake on systems like FreeBSD in the 
configure script of packages like Matrix ... ;-)

Rainer Hurling


Hin-Tak Leung schrieb:
 Rainer Hurling wrote:
 Thanks, Brian and Martin,

 I think you are both right, Matrix tries to use BSD make 
 (/usr/bin/make) on FreeBSD instead of GNU make (/usr/local/bin/gmake).

 Sorry, but I don't know how to persuade the configure script to use 
 gmake :-(
 
 easy -
 
 mkdir ~/mynewbin
 ln -s /usr/local/bin/gmake ~/mynewbin/make
 export PATH=${HOME}/mynewbin:${PATH}
 
 Then run R CMD INSTALL ... as you did.
 
 and afterwards, rm -rf ~/mynewbin. (I hope I don't need to explain
 what the 3 lines above do...)
 
 HTL
 
 

 Rainer


 Prof Brian Ripley schrieb:
 This is because of the GNUism in Matrix/src/Makefile

 ## get rid of this, once we have 'Depends: R (= 2.5.0)':
 ifeq (, $(findstring -lRlapack, $(LAPACK_LIBS)))
 SOURCES_LAPACK =
 else
 SOURCES_LAPACK = zpotf2.f zpotrf.f zlacgv.f
 endif

 I guess you know what you need to do to fix it for BSD make?

 On Sat, 31 Mar 2007, Rainer Hurling wrote:

 Trying to compile the package Matrix_0.9975-11.tar.gz with newest
 R-2.5.0 alpha (2007-03-31 r40986) on FreeBSD 7.0-CURRENT (i386) I get
 the following error:

 -
 R CMD INSTALL Matrix_0.9975-11.tar.gz
 * Installing to library '/usr/local/lib/R/library'
 * Installing *source* package 'Matrix' ...
 ** libs
 ** arch -
 Makefile, line 10: Missing dependency operator
 Makefile, line 12: Need an operator
 Makefile, line 14: Need an operator
 make: fatal errors encountered -- cannot continue
 ERROR: compilation failed for package 'Matrix'
 ** Removing '/usr/local/lib/R/library/Matrix'
 -


 Under FreeBSD I have installed the LAPACK package (3.0.2) with library
 at location

 /usr/local/lib/liblapack.so.4

 Is it possible that the Makefile of package Matrix fails because of 
 that?
 Not used unless you asked for it during R's configure.


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


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

[Rd] Matrix package: compilation error

[Rainer Hurling]

Trying to compile the package Matrix_0.9975-11.tar.gz with newest 
R-2.5.0 alpha (2007-03-31 r40986) on FreeBSD 7.0-CURRENT (i386) I get 
the following error:

-
R CMD INSTALL Matrix_0.9975-11.tar.gz
* Installing to library '/usr/local/lib/R/library'
* Installing *source* package 'Matrix' ...
** libs
** arch -
Makefile, line 10: Missing dependency operator
Makefile, line 12: Need an operator
Makefile, line 14: Need an operator
make: fatal errors encountered -- cannot continue
ERROR: compilation failed for package 'Matrix'
** Removing '/usr/local/lib/R/library/Matrix'
-


Under FreeBSD I have installed the LAPACK package (3.0.2) with library 
at location

/usr/local/lib/liblapack.so.4

Is it possible that the Makefile of package Matrix fails because of that?

Any help is appreciated,
Rainer Hurling

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

Re: [Rd] Matrix package: compilation error

[Rainer Hurling]

Thanks, Brian and Martin,

I think you are both right, Matrix tries to use BSD make (/usr/bin/make) 
on FreeBSD instead of GNU make (/usr/local/bin/gmake).

Sorry, but I don't know how to persuade the configure script to use 
gmake :-(

Rainer


Prof Brian Ripley schrieb:
 This is because of the GNUism in Matrix/src/Makefile
 
 ## get rid of this, once we have 'Depends: R (= 2.5.0)':
 ifeq (, $(findstring -lRlapack, $(LAPACK_LIBS)))
 SOURCES_LAPACK =
 else
 SOURCES_LAPACK = zpotf2.f zpotrf.f zlacgv.f
 endif
 
 I guess you know what you need to do to fix it for BSD make?
 
 On Sat, 31 Mar 2007, Rainer Hurling wrote:
 
 Trying to compile the package Matrix_0.9975-11.tar.gz with newest
 R-2.5.0 alpha (2007-03-31 r40986) on FreeBSD 7.0-CURRENT (i386) I get
 the following error:

 -
 R CMD INSTALL Matrix_0.9975-11.tar.gz
 * Installing to library '/usr/local/lib/R/library'
 * Installing *source* package 'Matrix' ...
 ** libs
 ** arch -
 Makefile, line 10: Missing dependency operator
 Makefile, line 12: Need an operator
 Makefile, line 14: Need an operator
 make: fatal errors encountered -- cannot continue
 ERROR: compilation failed for package 'Matrix'
 ** Removing '/usr/local/lib/R/library/Matrix'
 -


 Under FreeBSD I have installed the LAPACK package (3.0.2) with library
 at location

 /usr/local/lib/liblapack.so.4

 Is it possible that the Makefile of package Matrix fails because of that?
 
 Not used unless you asked for it during R's configure.


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

Re: [Rd] Matrix package: compilation error

[Rainer Hurling]

Thank you Andrew,

'setenv MAKE gmake' did it.

Now I can use latest spdep package :-)

Rainer


Andrew Robinson schrieb:
 Hi Rainer,
 
 check the following post for an alternative solution:
 
 http://tolstoy.newcastle.edu.au/R/help/06/01/18908.html
 
 if you would like more detailed instructions, let me know.
 
 Andrew
 
 
 On Sat, Mar 31, 2007 at 10:10:45PM +0200, Rainer Hurling wrote:
 Thanks, Brian and Martin,

 I think you are both right, Matrix tries to use BSD make (/usr/bin/make) 
 on FreeBSD instead of GNU make (/usr/local/bin/gmake).

 Sorry, but I don't know how to persuade the configure script to use 
 gmake :-(

 Rainer


 Prof Brian Ripley schrieb:
 This is because of the GNUism in Matrix/src/Makefile

 ## get rid of this, once we have 'Depends: R (= 2.5.0)':
 ifeq (, $(findstring -lRlapack, $(LAPACK_LIBS)))
 SOURCES_LAPACK =
 else
 SOURCES_LAPACK = zpotf2.f zpotrf.f zlacgv.f
 endif

 I guess you know what you need to do to fix it for BSD make?

 On Sat, 31 Mar 2007, Rainer Hurling wrote:

 Trying to compile the package Matrix_0.9975-11.tar.gz with newest
 R-2.5.0 alpha (2007-03-31 r40986) on FreeBSD 7.0-CURRENT (i386) I get
 the following error:

 -
 R CMD INSTALL Matrix_0.9975-11.tar.gz
 * Installing to library '/usr/local/lib/R/library'
 * Installing *source* package 'Matrix' ...
 ** libs
 ** arch -
 Makefile, line 10: Missing dependency operator
 Makefile, line 12: Need an operator
 Makefile, line 14: Need an operator
 make: fatal errors encountered -- cannot continue
 ERROR: compilation failed for package 'Matrix'
 ** Removing '/usr/local/lib/R/library/Matrix'
 -


 Under FreeBSD I have installed the LAPACK package (3.0.2) with library
 at location

 /usr/local/lib/liblapack.so.4

 Is it possible that the Makefile of package Matrix fails because of that?
 Not used unless you asked for it during R's configure.

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


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

Re: [Rd] rgl update: please test!

[Rainer Hurling]

Hallo Duncan,

your newest version works fine under R-2.5.0 (devel) on FreeBSD 
7.0-CURRENT (i386). I made some tests with different types of diagrams 
and all seems to be ok for me.

Thank you very much. I am look forward to the release of this version.

Have a nice trip,
Rainer



Duncan Murdoch wrote:
 (This is bcc'd to a list of people who have had problems with rgl lately 
 or who are known to be big users; not cc'd, so you don't all get cc'd 
 all the responses on the R-devel list).
 
 I've just put together a test build of rgl, and put it on my web site as
 
 http://www.stats.uwo.ca/faculty/murdoch/software/rgl_0.70.564.tar.gz 
 (source)
 
 and
 
 http://www.stats.uwo.ca/faculty/murdoch/software/rgl_0.70.564.zip 
 (Windows binary).
 
 This includes a number of changes:
 
- changes to configure script from Laszlo Kajan and Brian Ripley: 
 should now be much more portable
- removed deprecated OSX font setting calls
- texture properties are now returned by material3d()
- allowed normals and texture coordinates to be specified in 
 triangles and quads
- normals may be specified in qmesh objects, but (at present) 
 subdivide removes them
- material3d() now preserves the values of unspecified parameters (as 
 documented, but not previously functioning)
- open3d() now resets all material properties to the defaults.
 
 Could people who have been having problems with rgl (or just making use 
 of it) please test this update?  Some of the changes are very recent, 
 and may still be buggy:  but I'm going offline from late tomorrow until 
 March 4, so I'm not going to have an opportunity to test them myself 
 well enough to want to send this to CRAN.
 
 I'm hoping to send this to CRAN soon after I return.
 
 Duncan Murdoch

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

Re: [Rd] R-devel does not compile under FreeBSD-7.0 CURRENT [SOLVED]

[Rainer Hurling]

I tried todays R-devel (2006-11-30) with FreeBSD-7.0 CURRENT and it 
seems, that compiling with 'make  make install' is ok again.

Thank you very much,
Rainer Hurling


Prof Brian Ripley wrote:
 As I said to you privately, I believe this to be a make issue: does GNU 
 make work?  We don't guarantee R to work with other makes (although it 
 usually does).
 
 My guess is that the problem is the missing .m in the .SUFFIXES list
 in Makeconf.in, but Solaris make and GNU make see no problem and it 
 looks like a make bug to me.  I've added the suffix, so please try the 
 current version.
 
 (This seems to be related to adding ObjC support which is apparently 
 currently incomplete.)
 
 On Wed, 29 Nov 2006, Rainer Hurling wrote:
 
 I am not able to compile R-devel 2006-11-28 under FreeBSD-7.0 CURRENT. 
 After running ./configure script 'make' stops with the following error 
 message:

 --
 #make
 gcc -I. -I./src/include -I./src/include -I/usr/local/include
 -DHAVE_CONFIG_H -g -O2 -c  -o .m.o
 gcc: No input files specified
 *** Error code 1

 Stop in /usr/local/R-devel.
 #
 --

 I attached configure messages. If wanted I can send complete 
 config.log (460 kByte).

 Are their any ideas about what is going wrong? If I could help with 
 more information or with testing, please let me know.

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

Re: [Rd] FreeBSD 7.0-CURRENT and R-2.2.0 alpha

[Rainer Hurling]

Sorry for my very late answer. On Sept. 12th I got an unexpected 
business trip until yesterday evening, so I had no chance to try out.


Thank you for the hints. But I am afraid I have no idea how to extract 
the needed information.

With R-2.2.0 (R-beta_2005-09-22_r35658.tar.gz) I tried the following:

nm /usr/lib/libc.a | grep cpow
nm /usr/lib/libm.a | grep cpow

In both cases without any result.

Where I have to look? Or what else can I do to find out where the libs 
with these procedures are?

Rainer Hurling


Prof Brian Ripley wrote:
 These were found by AC_CHECK_FUNCS (please confirm what configure said) 
 so most likely some macro needs to be set or header included.
 
 Could you please find out how configure managed to find cpow etc when 
 they appear not to be in libc/libm?
 
 On Sat, 10 Sep 2005, Rainer Hurling wrote:
 
 The configure script runs fine, but when I compile todays alpha version
 of R-2.2.0 (R-alpha_2005-09-10_r35546.tar.gz) under FreeBSD 7.0-CURRENT
 from Sept. 4th I get the following output:


 
 [...]
 gcc -I../../src/extra/zlib -I../../src/extra/bzip2
 -I../../src/extra/pcre   -I. -I../../src/include -I../../src/include
 -I/usr/local/include -DHAVE_CONFIG_H -D__NO_MATH_INLINES  -g -O2 -c
 version.c -o version.o
 gcc -I../../src/extra/zlib -I../../src/extra/bzip2
 -I../../src/extra/pcre   -I. -I../../src/include -I../../src/include
 -I/usr/local/include -DHAVE_CONFIG_H -D__NO_MATH_INLINES  -g -O2 -c
 vfonts.c -o vfonts.o
 f77   -g -O2 -c xxxpr.f -o xxxpr.o
 gcc -export-dynamic -L/usr/local/lib -o R.bin  Rmain.o  CConverters.o
 CommandLineArgs.o Rdynload.o Renviron.o RNG.o apply.o arithmetic.o
 apse.o array.o attrib.o base.o bind.o builtin.o character.o coerce.o
 colors.o complex.o connections.o context.o cov.o cum.o dcf.o datetime.o
 debug.o deparse.o deriv.o dotcode.o dounzip.o dstruct.o duplicate.o
 engine.o envir.o errors.o eval.o format.o fourier.o gevents.o gram.o
 gram-ex.o graphics.o identical.o internet.o iosupport.o lapack.o list.o
 logic.o main.o mapply.o match.o memory.o model.o names.o objects.o
 optim.o optimize.o options.o par.o paste.o pcre.o platform.o plot.o
 plot3d.o plotmath.o print.o printarray.o printvector.o printutils.o
 qsort.o random.o regex.o registration.o relop.o saveload.o scan.o seq.o
 serialize.o size.o sort.o source.o split.o sprintf.o startup.o
 subassign.o subscript.o subset.o summary.o sysutils.o unique.o util.o
 version.o vfonts.o xxxpr.o ../unix/libunix.a ../appl/libappl.a
 ../nmath/libnmath.a  -lf77blas -latlas -lg2c -lm  ../extra/zlib/libz.a
 ../extra/bzip2/libbz2.a ../extra/pcre/libpcre.a
 /usr/local/lib/libintl.so -Wl,-rpath -Wl,/usr/local/lib -lreadline -lm
 -liconv
 complex.o(.text+0x106): In function `mycpow':
 /usr/local/R-alpha/src/main/complex.c:170: undefined reference to `cpow'
 complex.o(.text+0x6f9): In function `do_cmathfuns':
 /usr/local/R-alpha/src/main/complex.c:323: undefined reference to `carg'
 complex.o(.text+0xb4b): In function `z_log':
 /usr/local/R-alpha/src/main/complex.c:423: undefined reference to `clog'
 complex.o(.text+0xb86): In function `z_logbase':
 /usr/local/R-alpha/src/main/complex.c:429: undefined reference to `clog'
 complex.o(.text+0xb98):/usr/local/R-alpha/src/main/complex.c:429:
 undefined reference to `clog'
 complex.o(.text+0xbd8): In function `z_exp':
 /usr/local/R-alpha/src/main/complex.c:434: undefined reference to `cexp'
 complex.o(.text+0xbf8): In function `z_sqrt':
 /usr/local/R-alpha/src/main/complex.c:439: undefined reference to `csqrt'
 complex.o(.text+0xc18): In function `z_cos':
 /usr/local/R-alpha/src/main/complex.c:486: undefined reference to `ccos'
 complex.o(.text+0xc38): In function `z_sin':
 /usr/local/R-alpha/src/main/complex.c:491: undefined reference to `csin'
 complex.o(.text+0xc5e): In function `z_tan':
 /usr/local/R-alpha/src/main/complex.c:497: undefined reference to `ctan'
 complex.o(.text+0xd26): In function `z_atan2':
 /usr/local/R-alpha/src/main/complex.c:523: undefined reference to `catan'
 complex.o(.text+0xe18): In function `z_asin':
 /usr/local/R-alpha/src/main/complex.c:541: undefined reference to `casin'
 complex.o(.text+0xe38): In function `z_acos':
 /usr/local/R-alpha/src/main/complex.c:553: undefined reference to `cacos'
 complex.o(.text+0xe58): In function `z_atan':
 /usr/local/R-alpha/src/main/complex.c:559: undefined reference to `catan'
 complex.o(.text+0xe78): In function `z_acosh':
 /usr/local/R-alpha/src/main/complex.c:564: undefined reference to 
 `cacosh'
 complex.o(.text+0xe98): In function `z_asinh':
 /usr/local/R-alpha/src/main/complex.c:569: undefined reference to 
 `casinh'
 complex.o(.text+0xeb8): In function `z_atanh':
 /usr/local/R-alpha/src/main/complex.c:574: undefined reference to 
 `catanh'
 complex.o(.text+0xed8): In function `z_cosh':
 /usr/local/R-alpha/src/main/complex.c:579: undefined reference to `ccosh'
 complex.o(.text+0xef8): In function `z_sinh':
 /usr/local/R-alpha/src/main

[Rd] FreeBSD 7.0-CURRENT and R-2.2.0 alpha

[Rainer Hurling]

The configure script runs fine, but when I compile todays alpha version
of R-2.2.0 (R-alpha_2005-09-10_r35546.tar.gz) under FreeBSD 7.0-CURRENT
from Sept. 4th I get the following output:



[...]
gcc -I../../src/extra/zlib -I../../src/extra/bzip2
-I../../src/extra/pcre   -I. -I../../src/include -I../../src/include
-I/usr/local/include -DHAVE_CONFIG_H -D__NO_MATH_INLINES  -g -O2 -c
version.c -o version.o
gcc -I../../src/extra/zlib -I../../src/extra/bzip2
-I../../src/extra/pcre   -I. -I../../src/include -I../../src/include
-I/usr/local/include -DHAVE_CONFIG_H -D__NO_MATH_INLINES  -g -O2 -c
vfonts.c -o vfonts.o
f77   -g -O2 -c xxxpr.f -o xxxpr.o
gcc -export-dynamic -L/usr/local/lib -o R.bin  Rmain.o  CConverters.o
CommandLineArgs.o Rdynload.o Renviron.o RNG.o apply.o arithmetic.o
apse.o array.o attrib.o base.o bind.o builtin.o character.o coerce.o
colors.o complex.o connections.o context.o cov.o cum.o dcf.o datetime.o
debug.o deparse.o deriv.o dotcode.o dounzip.o dstruct.o duplicate.o
engine.o envir.o errors.o eval.o format.o fourier.o gevents.o gram.o
gram-ex.o graphics.o identical.o internet.o iosupport.o lapack.o list.o
logic.o main.o mapply.o match.o memory.o model.o names.o objects.o
optim.o optimize.o options.o par.o paste.o pcre.o platform.o plot.o
plot3d.o plotmath.o print.o printarray.o printvector.o printutils.o
qsort.o random.o regex.o registration.o relop.o saveload.o scan.o seq.o
serialize.o size.o sort.o source.o split.o sprintf.o startup.o
subassign.o subscript.o subset.o summary.o sysutils.o unique.o util.o
version.o vfonts.o xxxpr.o ../unix/libunix.a ../appl/libappl.a
../nmath/libnmath.a  -lf77blas -latlas -lg2c -lm  ../extra/zlib/libz.a
../extra/bzip2/libbz2.a ../extra/pcre/libpcre.a
/usr/local/lib/libintl.so -Wl,-rpath -Wl,/usr/local/lib -lreadline -lm
-liconv
complex.o(.text+0x106): In function `mycpow':
/usr/local/R-alpha/src/main/complex.c:170: undefined reference to `cpow'
complex.o(.text+0x6f9): In function `do_cmathfuns':
/usr/local/R-alpha/src/main/complex.c:323: undefined reference to `carg'
complex.o(.text+0xb4b): In function `z_log':
/usr/local/R-alpha/src/main/complex.c:423: undefined reference to `clog'
complex.o(.text+0xb86): In function `z_logbase':
/usr/local/R-alpha/src/main/complex.c:429: undefined reference to `clog'
complex.o(.text+0xb98):/usr/local/R-alpha/src/main/complex.c:429:
undefined reference to `clog'
complex.o(.text+0xbd8): In function `z_exp':
/usr/local/R-alpha/src/main/complex.c:434: undefined reference to `cexp'
complex.o(.text+0xbf8): In function `z_sqrt':
/usr/local/R-alpha/src/main/complex.c:439: undefined reference to `csqrt'
complex.o(.text+0xc18): In function `z_cos':
/usr/local/R-alpha/src/main/complex.c:486: undefined reference to `ccos'
complex.o(.text+0xc38): In function `z_sin':
/usr/local/R-alpha/src/main/complex.c:491: undefined reference to `csin'
complex.o(.text+0xc5e): In function `z_tan':
/usr/local/R-alpha/src/main/complex.c:497: undefined reference to `ctan'
complex.o(.text+0xd26): In function `z_atan2':
/usr/local/R-alpha/src/main/complex.c:523: undefined reference to `catan'
complex.o(.text+0xe18): In function `z_asin':
/usr/local/R-alpha/src/main/complex.c:541: undefined reference to `casin'
complex.o(.text+0xe38): In function `z_acos':
/usr/local/R-alpha/src/main/complex.c:553: undefined reference to `cacos'
complex.o(.text+0xe58): In function `z_atan':
/usr/local/R-alpha/src/main/complex.c:559: undefined reference to `catan'
complex.o(.text+0xe78): In function `z_acosh':
/usr/local/R-alpha/src/main/complex.c:564: undefined reference to `cacosh'
complex.o(.text+0xe98): In function `z_asinh':
/usr/local/R-alpha/src/main/complex.c:569: undefined reference to `casinh'
complex.o(.text+0xeb8): In function `z_atanh':
/usr/local/R-alpha/src/main/complex.c:574: undefined reference to `catanh'
complex.o(.text+0xed8): In function `z_cosh':
/usr/local/R-alpha/src/main/complex.c:579: undefined reference to `ccosh'
complex.o(.text+0xef8): In function `z_sinh':
/usr/local/R-alpha/src/main/complex.c:584: undefined reference to `csinh'
complex.o(.text+0xf18): In function `z_tanh':
/usr/local/R-alpha/src/main/complex.c:589: undefined reference to `ctanh'
*** Error code 1
Stop in /usr/local/R-alpha/src/main.
*** Error code 1
Stop in /usr/local/R-alpha/src/main.
*** Error code 1
Stop in /usr/local/R-alpha/src.
*** Error code 1
Stop in /usr/local/R-alpha.


Am I missing something?

Thank you,
Rainer Hurling

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