http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50149
--- Comment #3 from Behzad Salimi <riddle00 at gmail dot com> 2011-09-02 22:34:27 UTC --- Hello, Thank you very much for your reply and help. Your example pointed me to the clue to find the error in my source: evidently, a /name/ block is required even when the "name" is empty, i.e., "common // ...", my source had "common i, j, k, ..." this is not allowed! What is surprising is that no compiler error or warning was generated while the loader complained! I had expected to get a compiler error if the "common /name/ ..." format is strictly required. Perhaps you could make a note to cause a compiler error in your future distributions. Problem is solved and I thank you very much for your assistance. You can delete my original bug report as resolved and perhaps mark it as a remark for a future compiler improvement. Take care, Behzad. On Mon, Aug 22, 2011 at 6:38 AM, burnus at gcc dot gnu.org <gcc-bugzi...@gcc.gnu.org> wrote: > 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 > > -- > Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You reported the bug. >
