This is the mail archive of the
mailing list for the binutils project.
Re: Using binutils-2.12.1 on sparc64-sun-solaris2.8 to build gcc-3.1 results in relocation errors
David S. Miller wrote:
> From: Alan Modra <firstname.lastname@example.org>
> Date: Tue, 16 Jul 2002 12:10:12 +0930
> On Mon, Jul 15, 2002 at 12:45:33PM -0500, Dana, Eric wrote:
> > When building some of our 64-bit libraries in C++, we are seeing
> > R_SPARC_DISP32 errors:
> Please try current binutils CVS. If the problem isn't fixed there,
> now would be the time to shout about it. We're about to release 2.13.
I have exactly the same problem with C++ code and gcc 3.1 and newer, and
binutils 2.12.1 and newer.
> Actually this looks like some kind of code-model error.
> There should not be any R_SPARC_DISP32 relocations generated
> as no "call" instruction based function invocations should
> be emitted with Solaris's default code model.
> "Call" is the only way R_SPARC_DISP32 relocations can be
As far as I can see, only "call" instructions are ever emitted by gcc.
Nothing changes if I use -m32, -m64, -mcmodel=<any value>.
Am I missing something, or am I just ignorant?
> I really doubt this is a binutils bug. It is either some user
> configuration error, or the libtool machinery is causing the
> wrong code model to be used when generating the c++ libraries
> and/or binaries.
> If these folks are specifying the code-model explicitly on the
> command line, and linking with libstdc++ this could cause errors
> like the above as well.
In my projects no libtool used, just plain makefiles. No code models ever
specified, just -m64. And everything with plain C works, the only problem
is with non-trivial C++, where shared libraries are built and used. I
don't really know what is the point when the problem appears, every time I
try to produce a test case, it works.