b...@gmx.net writes:
>> The difference in the output appears to be in the strings. This
>> suggests that your compilers are behaving differently than I expect with
>> respect to references to entries in string merge sections. Can you send
>> me just the file TestClass.o? That might be enough fo
We have an issue where a nonPIC binary that is
* calling a function in a shared object
* calling another function in a shared object, which references the address of
the first function, saving it as a function pointer.
* later, calling yet another function (in a shared object) which invokes the
Dear gold developers,
Dear Ian,
Being very happy when I read about the new fast linker, I tried to use it on
the package I'm working with (1050229 lines C++, 649866 lines Fortran 90),
together with our preferred toolchain of the Intel C++ and Fortran compiler.
For the linking step itself, I n
tuebened...@yahoo.de writes:
> Not being a linking expert, I assume the object code of fortran
> subroutines is compatible to objects derived from C code. Am I wrong?
Yes, the object code should be compatible.
> ===
> And now for the details: You will fin
--- Additional Comments From niki dot waibel at gmx dot net 2009-03-24
16:37 ---
i meant to say:
===
"ar xv" either fails to extract archives (most cases, error message: "... is not
a valid archive") on i386-pc-solaris2.10 / sparc-sun-solaris2.10;
or extracts with wrong permissions and
--- Additional Comments From niki dot waibel at gmx dot net 2009-03-24
15:00 ---
Created an attachment (id=3841)
--> (http://sourceware.org/bugzilla/attachment.cgi?id=3841&action=view)
contains files referenced in this report
--
http://sourceware.org/bugzilla/show_bug.cgi?id=9992
binutils-2.19.51.0.3.20090310
gcc-4.3.3
tested on i386-pc-solaris2.10, sparc-sun-solaris2.10, x86_64-unknown-linux-gnu:
===
x86_64-unknown-linux-gnu $ uname -a
Linux amdlnx-2 2.4.21-58.ELsmp #1 SMP Tue Nov 4 11:38:48 EST 2008 x86_64
GNU/Linux
===
i386-pc-solaris2.10 $ uname -a
SunOS amdsol-1 5.10
