search for: rdynload

...------------------------------------ ------------------------------------------------------------------------------------------------------------------------------------------- ==20262== Conditional jump or move depends on uninitialised value(s) ==20262== at 0x1B92D888: R_getDLLRegisteredSymbol (Rdynload.c:665) ==20262== by 0x1B92D9C5: R_dlsym (Rdynload.c:735) ==20262== by 0x1B92D0BD: R_callDLLUnload (Rdynload.c:412) ==20262== by 0x1B92D15B: DeleteDLL (Rdynload.c:439) ==20262== ==20262== Conditional jump or move depends on uninitialised value(s) ==20262== at 0x1B92D8D2: R_getDLLRegister...

...cc -I. -I../../src/include -I../../src/include -I/usr/local/include -DHAVE_CONFIG_H -I/usr/include/Motif1.1 -I/usr/include/X11R4 -c CConverters.c -o CConverters.o gcc -I. -I../../src/include -I../../src/include -I/usr/local/include -DHAVE_CONFIG_H -I/usr/include/Motif1.1 -I/usr/include/X11R4 -c Rdynload.c -o Rdynload.o Rdynload.c: In function `R_FindSymbol': Rdynload.c:781: `CFunTab' undeclared (first use in this function) Rdynload.c:781: (Each undeclared identifier is reported only once Rdynload.c:781: for each function it appears in.) make[3]: *** [Rdynload.o] Error 1 make[3]: Leaving di...

...ng to make R-1.5.0 from source on a new G4 system with the apple developer tools and X11 installed and with ATLAS. Running ./configure appears to end normally, but running make yields: gcc -no-cpp-precomp -I. -I../../src/include -I../../src/include -I/usr/local/include -DHAVE_CONFIG_H -g -O2 -c Rdynload.c -o Rdynload.o Rdynload.c: In function `R_FindSymbol': Rdynload.c:942: `CFunTab' undeclared (first use in this function) Rdynload.c:942: (Each undeclared identifier is reported only once Rdynload.c:942: for each function it appears in.) make[3]: *** [Rdynload.o] Error 1 make[2]: *** [R] Er...

I'm having trouble compiling the latest version of R (1.7.0) under OS (10.2.5), after running ./configure then make, building fails on the file main/Rdynload.c with the following error message. gcc -I../../src/extra/pcre -no-cpp-precomp -I. -I../../src/include -I../../src/include -I/sw/include -DHAVE_CONFIG_H -g -O2 -c Rdynload.c -o Rdynload.o Rdynload.c: In function `R_FindSymbol': Rdynload.c:1036: `CFunTab' undeclared (first use in this...

...gnu" CFLAGS="-O2 -mcpu=G4 -mtune=G4 -fno-strict-aliasing -pipe -maltivec -mabi=altivec" CHOST="powerpc-unknown-linux-gnu" Fault log gfortran -fpic -g -O2 -c xxxpr.f -o xxxpr.o powerpc-unknown-linux-gnu-gcc -shared -o libR.so Rembedded.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....

This is a request to increase MAX_NUM_DLLS in Rdynload.c in from 100 to 500. On line 131 of Rdynload.c, changing #define MAX_NUM_DLLS 100 to #define MAX_NUM_DLLS 500 In development of the mlr package, there have been several episodes in the past where we have had to break up unit tests because of the "maximum number of DLLs reached" er...

...nloaded (https://github.com/HenrikBengtsson/Wishlist-for-R/issues/29), but of course, someone needs to write the code / a patch for this to happen. /Henrik On Mon, Dec 19, 2016 at 6:01 PM, Steve Bronder <sbronder at stevebronder.com> wrote: > This is a request to increase MAX_NUM_DLLS in Rdynload.c in from 100 to 500. > > On line 131 of Rdynload.c, changing > > #define MAX_NUM_DLLS 100 > > to > > #define MAX_NUM_DLLS 500 > > > In development of the mlr package, there have been several episodes in the > past where we have had to break up unit tests becaus...

...intf.c gcc -I../../src/extra/pcre -no-cpp-precomp -I. -I../../src/include -I../../src/include -I/sw/include -DHAVE_CONFIG_H -g -O2 -c CConverters.c -o CConverters.o gcc -I../../src/extra/pcre -no-cpp-precomp -I. -I../../src/include -I../../src/include -I/sw/include -DHAVE_CONFIG_H -g -O2 -c Rdynload.c -o Rdynload.o Rdynload.c: In function `R_FindSymbol': Rdynload.c:1036: `CFunTab' undeclared (first use in this function) Rdynload.c:1036: (Each undeclared identifier is reported only once Rdynload.c:1036: for each function it appears in.) make[3]: *** [Rdynload.o] Error 1 make[2]: *** [R]...

...t; gcc -I. -I../../src/include -I../../src/include > >> -I/usr/local/include -DHAVE_CONFIG_H -g -O2 -c CConverters.c -o > >> CConverters.o > >> gcc -I. -I../../src/include -I../../src/include > >> -I/usr/local/include -DHAVE_CONFIG_H -g -O2 -c Rdynload.c -o Rdynload.o > >> Rdynload.c: In function `R_FindSymbol': > >> Rdynload.c:781: `CFunTab' undeclared (first use in this function) > >> Rdynload.c:781: (Each undeclared identifier is reported only once > >> Rdynload.c:781: for each function it appears in...

...course, someone needs to write the code / a patch for this to happen. >> >> /Henrik >> >> On Mon, Dec 19, 2016 at 6:01 PM, Steve Bronder >> <sbronder at stevebronder.com> wrote: >> > This is a request to increase MAX_NUM_DLLS in Rdynload.c in from 100 to >> 500. >> > >> > On line 131 of Rdynload.c, changing >> > >> > #define MAX_NUM_DLLS 100 >> > >> > to >> > >> > #define MAX_NUM_DLLS 500 >> > >>...

...reset the PB gcc version to default to gcc 3.1, which then allowed us to install the g77 patch. In building R, the configure is fine (except for lacking pdf and dvi support to build the manuals - no big deal right now), but during the make, the program barfs, complaining that it can't find Rdynload.c, which sits precisely where it ought to be. Again, since we have no experience with building software on the Mac, this one is tough to sort out. I read a few messages on R-devel about issues involving g77 support, but I don't know whether this is the problem or not. The errors are being...

.../ a patch for this to happen. > | >> > | >> /Henrik > | >> > | >> On Mon, Dec 19, 2016 at 6:01 PM, Steve Bronder > | >> <sbronder at stevebronder.com> wrote: > | >> > This is a request to increase MAX_NUM_DLLS in Rdynload.c in from 100 to > | >> 500. > | >> > > | >> > On line 131 of Rdynload.c, changing > | >> > > | >> > #define MAX_NUM_DLLS 100 > | >> > > | >> > to > | >> > > | >&g...

...kBengtsson/Wishlist-for-R/issues/29), but of > course, someone needs to write the code / a patch for this to happen. > > /Henrik > > On Mon, Dec 19, 2016 at 6:01 PM, Steve Bronder > <sbronder at stevebronder.com> wrote: > > This is a request to increase MAX_NUM_DLLS in Rdynload.c in from 100 to > 500. > > > > On line 131 of Rdynload.c, changing > > > > #define MAX_NUM_DLLS 100 > > > > to > > > > #define MAX_NUM_DLLS 500 > > > > > > In development of the mlr package, there have been several episodes in &...

It's not always clear when it's safe to remove the DLL. The main problem that I'm aware of is that native objects with finalizers might still exist (created by R_RegisterCFinalizer etc). Even if there are no live references to such objects (which would be hard to verify), it still wouldn't be safe to unload the DLL until a full garbage collection has been done. If the DLL is

It does, but you'd still be relying on the R code ensuring that all of these objects are dead prior to unloading the DLL, otherwise they'll survive the GC. Maybe if the package counted how many such objects exist, it could work out when it's safe to remove the DLL. I'm not sure that it can be done automatically. What could be done is to to keep the DLL loaded, but remove it from

On Tue, Dec 20, 2016 at 7:04 AM, Henrik Bengtsson <henrik.bengtsson at gmail.com> wrote: > On reason for hitting the MAX_NUM_DLLS (= 100) limit is because some > packages don't unload their DLLs when they being unloaded themselves. I am surprised by this. Why does R not do this automatically? What is the case for keeping the DLL loaded after the package has been unloaded? What

Hi, I'm trying to register my native routines using R_registerRoutines (...). I can compile the code, but the loader cannot resolve the symbol: undefined symbol: _Z18R_registerRoutinesP8_DllInfoPK12R_CMethodDefPK15R_CallMethodDefS3_S6 _ $ nm bgx.Rcheck/bgx/libs/bgx.so | grep R_registerRoutines U _Z18R_registerRoutinesP8_DllInfoPK12R_CMethodDefPK15R_CallMethodDefS3_S6

...one needs to write the code / a patch for this to happen. | >> | >> /Henrik | >> | >> On Mon, Dec 19, 2016 at 6:01 PM, Steve Bronder | >> <sbronder at stevebronder.com> wrote: | >> > This is a request to increase MAX_NUM_DLLS in Rdynload.c in from 100 to | >> 500. | >> > | >> > On line 131 of Rdynload.c, changing | >> > | >> > #define MAX_NUM_DLLS 100 | >> > | >> > to | >> > | >> > #define MAX_NUM_DLLS 500 | >&g...

Hi all, I'm preparing a package which uses .Fortran to interface a Fortran 95 function. This F95 function simply receives the name of a file from R, opens this file and forwards its content to a F95 module, which, in turn, makes the real computation. The F95 module is a pre-existing one and I'm trying to use it in its actual state. Thus, data transfer between R and this F95 module is

On Tue, Dec 20, 2016 at 7:39 AM, Karl Millar <kmillar at google.com> wrote: > It's not always clear when it's safe to remove the DLL. > > The main problem that I'm aware of is that native objects with > finalizers might still exist (created by R_RegisterCFinalizer etc). > Even if there are no live references to such objects (which would be > hard to verify), it