This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug fortran/50149] loader error with source containing common blocks
- From: "burnus at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Mon, 22 Aug 2011 13:38:45 +0000
- Subject: [Bug fortran/50149] loader error with source containing common blocks
- Auto-submitted: auto-generated
- References: <bug-50149-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50149
Tobias Burnus <burnus at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |burnus at gcc dot gnu.org
--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> 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