similar to: embedded R resolving wrong symbols

Hi Duncan Your suggestion to use '-Bsymbolic' proved to be (almost) the solution. I tried that and it didn't work because I'm using gcc instead of Sun's compilers. It took me a bit of time to discoed that gcc uses '-symbolic' rather than '-Bsymbolic'. Once I figured that out, changing LIBR_LDFLAGS = -shared to LIBR_LDFLAGS = -symbolic -shared in Makeconf

On Aug 23, 2009, at 9:01 PM, Daniel Berlin wrote: >> 2. Use POSIX regcomp facilities. This implies importing some >> implementation of this interface, e.g., Windows. On Linux, BSD, etc. >> we would try to use the platform version if available (and non- >> buggy). > > Don't do it. > They are ridiculous slow, and posix made some really dumb choices in >

Hi All, I have two small things that I would appreciate some help with: 1. Config/Alloca.h is now dead. Once configure and cmake support is removed, we can zap it. Can someone remove the cmake/autoconf stuff that pokes at Config/Alloca.h? 2. Daniel's regex email. I think the right answer is to just autodetect whether regcomp/regexec etc are available (his #2). Could someone add

On Sun, Aug 23, 2009 at 3:29 PM, Kenneth Uildriks<kennethuil at gmail.com> wrote: > On Sun, Aug 23, 2009 at 4:56 PM, Daniel Dunbar<daniel at zuster.org> wrote: >> We would like to have access to some kind of regular expression >> library inside LLVM. For example, we need this to extend the FileCheck >> test case checking tool to support regular expressions.

Chris Lattner <clattner at apple.com> writes: > 1. Config/Alloca.h is now dead. Once configure and cmake support is > removed, we can zap it. Can someone remove the cmake/autoconf stuff > that pokes at Config/Alloca.h? AFAIK, there is nothing specific for include/llvm/Config/alloca.h on the cmake build and it works fine after removing the file (checked on Linux x86_64).

On Sun, Aug 23, 2009 at 5:04 PM, Óscar Fuentes<ofv at wanadoo.es> wrote: > Chris Lattner <clattner at apple.com> writes: > >> 1. Config/Alloca.h is now dead.  Once configure and cmake support is >> removed, we can zap it.  Can someone remove the cmake/autoconf stuff >> that pokes at Config/Alloca.h? > > AFAIK, there is nothing specific for

On Sun, Aug 23, 2009 at 5:56 PM, Daniel Dunbar<daniel at zuster.org> wrote: > We would like to have access to some kind of regular expression > library inside LLVM. For example, we need this to extend the FileCheck > test case checking tool to support regular expressions. > > There are three obvious options: >  1. Roll our own library. Multiple unnamed individuals may even

Under RSPython and rpy, the regexec C function is returning nonsensical results leading to segmentation faults. This is happening in some situations under R 1.4.1 and (more often?) under R 1.5.0 on my Solaris 8 box. R 1.4.1 was compiled with gcc 2.95.2, and I've tried 1.5.0 with both gcc 2.95.2 and gcc 3.0.3. The error appears to be exactly the same under both python tools and both

On 2009-08-24 07:28, Chris Lattner wrote: > On Aug 23, 2009, at 9:01 PM, Daniel Berlin wrote: > >>> 2. Use POSIX regcomp facilities. This implies importing some >>> implementation of this interface, e.g., Windows. On Linux, BSD, etc. >>> we would try to use the platform version if available (and non- >>> buggy). >>> >> Don't

We would like to have access to some kind of regular expression library inside LLVM. For example, we need this to extend the FileCheck test case checking tool to support regular expressions. There are three obvious options: 1. Roll our own library. Multiple unnamed individuals may even already have implementations lying around! :) 2. Use POSIX regcomp facilities. This implies importing some

Hi, In R 3.4.0, the "Pattern Matching and Replacement" documentation that describes regexec(), gregexpr(), etc. states that the "text" argument to regexec is a character vector, "or an object which can be coerced by as.character to a character vector": regexec(pattern, text, ignore.case = FALSE, perl = FALSE, fixed = FALSE, useBytes = FALSE)

I've just tried using both Duncan's RSPython and Walter Moriera's rpy with R 1.5.0. Both segfaulted during startup in exactly the same place, apparently while trying to load the ctest package. Recompiling the packages doesn't seem to have any effect on this outcome. Here's the first few lines of a gdb backtrace: #0 0xff132df8 in strlen () from /usr/lib/libc.so.1 #1

On Sun, Aug 23, 2009 at 4:56 PM, Daniel Dunbar<daniel at zuster.org> wrote: > We would like to have access to some kind of regular expression > library inside LLVM. For example, we need this to extend the FileCheck > test case checking tool to support regular expressions. > > There are three obvious options: >  1. Roll our own library. Multiple unnamed individuals may even

Hi, this is not a bug report since this may not be a problem with R per se. The current release of R (1.1.0) will compile cleanly on an AIX box (I have 4.3.2) but it will fail upon startup with an Illegal Instruction. I've located the problem to be in do_strsplit when R calls regcomp. This function is defined in regex.c. However, the text from regex.o doesn't find its way into the

On Aug 23, 2009, at 5:50 PM, OvermindDL1 wrote: > On Sun, Aug 23, 2009 at 6:32 PM, Daniel Dunbar<daniel at zuster.org> > wrote: >> This is too heavy, and we don't need the extra features, and regexec >> is well tested and much more standard. Unless there is an >> overwhelming > > 'regexec' I had never heard of, figured it was a library, turns

Hi, I am compiling R-0.50 on my SGI Indigo 2 R8000 machine with IRIX6.1 and it stopped in the middle. Could anyone help me to fix it? Many thanks! p.s.: The last lines of message: : ../lib/libappl.a cd regex; make cc -g -I../include -DPOSIX_MISTAKE -c regcomp.c "regcomp.c", line 753: warning(1110): statement is unreachable break; ^ cc -g -I../include -DPOSIX_MISTAKE -c

Hi, I am compiling R-0.50 on my SGI Indigo 2 R8000 machine with IRIX6.1 and it stopped in the middle. Could anyone help me to fix it? Many thanks! p.s.: The last lines of message: : ../lib/libappl.a cd regex; make cc -g -I../include -DPOSIX_MISTAKE -c regcomp.c "regcomp.c", line 753: warning(1110): statement is unreachable break; ^ cc -g -I../include -DPOSIX_MISTAKE -c

Here are a couple of patches against the CVS (Jan 22 18:41 PST) Some C++ comments found their way into ssh.h The no64.patch puts ifdefs around buffer_get_int64() now in bufaux.[c,h] -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net -------------- next part -------------- --- ssh.h.old Mon Jan 22 18:40:58 2001 +++ ssh.h Mon Jan 22 19:02:02 2001 @@ -25,8 +25,10 @@ # include

On Sun, Aug 23, 2009 at 6:32 PM, Daniel Dunbar<daniel at zuster.org> wrote: > This is too heavy, and we don't need the extra features, and regexec > is well tested and much more standard. Unless there is an overwhelming 'regexec' I had never heard of, figured it was a library, turns out it is a function call on *nix systems, yea, that is very much not usable in any way

On Sun, Aug 23, 2009 at 10:20 PM, Chris Lattner<clattner at apple.com> wrote: > On Aug 23, 2009, at 9:11 PM, OvermindDL1 wrote: >>> >>> Again, forget boost regex. :) >> >> What about std::regex? > > No, we have to build with c++'98 compilers. I think you're missing the > point here. We care about code size in llvm, and the best code size