From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17550 invoked by alias); 22 Aug 2011 13:39:05 -0000 Received: (qmail 17492 invoked by uid 22791); 22 Aug 2011 13:39:04 -0000 X-SWARE-Spam-Status: No, hits=-2.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 22 Aug 2011 13:38:51 +0000 From: "burnus at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/50149] loader error with source containing common blocks Date: Mon, 22 Aug 2011 13:52:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Keywords: X-Bugzilla-Severity: major X-Bugzilla-Who: burnus at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: CC Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2011-08/txt/msg01842.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50149 Tobias Burnus changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus 2011-08-22 13:38:45 UTC --- (In reply to comment #0) > System Version: Mac OS X 10.6.8 (10K549), Kernel Version: Darwin 10.8.0 > gcc/gfortran version 4.6.1 > > ld: duplicate symbol ___BLNK__ in obj/trajectory.o and obj/integral.o > collect2: ld returned 1 exit status As written, I cannot reproduce the problem on Linux. Can you create a minimal example which reproduces this error and attach it, stating exactly the command-line options you used? For instance, the following example works for me on Linux with no special options and with the options you used. As expected, I get in the object files the blank common ("common // ..."), namely "nm" shows the __BLNK__ symbol in both files: 0000000000000008 C __BLNK__ However, as the "C" indicates, the data is in common and thus should not produce any error message if it exists in multiple object files. What do you get if you run "nm obj/trajectory.o |grep __BLNK__" and "nm obj/integral.o |grep __BLNK__"? ! --------- file1.f90 --------- subroutine foo integer :: i common // i end subroutine foo ! --------- file2.f90 --------- subroutine bar integer :: j common // j end subroutine bar call foo() call bar() end