From: lynnmcguire5@gmail.com   
      
   On 1/8/2025 3:37 AM, Thomas Koenig wrote:   
   > 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?   
      
   About three times now.  Still makes my head spin.   
      
   All of this F77 / C++ code was working with the Watcom F77 / C++ PCDOS /   
   Win32 compilers for the last 32+ years and over 2,000 commercial users.   
   The port has been the worst port ever.  But I blame that on the old   
   Fortran code dating back to 1965 (Fortran II !!!).  I have ported the   
   Fortran code to twelve different platforms over the years (mainframes,   
   various Unix boxen, Vax VMS, Prime, PC DOS, Win32).   
      
   I was porting for the third attempt to the Intel Fortran / Visual C++   
   compilers and they obsoleted the Intel Fortran compiler on me about   
   three months ago.  I am not going to port to an obsolete compiler.  The   
   first two attempts in 2002 ? and 2010 ? to port to Intel Fortran ran   
   into compiler bugs (crashed the linker table at 300,000 entries, the   
   vector automatic zeroing code had a serious bug).   
      
   Lynn   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)