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 resolves the problem, albeit generating a long list of undefined reference warnings during the link. -Greg> -----Original Message----- > From: Duncan Temple Lang [mailto:duncan@research.bell-labs.com] > Sent: Wednesday, May 08, 2002 7:15 PM > To: Warnes, Gregory R > Cc: 'R-devel@stat.math.ethz.ch'; 'Walter Moreira' > Subject: Re: embedded R resolving wrong symbols > > > Hi Greg. > > Yes, there are some ways to arrange for tight/eager binding > rather than dynamically loading libraries. They do depend on > the linker being used and unfortunately precisely how the > libraries containing the symbols are being "included". > > One GNU linker option that is of relevance here is -Bsymbolic > which is documented as > "When creating a shared library, bind references to global symbols > to the definition within the shared library, if any. ....." > > As a quick guess, I would add this to R's Makeconf for building > libR.so so that all possible symbols are resolved locally within that > library. Then try linking again. > > > I have seen this on several different systems over the past few years > and I have written up _some_ of the details that I discovered > on this topic. > Unfortunately, I won't have time to dig them up until I get > back to the office at the > beginning of next week. Please remind me. > > D. > > Warnes, Gregory R wrote: > > > > Hi All, > > > > When R is embedded in python on my system (Solaris 8), > calls to the c > > functions 'regcomp' and 'regexec' are being resolved to the > c-library, > > rather than the functions compiled from regex.c. This > leads to segfaults > > because the c-library functions have quite different semantics. > > > > Is there any way to get around this, other than renaming > the offending > > functions? E.G., would it be possible to use the '-wrap' > argument to ld, or > > perhaps there is another argument which says 'check inside > this library for > > symbols before looking elsewhere'? > > > > Thanks, > > > > -Greg > > > > ----------------- obligatory version information > > > > R 1.4.1, 1.5.0, > > gcc 2.95.2, 3.0.3, > > python 2.1.1, 2.1.3 > > SunOs 5.8, sparc > > > > > > > > > > LEGAL NOTICE > > Unless expressly stated otherwise, this message is > confidential and may be privileged. It is intended for the > addressee(s) only. Access to this E-mail by anyone else is > unauthorized. If you are not an addressee, any disclosure or > copying of the contents of this E-mail or any action taken > (or not taken) in reliance on it is unauthorized and may be > unlawful. If you are not an addressee, please inform the > sender immediately. >-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
ripley@stats.ox.ac.uk
2002-May-09 16:47 UTC
[Rd] Fixed: embedded R resolving wrong symbols
Coincidentally, the regex symbols are now remapped in R-devel. This was to allow the use of PCRE (which also defines them), so that may merely have made the problem worse on machines with PCRE installed. Maybe one day I'll summon the energy to use PCRE's native interface instead. On Thu, 9 May 2002, Warnes, Gregory R wrote:> 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 resolves the problem, albeit generating a long list of undefined > reference warnings during the link. > > -Greg > > > > -----Original Message----- > > From: Duncan Temple Lang [mailto:duncan@research.bell-labs.com] > > Sent: Wednesday, May 08, 2002 7:15 PM > > To: Warnes, Gregory R > > Cc: 'R-devel@stat.math.ethz.ch'; 'Walter Moreira' > > Subject: Re: embedded R resolving wrong symbols > > > > > > Hi Greg. > > > > Yes, there are some ways to arrange for tight/eager binding > > rather than dynamically loading libraries. They do depend on > > the linker being used and unfortunately precisely how the > > libraries containing the symbols are being "included". > > > > One GNU linker option that is of relevance here is -Bsymbolic > > which is documented as > > "When creating a shared library, bind references to global symbols > > to the definition within the shared library, if any. ....." > > > > As a quick guess, I would add this to R's Makeconf for building > > libR.so so that all possible symbols are resolved locally within that > > library. Then try linking again. > > > > > > I have seen this on several different systems over the past few years > > and I have written up _some_ of the details that I discovered > > on this topic. > > Unfortunately, I won't have time to dig them up until I get > > back to the office at the > > beginning of next week. Please remind me. > > > > D. > > > > Warnes, Gregory R wrote: > > > > > > Hi All, > > > > > > When R is embedded in python on my system (Solaris 8), > > calls to the c > > > functions 'regcomp' and 'regexec' are being resolved to the > > c-library, > > > rather than the functions compiled from regex.c. This > > leads to segfaults > > > because the c-library functions have quite different semantics. > > > > > > Is there any way to get around this, other than renaming > > the offending > > > functions? E.G., would it be possible to use the '-wrap' > > argument to ld, or > > > perhaps there is another argument which says 'check inside > > this library for > > > symbols before looking elsewhere'? > > > > > > Thanks, > > > > > > -Greg > > > > > > ----------------- obligatory version information > > > > > > R 1.4.1, 1.5.0, > > > gcc 2.95.2, 3.0.3, > > > python 2.1.1, 2.1.3 > > > SunOs 5.8, sparc > > > > > > > > > > > > > > > LEGAL NOTICE > > > Unless expressly stated otherwise, this message is > > confidential and may be privileged. It is intended for the > > addressee(s) only. Access to this E-mail by anyone else is > > unauthorized. If you are not an addressee, any disclosure or > > copying of the contents of this E-mail or any action taken > > (or not taken) in reliance on it is unauthorized and may be > > unlawful. If you are not an addressee, please inform the > > sender immediately. > > > -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- > r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html > Send "info", "help", or "[un]subscribe" > (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch > _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._ >-- Brian D. Ripley, ripley@stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272860 (secr) Oxford OX1 3TG, UK Fax: +44 1865 272595 -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._