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