home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.lang.fortran      Putting John Backus on a giant pedestal      5,127 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 4,894 of 5,127   
   Thomas Koenig to Lynn McGuire   
   Re: nasty link problem with Gfortran and   
   08 Jan 25 09:37:22   
   
   From: tkoenig@netcologne.de   
      
   Lynn McGuire  schrieb:   
   > On 1/7/2025 4:18 PM, Thomas Koenig wrote:   
   >> Lynn McGuire  schrieb:   
   >>> I just ran into a nasty problem with GFortran and G++ (C++).  Probably   
   >>> not a bug ???  I am using GCC 14.1.   
   >>>   
   >>> I have a lot of code in C++ (over 100,000 lines).  I have 750,000 lines   
   >>> of code in GFortran.  I have to extern "C" this code in C++ to make it   
   >>> callable by GFortran code.   
   >>>   
   >>> I missed declaring a couple of C++ functions as extern "C" which means   
   >>> that they kept their C++ mangled link names.  But these C++ functions   
   >>> were declared as integer*8 and external in the GFortran code (old F77   
   >>> code).   
   >>>   
   >>> So, the GCC linker did not report to me that it did not have a link for   
   >>> the G++ functions.  This may be a bug, I am not sure.   
   >>   
   >> Without having looked at the source code, I suspect   
   >> it is probably something that you are not describing.   
   >>   
   >> You can look into the object files with any number of utilities,   
   >> for example "nm".  Here's an example:   
   >>   
   >> subroutine foo   
   >>    external bar   
   >>    integer *8 bar   
   >>    print *,bar(1234)   
   >> end subroutine foo   
   >>   
   >> Compiling to an object file and running nm on this will show you   
   >>   
   >>                   U bar_   
   >> 0000000000000000 T foo_   
   >>                   U _gfortran_st_write   
   >>                   U _gfortran_st_write_done   
   >>                   U _gfortran_transfer_integer_write   
   >>   
   >> which means you have a symbol "foo_" defined, it is a global (hence   
   >> uppercase) symbol in the text section (hence T).  You also have   
   >> several undefined symbols, among them bar_, plus some gfortran   
   >> library routines, so all is fine.   
   >>   
   >> If you do not find your undefined   
   >>> When I ran the program, the C++ functions were not called by the   
   >>> GFortran code.  Instead, the GFortran code treated the C++ functions as   
   >>> integer*8 scalar variables.   
   >>   
   >>>   
   >>> If needful, I can probably put together a small code sample that   
   >>> exhibits the problem.  Maybe.  It could be that the size of my code   
   >>> affects the GCC linker.   
   >>   
   >> That I would consider highly unlikely.   
   >   
   > I turn off the trailing underscores in the Fortran code.  I build Win32   
   > DLLs that are Excel VBA, C++, and Fortran callable.   
      
   Just wondering... have you read the relevant gfortran documentation   
   regarding naming conventions and the attributes directive?   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca