Fixed: embedded R resolving wrong symbols

2 messages · Warnes, Gregory R, Brian Ripley

Thu, May 9, 2002 9:33 AM #

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 Ripley

Thu, May 9, 2002 9:47 AM #

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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._