It works perfecty with --no-relax inside my Makefiles Thanks a lot Luc Uwe Schindler wrote: Thats a known problem with binutils on alpha. The ld process finishes always (so no infinite loop) but it takes 100x so long than normal for C++ programs. The problem is described in the bug report at debain and at sourceware.org: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=334766 http://sourceware.org/bugzilla/show_bug.cgi?id=1543 As a fine temporary workaround is to use --no-relax when linking (a patch could be to make --no-relax a default option on alpha!): use ld --no-relax, or pass compiler with -Wl,--no-relax or patch --no-relax to default / --relax as optional and everything turn to be fine after :-) firefox links in /layout now in 11 minutes instead of 4:30 hour, and anyway i think we could live without relax. I bootstrapped to alphacore [fedora-devel] this way with latest CVS pool of glibc/gcc-4.1.2/binutils and everything seems fine. ----- Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: uwe@thetaphi.de-----Original Message----- From: Luc Papeleux [mailto:L.Papeleux@ulg.ac.be] Sent: Tuesday, April 17, 2007 11:58 AM To: debian-alpha@lists.debian.org Subject: infinite loop in ld Hi, Since I updated a compaq XP1000 (alpha EV6) from sarge to etch my large c++ program (650 objects + dynamicaly linked libraries) does not link anymore : building objects last 3 to 4 hours (on each distribution) linking dynamic libraries (.so) is ok on each distribution ld that lasted less than 20seconds on Sarge (GNU ld version 2.15) run for 2 hours on Etch with no results (GNU ld version 2.17 Debian GNU/Linux) I attached ld process inside ddd and stopped it at several time and it seemed to spend a lot of time inside : bfd_elf64_archive_slurp_armap () (se output of gdb below - is this significant) small c++ programs (1-2 files) compiles and link without problems (i am unable to reproduce the problem with small examples) Does someone have an idea how to solve the problem (or which information could help to reproduce the problem) Thanks in advance Luc ==================================================================== Versions of installed packages (everythin is (normaly) up to date to Etch) gcc : gcc (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) ld : GNU ld version 2.17 Debian GNU/Linux kernel : 2.6.18-4-alpha-generic Sarge : compile & link OK gcc : 3.3.6 (home compilation) ld : GNU ld version 2.15 kernel : 2.4.27-2-generic Sarge altenative configuration : compile & link OK gcc : 4.1.1 (home compilation) ld : GNU ld version 2.15 kernel : 2.6.8-2-generic ========================================================================== = Copyright C 2001-2004 Free Software Foundation, Inc. (gdb) file /usr/bin/ld (no debugging symbols found) Using host libthread_db library "/lib/libthread_db.so.1". (gdb) attach 8211 (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) 0x00000200000709c8 in bfd_elf64_archive_slurp_armap () from /usr/lib/libbfd-2.17.so (gdb) where #0 0x00000200000709c8 in bfd_elf64_archive_slurp_armap () from /usr/lib/libbfd-2.17.so #1 0x000002000005d328 in bfd_hash_traverse () from /usr/lib/libbfd- 2.17.so #2 0x000002000005e4c8 in bfd_link_hash_traverse () from /usr/lib/libbfd-2.17.so #3 0x0000020000072abc in bfd_elf64_archive_slurp_armap () from /usr/lib/libbfd-2.17.so #4 0x0000020000075294 in bfd_elf64_archive_slurp_armap () from /usr/lib/libbfd-2.17.so #5 0x0000000120013fd4 in ?? () #6 0x0000000120013ae0 in ?? () #7 0x0000000120013cc4 in ?? () #8 0x00000001200144b8 in ?? () #9 0x0000000120014714 in ?? () #10 0x0000000120017b18 in ?? () #11 0x000000012001cb20 in ?? () #12 0x0000020000101048 in __libc_start_main () from /lib/libc.so.6.1 #13 0x0000000120003f78 in ?? () (gdb) Program received signal SIGINT, Interrupt. 0x000002000008a6c4 in _bfd_elf_dynamic_symbol_p () from /usr/lib/libbfd-2.17.so (gdb) where #0 0x000002000008a6c4 in _bfd_elf_dynamic_symbol_p () from /usr/lib/libbfd-2.17.so #1 0x0000020000078490 in bfd_elf64_archive_slurp_armap () from /usr/lib/libbfd-2.17.so #2 0x000002000005d328 in bfd_hash_traverse () from /usr/lib/libbfd- 2.17.so #3 0x000002000005e4c8 in bfd_link_hash_traverse () from /usr/lib/libbfd-2.17.so #4 0x00000200000729f8 in bfd_elf64_archive_slurp_armap () from /usr/lib/libbfd-2.17.so #5 0x00000200000759f4 in bfd_elf64_archive_slurp_armap () from /usr/lib/libbfd-2.17.so #6 0x0000000120013fd4 in ?? () #7 0x0000000120013ae0 in ?? () #8 0x0000000120013cc4 in ?? () #9 0x00000001200144b8 in ?? () #10 0x0000000120014714 in ?? () #11 0x0000000120017b18 in ?? () #12 0x000000012001cb20 in ?? () #13 0x0000020000101048 in __libc_start_main () from /lib/libc.so.6.1 #14 0x0000000120003f78 in ?? () Previous frame inner to this frame (corrupt stack?) (gdb) Program received signal SIGINT, Interrupt. 0x00000200000784c4 in bfd_elf64_archive_slurp_armap () from /usr/lib/libbfd-2.17.so (gdb) where #0 0x00000200000784c4 in bfd_elf64_archive_slurp_armap () from /usr/lib/libbfd-2.17.so #1 0x000002000005d328 in bfd_hash_traverse () from /usr/lib/libbfd- 2.17.so #2 0x000002000005e4c8 in bfd_link_hash_traverse () from /usr/lib/libbfd-2.17.so #3 0x00000200000729f8 in bfd_elf64_archive_slurp_armap () from /usr/lib/libbfd-2.17.so #4 0x00000200000759f4 in bfd_elf64_archive_slurp_armap () from /usr/lib/libbfd-2.17.so #5 0x0000000120013fd4 in ?? () #6 0x0000000120013ae0 in ?? () #7 0x0000000120013cc4 in ?? () #8 0x00000001200144b8 in ?? () #9 0x0000000120014714 in ?? () #10 0x0000000120017b18 in ?? () #11 0x000000012001cb20 in ?? () #12 0x0000020000101048 in __libc_start_main () from /lib/libc.so.6.1 #13 0x0000000120003f78 in ?? () Previous frame inner to this frame (corrupt stack?) (gdb) (gdb) c ^C Program received signal SIGINT, Interrupt. 0x000002000007842c in bfd_elf64_archive_slurp_armap () from /usr/lib/libbfd-2.17.so (gdb) where #0 0x000002000007842c in bfd_elf64_archive_slurp_armap () from /usr/lib/libbfd-2.17.so #1 0x000002000005d328 in bfd_hash_traverse () from /usr/lib/libbfd- 2.17.so #2 0x000002000005d328 in bfd_hash_traverse () from /usr/lib/libbfd- 2.17.so #3 0x0000000128629240 in ?? () warning: Hit heuristic-fence-post without finding enclosing function for address 0x128629240 This warning occurs if you are debugging a function without any symbols (for example, in a stripped executable). In that case, you may wish to increase the size of the search with the `set heuristic-fence-post' command. Otherwise, you told GDB there was a function where there isn't one, or (more likely) you have encountered a bug in GDB. #4 0x0000000128629240 in ?? () warning: Hit heuristic-fence-post without finding enclosing function for address 0x128629240 Previous frame identical to this frame (corrupt stack?) (gdb) -- To UNSUBSCRIBE, email to debian-alpha-REQUEST@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org -- ________________________________________________________________ Luc Papeleux Ingenieur de Recherche Universite de Liege - Departement ASMA LTAS-Thermomecanique & Milieux Continus Campus Universitaire du Sart-Tilman Institut de Mecanique (Bat B52/3 - local +2/540) Chemin des chevreuils, 1 B-4000 LIEGE 1, BELGIUM Tel: +32-(0)4-366.91.49 Fax: +32-(0)4-366.91.41 Email : L.Papeleux@ulg.ac.be WWW : http://www.ulg.ac.be/ltas-mct/index.html ________________________________________________________________ |