[Bug c++/54155] Newly compiled GCC 4.4.4 on Solaris sparc gives problem with -m32/-m64 flags
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54155 --- Comment #7 from damz 2012-08-08 17:40:37 UTC --- (In reply to comment #5) > > --- Comment #4 from Eric Botcazou 2012-08-02 > > 15:17:25 UTC --- > > >> If I replace only the ld from GNU Binutils 2.21.x with the ld from 2.20.x > >> then > >> the compilation is successful with -m32/-m64. > > Replacing the linker (or assembler) used at gcc configure time with a > different one at runtime is not supported: the configure process > determines several linker features and hardcodes the result into the > compiler built. > > >> Is this a bug in the GNU ld 2.21.x? > > No, but gcc 4.4.4 doesn't support gld 2.21. That version introduced the > elf*_sparc_sol2 linker emulations, and this is only handled by gcc 4.4.5 > and newer. Please note that both gcc 4.4 and 4.5 are ancient history by > now and not supported any longer. > > > Certainly there is a mismatch between the compiler and the linker, and the > > linker now rejecting elf32_sparc is unexpected. > > > > Rainer, is that a known issue? > > In a way, yes, see above. > > Rainer Thanks so much for the clarification! :) How I wish that the supportability matrix was published. Did I miss to see a document saying that ld 2.21 will not be supported by GCC 4.4.4 and below? :( I was hoping that backward compatibility was mostly retained!
[Bug c++/54155] Newly compiled GCC 4.4.4 on Solaris sparc gives problem with -m32/-m64 flags
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54155 --- Comment #9 from damz 2012-08-09 12:02:42 UTC --- (In reply to comment #8) > > --- Comment #7 from damz 2012-08-08 17:40:37 UTC > > --- > > > How I wish that the supportability matrix was published. > > I hope you understand that this is completely unfeasible: I'm currently > testing gcc 4.6/4.7/4.8 on Solaris 8/9/10/11, both sparc and x86. > Adding older gcc releases (which are no longer maintained anyway) and > more than one (the current) binutils release to that testing simply > cannot be done in reasonable time, with finite amounts of diskspace, and > man power to analyse the results. > > > Did I miss to see a document saying that ld 2.21 will not be supported by > > GCC > > 4.4.4 and below? :( > > No, but in general (which is not yet true for gcc 4.4) I try to list the > latest binutils version known to work with that version of gcc. With > newer binutils releases, you're on your own. They may well work, but no > guarantees. > > > I was hoping that backward compatibility was mostly retained! > > Agreed, but as I said when I found that gcc 4.4 doesn't work with gld > 2.21, I immediately backported the patch to that release branch. > > Rainer Thank you Rainer. I really appreciate your transparent replies. Cheers! signing off damz
[Bug c++/54155] New: Newly compiled GCC 4.4.4 on Solaris sparc gives problem with -m32/-m64 flags
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54155
Bug #: 54155
Summary: Newly compiled GCC 4.4.4 on Solaris sparc gives
problem with -m32/-m64 flags
Classification: Unclassified
Product: gcc
Version: 4.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dsha...@gmail.com
This issue has kept me busy all day long. It started off with openssl
compilation which was giving linking error with following message:
/usr/local/bin/ld: target elf32-sparc not found
collect2: ld returned 1 exit status
I tried every step possible thing that I could think of but was not able to
resolve the issue. Although I came to know that specifying -m32/-m64 flag with
my newly built gcc has started reporting this issue. I have tried to provide
all necessary details below including the test program which when I try to
compile gives the same issue.
Note: I am using GNU binaries(bintuils 2.21)
#
bash-3.2# uname -a
SunOS CSAPI-DEV-SOL3 5.10 Generic_147440-01 sun4u sparc SUNW,Sun-Fire-V240
#
bash-3.2# gcc -v
Using built-in specs.
Target: sparc-sun-solaris2.10
Configured with: ../gcc-4.4.4/configure --prefix=/usr/local/gcc-4.4.4
--program-suffix=-4.4.4 --enable-threads=posix --enable-shared
--enable-languages=c,c++ --with-gnu-as --with-as=/usr/local/bin/as
--with-gnu-ld --with-ld=/usr/local/bin/ld
Thread model: posix
gcc version 4.4.4 (GCC)
#
Content of test.cpp
#include
int main()
{
std::cout<< "hello world\n";
}
#
/*** COMPILATION OUTPUT ***/
bash-3.2# gcc -o test1 test.cpp -m32 -mcpu=ultrasparc -lstdc++
/usr/local/bin/ld: target elf32-sparc not found
collect2: ld returned 1 exit status
#
If I eliminate the -m32/-m64 flag output file is successfully generated.
#
bash-3.2# file test1
test1: ELF 32-bit MSB executable SPARC32PLUS Version 1, V8+ Required,
dynamically linked, not stripped
#
Is it something that has gone wrong during configuration due to which the
compiler does not recognize the -m option?
Please help!
[Bug c++/54155] Newly compiled GCC 4.4.4 on Solaris sparc gives problem with -m32/-m64 flags
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54155 --- Comment #2 from damz 2012-08-02 10:02:46 UTC --- (In reply to comment #1) > > /*** COMPILATION OUTPUT ***/ > > bash-3.2# gcc -o test1 test.cpp -m32 -mcpu=ultrasparc -lstdc++ > > /usr/local/bin/ld: target elf32-sparc not found > > collect2: ld returned 1 exit status > > # > > > > If I eliminate the -m32/-m64 flag output file is successfully generated. > > # > > bash-3.2# file test1 > > test1: ELF 32-bit MSB executable SPARC32PLUS Version 1, V8+ Required, > > dynamically linked, not stripped > > # > > > > Is it something that has gone wrong during configuration due to which the > > compiler does not recognize the -m option? > > Rather strange indeed. What does `/usr/local/bin/ld -V' report? > > Could you compare the command line passed to collect2 w/ and w/o the -m32 > flag? > You need to add -v on the link line to have it printed. Output of ld -V is as follows: bash-3.2# /usr/local/bin/ld -V GNU ld (GNU Binutils) 2.21.1 Supported emulations: elf32_sparc_sol2 elf32_sparc elf64_sparc_sol2 elf64_sparc Collect options passed are as follows: Without -m32: COLLECT_GCC_OPTIONS='-o' 'test' '-v' '-shared-libgcc' '-mcpu=v9' With -m32: COLLECT_GCC_OPTIONS='-o' 'test' '-m32' '-v' '-shared-libgcc' '-mcpu=v9' Without -m32: collect2 -V -Y P,/usr/ccs/lib:/usr/lib -rpath-link... With -m32: collect2 -V -m elf32_sparc -Y P,/usr/ccs/lib:/usr/lib -rpath-link Note: On another machine where the output of ld -V is as follows, gcc 4.4.4 is able to compile successfully with the -m32/-m64 options bash-3.00# /usr/local/bin/ld -V GNU ld (GNU Binutils) 2.20.1.20100303 Supported emulations: elf32_sparc elf64_sparc bash-3.00# If I replace only the ld from GNU Binutils 2.21.x with the ld from 2.20.x then the compilation is successful with -m32/-m64. Is this a bug in the GNU ld 2.21.x? I read the following link (http://archives.gentoo.org/gentoo-alt/msg_a4641a1c17ce5f66a05c6440dd5cfc87.xml) which suggests a solution to the problem but it did not help me. I ran the following command but no change in behavior when i use ld from gnu binutils 2.21.x sed -i -e 's/^OUTPUT_FORMAT ( elf32-sparc )$/OUTPUT_FORMAT ( elf32-sparc-sol2 )/' $EPREFIX/usr/lib/lib*.so Please help. Thanks, damz
[Bug c++/54155] Newly compiled GCC 4.4.4 on Solaris sparc gives problem with -m32/-m64 flags
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54155 --- Comment #3 from damz 2012-08-02 10:08:44 UTC --- Note: My gcc libraries are available at the /usr/local/gcc-4.4.4/lib whereas I ran the sed command on usr/lib/lib*.so
