| Deutsch English Français Italiano |
|
<vlmoel$2v1ap$1@dont-email.me> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: Lynn McGuire <lynnmcguire5@gmail.com> Newsgroups: comp.lang.fortran Subject: Re: nasty link problem with Gfortran and G++ (C++) ??? Date: Wed, 8 Jan 2025 14:50:29 -0600 Organization: A noiseless patient Spider Lines: 80 Message-ID: <vlmoel$2v1ap$1@dont-email.me> References: <vlk6nb$2cmk4$1@dont-email.me> <vlk97b$2d9j6$2@dont-email.me> <vlkfle$2eh7o$2@dont-email.me> <vllh0i$2ngh9$1@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Wed, 08 Jan 2025 21:50:30 +0100 (CET) Injection-Info: dont-email.me; posting-host="6a30793f1ee6b5ff293e246ca497dcd3"; logging-data="3114329"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX191+fGyg8SiKsOB8IP/0CH2eUarMcdcHrQ=" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:awKb5XjcBlktf3B8rlhiuoU2xWk= In-Reply-To: <vllh0i$2ngh9$1@dont-email.me> Content-Language: en-US Bytes: 4560 On 1/8/2025 3:37 AM, Thomas Koenig wrote: > Lynn McGuire <lynnmcguire5@gmail.com> schrieb: >> On 1/7/2025 4:18 PM, Thomas Koenig wrote: >>> Lynn McGuire <lynnmcguire5@gmail.com> 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