* Using binutils-2.12.1 on sparc64-sun-solaris2.8 to build gcc-3.1 results in relocation errors
@ 2002-07-15 10:46 Dana, Eric
2002-07-15 19:56 ` Alan Modra
0 siblings, 1 reply; 12+ messages in thread
From: Dana, Eric @ 2002-07-15 10:46 UTC (permalink / raw)
To: 'binutils@sources.redhat.com', 'gcc-bugs@gcc.gnu.org'
When building some of our 64-bit libraries in C++, we are seeing
R_SPARC_DISP32 errors:
../../../obj/sun/sparc-solaris2.7W/monitor/lib/Agent/libAgent.a(alert.o):iti
merspec/alert.C:37:
relocation truncated to fit: R_SPARC_DISP32
.gnu.linkonce.t._ZN10printClass5printEiPKc
../../../obj/sun/sparc-solaris2.7W/monitor/lib/Agent/libAgent.a(alert.o):iti
merspec/alert.C:37:
relocation truncated to fit: R_SPARC_DISP32
.gnu.linkonce.t._ZN10printClass6indentEi
../../../obj/sun/sparc-solaris2.7W/monitor/lib/Agent/libAgent.a(agentConditi
on.o):itimerspec/agentCondition.C:50:
relocation truncated to fit: R_SPARC_DISP32
.gnu.linkonce.t._ZN10printClass5printEiPKcm
and many, many more...
This happens on Solaris 2.7/2.8 when linking 64-bit objects.
Below is a reference from another developer (taken from the binutils
archives)
2002-05/msg01920.html
At this time we have no workaround. Can a previous version of binutils be
used on Solaris with 64-bit linking
with GCC 3.1 or later?
--Eric Dana--
BMC Software Inc.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Using binutils-2.12.1 on sparc64-sun-solaris2.8 to build gcc-3.1 results in relocation errors
2002-07-15 10:46 Using binutils-2.12.1 on sparc64-sun-solaris2.8 to build gcc-3.1 results in relocation errors Dana, Eric
@ 2002-07-15 19:56 ` Alan Modra
2002-07-16 0:14 ` David S. Miller
0 siblings, 1 reply; 12+ messages in thread
From: Alan Modra @ 2002-07-15 19:56 UTC (permalink / raw)
To: Dana, Eric
Cc: 'binutils@sources.redhat.com', 'gcc-bugs@gcc.gnu.org'
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.
http://sources.redhat.com/binutils/ for instructions on accessing the
cvs server.
--
Alan Modra
IBM OzLabs - Linux Technology Centre
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Using binutils-2.12.1 on sparc64-sun-solaris2.8 to build gcc-3.1 results in relocation errors
2002-07-15 19:56 ` Alan Modra
@ 2002-07-16 0:14 ` David S. Miller
2002-07-17 10:54 ` Teemu Torma
2002-07-18 0:45 ` Jakub Jelinek
0 siblings, 2 replies; 12+ messages in thread
From: David S. Miller @ 2002-07-16 0:14 UTC (permalink / raw)
To: amodra; +Cc: Eric_Dana, binutils, gcc-bugs
From: Alan Modra <amodra@bigpond.net.au>
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.
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
emitted.
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Using binutils-2.12.1 on sparc64-sun-solaris2.8 to build gcc-3.1 results in relocation errors
2002-07-16 0:14 ` David S. Miller
@ 2002-07-17 10:54 ` Teemu Torma
2002-07-17 18:32 ` Alan Modra
2002-07-18 0:45 ` Jakub Jelinek
1 sibling, 1 reply; 12+ messages in thread
From: Teemu Torma @ 2002-07-17 10:54 UTC (permalink / raw)
To: David S. Miller, binutils, gcc-bugs
David S. Miller wrote:
> From: Alan Modra <amodra@bigpond.net.au>
> 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
> emitted.
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.
Teemu
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Using binutils-2.12.1 on sparc64-sun-solaris2.8 to build gcc-3.1 results in relocation errors
2002-07-17 10:54 ` Teemu Torma
@ 2002-07-17 18:32 ` Alan Modra
2002-07-17 20:20 ` David S. Miller
0 siblings, 1 reply; 12+ messages in thread
From: Alan Modra @ 2002-07-17 18:32 UTC (permalink / raw)
To: David S. Miller; +Cc: Teemu Torma, binutils, gcc-bugs
On Wed, Jul 17, 2002 at 07:06:50PM +0200, Teemu Torma wrote:
> David S. Miller wrote:
> > From: Alan Modra <amodra@bigpond.net.au>
> > 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.
>
> > "Call" is the only way R_SPARC_DISP32 relocations can be
> > emitted.
David, are you sure you don't get these reloc types in dwarf2 debug
sections?
--
Alan Modra
IBM OzLabs - Linux Technology Centre
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Using binutils-2.12.1 on sparc64-sun-solaris2.8 to build gcc-3.1 results in relocation errors
2002-07-17 18:32 ` Alan Modra
@ 2002-07-17 20:20 ` David S. Miller
2002-07-18 8:17 ` Teemu Torma
0 siblings, 1 reply; 12+ messages in thread
From: David S. Miller @ 2002-07-17 20:20 UTC (permalink / raw)
To: amodra; +Cc: tot, binutils, gcc-bugs
From: Alan Modra <amodra@bigpond.net.au>
Date: Thu, 18 Jul 2002 10:43:51 +0930
On Wed, Jul 17, 2002 at 07:06:50PM +0200, Teemu Torma wrote:
> > "Call" is the only way R_SPARC_DISP32 relocations can be
> > emitted.
David, are you sure you don't get these reloc types in dwarf2 debug
sections?
32-bit PC-relative relocations? I really doubt it :-)
I did make a brain fart though, "call" is valid in several situations,
PIC function calls in particular because that goes through the PLT
which will be near the code itself.
I still maintain that this isn't a binutils bug but rather some other
problem.
A repeatable testcase from the bug reporter posted here and in GNATS
would be highly appreciated so that something concrete can be done
about this problem. Currently we are groveling over the bug because
not enough information is present. A reproducable testcase would
eliminate this problem.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Using binutils-2.12.1 on sparc64-sun-solaris2.8 to build gcc-3.1 results in relocation errors
2002-07-16 0:14 ` David S. Miller
2002-07-17 10:54 ` Teemu Torma
@ 2002-07-18 0:45 ` Jakub Jelinek
1 sibling, 0 replies; 12+ messages in thread
From: Jakub Jelinek @ 2002-07-18 0:45 UTC (permalink / raw)
To: David S. Miller; +Cc: amodra, Eric_Dana, binutils, gcc-bugs
On Mon, Jul 15, 2002 at 07:44:14PM -0700, David S. Miller wrote:
> From: Alan Modra <amodra@bigpond.net.au>
> 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.
>
> 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
> emitted.
No, call generates R_SPARC_WDISP32. R_SPARC_DISP32 is generated by
something like .word %r_disp32(foo + 12345).
%r_disp32() is emitted by gcc for the .eh_frame section (only when using
GNU ld, since Solaris ld has broken support for misaligned PC relative
relocs).
Are your 64-bit libraries bigger than 2GB?
Jakub
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Using binutils-2.12.1 on sparc64-sun-solaris2.8 to build gcc-3.1 results in relocation errors
2002-07-17 20:20 ` David S. Miller
@ 2002-07-18 8:17 ` Teemu Torma
0 siblings, 0 replies; 12+ messages in thread
From: Teemu Torma @ 2002-07-18 8:17 UTC (permalink / raw)
To: David S. Miller, amodra; +Cc: binutils, gcc-bugs
[-- Attachment #1: Type: text/plain, Size: 2109 bytes --]
On Thursday 18 July 2002 03:21, David S. Miller wrote:
> I did make a brain fart though, "call" is valid in several situations,
> PIC function calls in particular because that goes through the PLT
> which will be near the code itself.
All the failing symbols are in gnu.linkonce sections. What happens when
symbols get deleted.
> A repeatable testcase from the bug reporter posted here and in GNATS
> would be highly appreciated so that something concrete can be done
> about this problem. Currently we are groveling over the bug because
> not enough information is present. A reproducable testcase would
> eliminate this problem.
I finally managed to create test case that fails. See the attached perl
script that creates files, libraries and tries to link them in the current
directory.
The script is slightly complex, since I had trouble reproducing it, and I
thought it must be number or size of the libraries. But it turns out that it
starts failing only when there is more than one object in the "main" program.
$ perl link-test.pl
g++ -m64 -mcpu=ultrasparc -fPIC -c l_1_1.cc
g++ -m64 -mcpu=ultrasparc -fPIC -c l_1_2.cc
g++ -m64 -mcpu=ultrasparc --shared -o libl_1.so l_1_1.o l_1_2.o -L`pwd`
g++ -m64 -mcpu=ultrasparc -c main_1.cc
g++ -m64 -mcpu=ultrasparc -c main_2.cc
g++ -m64 -mcpu=ultrasparc -o link-test main_1.o main_2.o -L`pwd` -ll_1
main_2.o(.eh_frame+0x70): relocation truncated to fit: R_SPARC_DISP32
.gnu.linkonce.t._ZN7foo_1_1D1Ev
main_2.o(.eh_frame+0x90): relocation truncated to fit: R_SPARC_DISP32
.gnu.linkonce.t._ZN7foo_1_110to_destroyC1Ev
main_2.o(.eh_frame+0xb0): relocation truncated to fit: R_SPARC_DISP32
.gnu.linkonce.t._ZN7foo_1_110to_destroyD1Ev
main_2.o(.eh_frame+0xd0): relocation truncated to fit: R_SPARC_DISP32
.gnu.linkonce.t._ZN7foo_1_18method_1Ev
main_2.o(.eh_frame+0xf0): relocation truncated to fit: R_SPARC_DISP32
.gnu.linkonce.t._ZN7foo_1_18method_2Ev
main_2.o(.eh_frame+0x110): relocation truncated to fit: R_SPARC_DISP32
.gnu.linkonce.t._ZN7foo_1_1C1Ev
collect2: ld returned 1 exit status
Teemu
[-- Attachment #2: link-test.pl --]
[-- Type: text/x-perl, Size: 3261 bytes --]
#!/usr/bin/env perl
$num_libs = 1;
$num_classes = 2;
$num_methods = 2;
$num_mains = 2;
$gxx = "g++ -m64 -mcpu=ultrasparc";
# Build method declarations.
my $method_decl, @method_decl;
my $method_call, @method_call;
foreach $method (1 .. $num_methods) {
push (@method_decl, "void method_${method} () { throw 1; }");
push (@method_call, "to_destroy d_${method}; method_${method} ();");
}
$method_decl = join ("\n ", @method_decl);
$method_call = join ("\n ", @method_call);
foreach $lib (1 .. $num_libs) {
my @objs;
foreach $class (1 .. $num_classes) {
my $header = "l_${lib}_${class}.h";
open (HEADER, ">${header}") || die "Can not open $header";
print HEADER <<EOH;
#include <iostream>
#include <string>
struct foo_${lib}_${class}
{
typedef foo_${lib}_${class} self_type;
struct to_destroy
{
to_destroy () { self_type tem; tem.method_1 (); }
~to_destroy () { self_type tem; tem.method_1 (); }
};
foo_${lib}_${class} ()
{
$method_call
}
foo_${lib}_${class} (const self_type &)
{
$method_call
}
~foo_${lib}_${class} ()
{
$method_call
}
$method_decl
static self_type bar ();
std::string _a_string;
};
EOH
close (HEADER);
}
foreach $class (1 .. $num_classes) {
my $source = "l_${lib}_${class}.cc";
my $object = "l_${lib}_${class}.o";
open (SOURCE, ">${source}") || die "Can not open $source";
foreach $j (1 .. $lib) {
foreach $i (1 .. $num_classes) {
print SOURCE <<EOS1;
#include "l_${j}_${i}.h"
EOS1
}
}
print SOURCE <<EOS2;
foo_${lib}_${class}
foo_${lib}_${class}::bar ()
{
std::cout << "something to instanciate templates\\n";
EOS2
foreach $j (1 .. $lib) {
foreach $i (1 .. $num_classes) {
print SOURCE <<EOS3;
foo_${j}_${i}::bar ();
EOS3
}
}
print SOURCE <<EOS4;
return foo_${lib}_${class} ();
}
EOS4
close SOURCE;
my $compile = "${gxx} -fPIC -c $source";
print $compile, "\n";
system ($compile) && die "Compilation failed";
push (@objs, $object);
}
my $link
= "${gxx} --shared -o libl_${lib}.so "
. join (' ', @objs)
. " -L`pwd` "
. join (' ', @libs);
print $link, "\n";
system ($link) && die "Link failed";
push (@libs, "-ll_${lib}");
}
foreach $main (1 .. $num_mains) {
my $source = "main_${main}.cc";
my $object = "main_${main}.o";
open (MAIN, ">${source}") || die "Can not open ${source}";
foreach $lib (1 .. $num_libs) {
foreach $class (1 .. $num_classes) {
print MAIN <<EOM1;
#include "l_${lib}_${class}.h"
EOM1
}
}
my $main_name = ($main == 1 ? "main" : "main_${main}");
print MAIN <<EOM2;
int
${main_name} ()
{
EOM2
foreach $lib (1 .. $num_libs) {
foreach $class (1 .. $num_classes) {
next if ($class % 2 == 0);
print MAIN <<EOM3;
foo_${lib}_${class}::bar ();
EOM3
}
}
print MAIN <<EOM4;
return 0;
}
EOM4
close MAIN;
my $compile = "${gxx} -c $source";
print $compile, "\n";
system ($compile) && die "Compilation failed";
push (@mains, $object);
}
my $link = "${gxx} -o link-test "
. join (' ', @mains)
. " -L`pwd` " . join (' ', @libs);
print $link, "\n";
system ($link) && die "Link failed";
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Using binutils-2.12.1 on sparc64-sun-solaris2.8 to build gcc-3.1 results in relocation errors
2002-07-29 20:53 ` Daniel Jacobowitz
@ 2002-07-30 5:22 ` Brad Spencer
0 siblings, 0 replies; 12+ messages in thread
From: Brad Spencer @ 2002-07-30 5:22 UTC (permalink / raw)
To: binutils
On Mon, Jul 29, 2002 at 11:34:23PM -0400, Daniel Jacobowitz wrote:
> On Tue, May 28, 2002 at 11:49:49AM -0300, Brad Spencer wrote:
> > I've looked through the archives and the comments in gcc-3.1, and it
> > looks like this might be some sort of new feature that doesn't quite
> > work correctly. If I configure gcc-3.1 on top of binutils-2.12.1,
> > then when I link 64-bit objects, I get things to the effect of
>
> Could you try this with a 2.13 snapshot? There's one in
> /pub/binutils/snapshots, marked 2.12.91.
I will try this today and report back. It's my understanding I'll
need >=2.12 for gcc-3.2, so this was a pleasant surprise :)
> >
> > netra-map1:~$ g++ -Wall -m64 -o foo foo.cc -save-temps
> > /opt/gcc-3.1/lib/gcc-lib/sparc-sun-solaris2.8/3.1/../../../sparcv9/libstdc++.a(stl-inst.o)(.eh_frame+0xf0):
> > relocation truncated to fit: R_SPARC_DISP32
> > .gnu.linkonce.t._ZNSt24__default_alloc_templateILb1ELi0EE8allocateEm
> >
> > This is totally a Hello World application:
> >
> > static const char *st_ID __attribute__((unused)) =
> > "$Id$";
> >
> > #include <iostream>
> >
> > int
> > main()
> > {
> > std::cout << "hello world" << std::endl;
> > return 0;
> > }
> >
> > When I configure gcc-3.1 on top of binutils-2.11.2, this doesn't
> > happen.
> >
> > netra-map1:~$ g++ -m64 -Wall -o foo foo.cc -save-temps
> > netra-map1:~$ ./foo
> > hello world
> >
> > Inside gcc-3.1/gcc/config/sparc/sparc.h, I find the following
> > comment:
> >
> > /* [...]
> > binutils 2.12 would emit a R_SPARC_DISP32 dynamic relocation if the
> > symbol %r_disp32() is against was not local, but .hidden. In that
> > case, we have to use DW_EH_PE_absptr for pic personality. */
> >
> > >From what I can tell from this mailing list, the %r_dispX notation is
> > a new feature in gas. Is this a bug?
> >
> > netra-map1:~$ gcc -v
> > Reading specs from
> > /opt/gcc-3.1/lib/gcc-lib/sparc-sun-solaris2.8/3.1/specs
> > Configured with: ../gcc-3.1/configure --with-dwarf2
> > --enable-languages=c,c++ --enable-threads=single --disable-shared
> > --with-gnu-as --with-gnu-ld --with-as=/opt/bin/as
> > --with-ld=/opt/bin/ld --prefix=/opt/gcc-3.1
> > Thread model: single
> > gcc version 3.1
> > netra-map1:~$ gcc -print-prog-name=as
> > /opt/bin/as
> > netra-map1:~$ /opt/bin/as --version
> > GNU assembler 2.11.2
> > netra-map1:~$ gcc -print-prog-name=ld
> > /opt/bin/ld
> > netra-map1:~$ /opt/bin/ld --version
> > GNU ld 2.11.2
> > Copyright 2001 Free Software Foundation, Inc.
> > This program is free software; you may redistribute it under the terms
> > of
> > the GNU General Public License. This program has absolutely no
> > warranty.
> > Supported emulations:
> > elf32_sparc
> > elf64_sparc
> >
> >
> > --
> > -----------------------------------------------------------------
> > Brad Spencer - spencer@infointeractive.com - "It's quite nice..."
> > Systems Architect | InfoInterActive Corp. | An AOL Company
>
> --
> Daniel Jacobowitz Carnegie Mellon University
> MontaVista Software Debian GNU/Linux Developer
--
-----------------------------------------------------------------
Brad Spencer - spencer@infointeractive.com - "It's quite nice..."
Systems Architect | InfoInterActive Corp. | An AOL Company
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Using binutils-2.12.1 on sparc64-sun-solaris2.8 to build gcc-3.1 results in relocation errors
2002-05-28 7:50 Brad Spencer
@ 2002-07-29 20:53 ` Daniel Jacobowitz
2002-07-30 5:22 ` Brad Spencer
0 siblings, 1 reply; 12+ messages in thread
From: Daniel Jacobowitz @ 2002-07-29 20:53 UTC (permalink / raw)
To: Brad Spencer; +Cc: binutils
On Tue, May 28, 2002 at 11:49:49AM -0300, Brad Spencer wrote:
> I've looked through the archives and the comments in gcc-3.1, and it
> looks like this might be some sort of new feature that doesn't quite
> work correctly. If I configure gcc-3.1 on top of binutils-2.12.1,
> then when I link 64-bit objects, I get things to the effect of
Could you try this with a 2.13 snapshot? There's one in
/pub/binutils/snapshots, marked 2.12.91.
>
> netra-map1:~$ g++ -Wall -m64 -o foo foo.cc -save-temps
> /opt/gcc-3.1/lib/gcc-lib/sparc-sun-solaris2.8/3.1/../../../sparcv9/libstdc++.a(stl-inst.o)(.eh_frame+0xf0):
> relocation truncated to fit: R_SPARC_DISP32
> .gnu.linkonce.t._ZNSt24__default_alloc_templateILb1ELi0EE8allocateEm
>
> This is totally a Hello World application:
>
> static const char *st_ID __attribute__((unused)) =
> "$Id$";
>
> #include <iostream>
>
> int
> main()
> {
> std::cout << "hello world" << std::endl;
> return 0;
> }
>
> When I configure gcc-3.1 on top of binutils-2.11.2, this doesn't
> happen.
>
> netra-map1:~$ g++ -m64 -Wall -o foo foo.cc -save-temps
> netra-map1:~$ ./foo
> hello world
>
> Inside gcc-3.1/gcc/config/sparc/sparc.h, I find the following
> comment:
>
> /* [...]
> binutils 2.12 would emit a R_SPARC_DISP32 dynamic relocation if the
> symbol %r_disp32() is against was not local, but .hidden. In that
> case, we have to use DW_EH_PE_absptr for pic personality. */
>
> >From what I can tell from this mailing list, the %r_dispX notation is
> a new feature in gas. Is this a bug?
>
> netra-map1:~$ gcc -v
> Reading specs from
> /opt/gcc-3.1/lib/gcc-lib/sparc-sun-solaris2.8/3.1/specs
> Configured with: ../gcc-3.1/configure --with-dwarf2
> --enable-languages=c,c++ --enable-threads=single --disable-shared
> --with-gnu-as --with-gnu-ld --with-as=/opt/bin/as
> --with-ld=/opt/bin/ld --prefix=/opt/gcc-3.1
> Thread model: single
> gcc version 3.1
> netra-map1:~$ gcc -print-prog-name=as
> /opt/bin/as
> netra-map1:~$ /opt/bin/as --version
> GNU assembler 2.11.2
> netra-map1:~$ gcc -print-prog-name=ld
> /opt/bin/ld
> netra-map1:~$ /opt/bin/ld --version
> GNU ld 2.11.2
> Copyright 2001 Free Software Foundation, Inc.
> This program is free software; you may redistribute it under the terms
> of
> the GNU General Public License. This program has absolutely no
> warranty.
> Supported emulations:
> elf32_sparc
> elf64_sparc
>
>
> --
> -----------------------------------------------------------------
> Brad Spencer - spencer@infointeractive.com - "It's quite nice..."
> Systems Architect | InfoInterActive Corp. | An AOL Company
--
Daniel Jacobowitz Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 12+ messages in thread
* Using binutils-2.12.1 on sparc64-sun-solaris2.8 to build gcc-3.1 results in relocation errors
@ 2002-07-15 8:24 Dana, Eric
0 siblings, 0 replies; 12+ messages in thread
From: Dana, Eric @ 2002-07-15 8:24 UTC (permalink / raw)
To: 'binutils@sources.redhat.com', 'gcc-bugs@gcc.gnu.org'
When building some of our 64-bit libraries in C++, we are seeing
R_SPARC_DISP32 errors:
../../../obj/sun/sparc-solaris2.7W/monitor/lib/Agent/libAgent.a(alert.o):iti
merspec/alert.C:37:
relocation truncated to fit: R_SPARC_DISP32
.gnu.linkonce.t._ZN10printClass5printEiPKc
../../../obj/sun/sparc-solaris2.7W/monitor/lib/Agent/libAgent.a(alert.o):iti
merspec/alert.C:37:
relocation truncated to fit: R_SPARC_DISP32
.gnu.linkonce.t._ZN10printClass6indentEi
../../../obj/sun/sparc-solaris2.7W/monitor/lib/Agent/libAgent.a(agentConditi
on.o):itimerspec/agentCondition.C:50:
relocation truncated to fit: R_SPARC_DISP32
.gnu.linkonce.t._ZN10printClass5printEiPKcm
and many, many more...
This happens on Solaris 2.7/2.8 when linking 64-bit objects.
Below is a reference from another developer (taken from the binutils
archives)
2002-05/msg01920.html
At this time we have no workaround. Can a previous version of binutils be
used on Solaris with 64-bit linking
with GCC 3.1 or later?
--Eric Dana--
BMC Software Inc.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Using binutils-2.12.1 on sparc64-sun-solaris2.8 to build gcc-3.1 results in relocation errors
@ 2002-05-28 7:50 Brad Spencer
2002-07-29 20:53 ` Daniel Jacobowitz
0 siblings, 1 reply; 12+ messages in thread
From: Brad Spencer @ 2002-05-28 7:50 UTC (permalink / raw)
To: binutils
I've looked through the archives and the comments in gcc-3.1, and it
looks like this might be some sort of new feature that doesn't quite
work correctly. If I configure gcc-3.1 on top of binutils-2.12.1,
then when I link 64-bit objects, I get things to the effect of
netra-map1:~$ g++ -Wall -m64 -o foo foo.cc -save-temps
/opt/gcc-3.1/lib/gcc-lib/sparc-sun-solaris2.8/3.1/../../../sparcv9/libstdc++.a(stl-inst.o)(.eh_frame+0xf0):
relocation truncated to fit: R_SPARC_DISP32
.gnu.linkonce.t._ZNSt24__default_alloc_templateILb1ELi0EE8allocateEm
This is totally a Hello World application:
static const char *st_ID __attribute__((unused)) =
"$Id$";
#include <iostream>
int
main()
{
std::cout << "hello world" << std::endl;
return 0;
}
When I configure gcc-3.1 on top of binutils-2.11.2, this doesn't
happen.
netra-map1:~$ g++ -m64 -Wall -o foo foo.cc -save-temps
netra-map1:~$ ./foo
hello world
Inside gcc-3.1/gcc/config/sparc/sparc.h, I find the following
comment:
/* [...]
binutils 2.12 would emit a R_SPARC_DISP32 dynamic relocation if the
symbol %r_disp32() is against was not local, but .hidden. In that
case, we have to use DW_EH_PE_absptr for pic personality. */
From what I can tell from this mailing list, the %r_dispX notation is
a new feature in gas. Is this a bug?
netra-map1:~$ gcc -v
Reading specs from
/opt/gcc-3.1/lib/gcc-lib/sparc-sun-solaris2.8/3.1/specs
Configured with: ../gcc-3.1/configure --with-dwarf2
--enable-languages=c,c++ --enable-threads=single --disable-shared
--with-gnu-as --with-gnu-ld --with-as=/opt/bin/as
--with-ld=/opt/bin/ld --prefix=/opt/gcc-3.1
Thread model: single
gcc version 3.1
netra-map1:~$ gcc -print-prog-name=as
/opt/bin/as
netra-map1:~$ /opt/bin/as --version
GNU assembler 2.11.2
netra-map1:~$ gcc -print-prog-name=ld
/opt/bin/ld
netra-map1:~$ /opt/bin/ld --version
GNU ld 2.11.2
Copyright 2001 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms
of
the GNU General Public License. This program has absolutely no
warranty.
Supported emulations:
elf32_sparc
elf64_sparc
--
-----------------------------------------------------------------
Brad Spencer - spencer@infointeractive.com - "It's quite nice..."
Systems Architect | InfoInterActive Corp. | An AOL Company
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2002-07-30 12:05 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-07-15 10:46 Using binutils-2.12.1 on sparc64-sun-solaris2.8 to build gcc-3.1 results in relocation errors Dana, Eric
2002-07-15 19:56 ` Alan Modra
2002-07-16 0:14 ` David S. Miller
2002-07-17 10:54 ` Teemu Torma
2002-07-17 18:32 ` Alan Modra
2002-07-17 20:20 ` David S. Miller
2002-07-18 8:17 ` Teemu Torma
2002-07-18 0:45 ` Jakub Jelinek
-- strict thread matches above, loose matches on Subject: below --
2002-07-15 8:24 Dana, Eric
2002-05-28 7:50 Brad Spencer
2002-07-29 20:53 ` Daniel Jacobowitz
2002-07-30 5:22 ` Brad Spencer
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).