nasty link problem with Gfortran and G++ (C++) ???

[Lynn McGuire]

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.

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.

I removed the Gfortran code "external" keywords, extern "C" the C++
functions, added the C++ function to my module list, and got a working link.

Thanks,
Lynn

[Thomas Koenig]

Post by Lynn McGuire
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

Post by Lynn McGuire
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.

[Lynn McGuire]

Post by Thomas Koenig

Post by Lynn McGuire
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,
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

Post by Lynn McGuire
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.

I will try to build a sample code on Wednesday that illustrates the problem.

Thanks,
Lynn

[Thomas Koenig]

Post by Lynn McGuire

Post by Thomas Koenig

Post by Lynn McGuire
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,
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

Post by Lynn McGuire
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?

[Lynn McGuire]

Post by Thomas Koenig

Post by Lynn McGuire

Post by Thomas Koenig

Post by Lynn McGuire
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,
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

Post by Lynn McGuire
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

[Thomas Koenig]

Post by Lynn McGuire

Post by Thomas Koenig
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.

If there's something in there that you do not understand, do
not hesitate to ask :-)

Post by Lynn McGuire
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 !!!).

That is OLD. The oldest Fortran I ever had contact with was
of Fortran 66-vintage.

Post by Lynn McGuire
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.

They obsoleted the non-LLVM version? I hadn't heard that.

Post by Lynn McGuire
I am not going to port to an obsolete compiler.

Wise decision.

Post by Lynn McGuire
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).

Fingers crossed, that should not be a problem... anything that can
compile and link Firefox should be able to handle just about
anything.

[Steven G. Kargl]

Post by Thomas Koenig

Post by Lynn McGuire
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.

They obsoleted the non-LLVM version? I hadn't heard that.

Yes, ifort is EOL.

https://community.intel.com/t5/Blogs/Tech-Innovation/Tools/Deprecation-of-
The-Intel-Fortran-Compiler-Classic-ifort/post/1541699

[Lynn McGuire]

Post by Thomas Koenig

Post by Lynn McGuire
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,
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

Post by Lynn McGuire
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 cannot get a small code sample with or without a DLL to exhibit the
problem. Like I said, I thought it was something related to size of my
DLL. And this is the small DLL, only 3 MB.

Thanks,
Lynn

[Thomas Koenig]

Post by Lynn McGuire
I cannot get a small code sample with or without a DLL to exhibit the
problem. Like I said, I thought it was something related to size of my
DLL. And this is the small DLL, only 3 MB.

Regarding DLLs, I'm out... I don't think I have ever done one.

Which toolchain are you using? Msys/mingw64 is probably the
preferred one. (Personally, I use cygwin for Windows stuff (with
the mingw64 cross compiler), but that is because I like the
UNIXy look and feel of cygwin.)

Did you look at the symbols that can be found in the respective
DLLs, do they match your expectations? (I presume you follow

https://stackoverflow.com/questions/48021991/creating-dll-with-gfortran-on-windows

).

[Lynn McGuire]

Post by Thomas Koenig

Post by Lynn McGuire
I cannot get a small code sample with or without a DLL to exhibit the
problem. Like I said, I thought it was something related to size of my
DLL. And this is the small DLL, only 3 MB.

Regarding DLLs, I'm out... I don't think I have ever done one.
Which toolchain are you using? Msys/mingw64 is probably the
preferred one. (Personally, I use cygwin for Windows stuff (with
the mingw64 cross compiler), but that is because I like the
UNIXy look and feel of cygwin.)
Did you look at the symbols that can be found in the respective
DLLs, do they match your expectations? (I presume you follow
https://stackoverflow.com/questions/48021991/creating-dll-with-gfortran-on-windows
).

For compilers and IDE, I am using GCC 14.1 that is in Simply Fortran 3.38.
https://simplyfortran.com/

For Unix utilities on Windows, I use the old Thompson Toolkit from 1987
that had the grep written in assembly language for SPEED. Finding code
in 5,000+ subroutines across 60+ subdirectories requires SPEED.
http://www.tasoft.com/toolkit.html

Thanks,
Lynn

[Thomas Koenig]

Post by Lynn McGuire

Post by Thomas Koenig

Post by Lynn McGuire
I cannot get a small code sample with or without a DLL to exhibit the
problem. Like I said, I thought it was something related to size of my
DLL. And this is the small DLL, only 3 MB.

Regarding DLLs, I'm out... I don't think I have ever done one.
Which toolchain are you using? Msys/mingw64 is probably the
preferred one. (Personally, I use cygwin for Windows stuff (with
the mingw64 cross compiler), but that is because I like the
UNIXy look and feel of cygwin.)
Did you look at the symbols that can be found in the respective
DLLs, do they match your expectations? (I presume you follow
https://stackoverflow.com/questions/48021991/creating-dll-with-gfortran-on-windows
).

For compilers and IDE, I am using GCC 14.1 that is in Simply Fortran 3.38.
https://simplyfortran.com/

Hm, OK. I'm not familiar with how Simply Fortran operates; they do
not cooperate with the gfortran team (but rather make money off the
work of volunteers). If you have questions regarding teir toolbox,
this is best addressed to them.

Post by Lynn McGuire
For Unix utilities on Windows, I use the old Thompson Toolkit from 1987
that had the grep written in assembly language for SPEED. Finding code
in 5,000+ subroutines across 60+ subdirectories requires SPEED.
http://www.tasoft.com/toolkit.html

Do you have a working nm? If not, debugging this will be pretty
much impossible.

[Lynn McGuire]

Post by Thomas Koenig

Post by Lynn McGuire

Post by Thomas Koenig

Post by Lynn McGuire
I cannot get a small code sample with or without a DLL to exhibit the
problem. Like I said, I thought it was something related to size of my
DLL. And this is the small DLL, only 3 MB.

Regarding DLLs, I'm out... I don't think I have ever done one.
Which toolchain are you using? Msys/mingw64 is probably the
preferred one. (Personally, I use cygwin for Windows stuff (with
the mingw64 cross compiler), but that is because I like the
UNIXy look and feel of cygwin.)
Did you look at the symbols that can be found in the respective
DLLs, do they match your expectations? (I presume you follow
https://stackoverflow.com/questions/48021991/creating-dll-with-gfortran-on-windows
).

For compilers and IDE, I am using GCC 14.1 that is in Simply Fortran 3.38.
https://simplyfortran.com/

Hm, OK. I'm not familiar with how Simply Fortran operates; they do
not cooperate with the gfortran team (but rather make money off the
work of volunteers). If you have questions regarding teir toolbox,
this is best addressed to them.

Post by Lynn McGuire
For Unix utilities on Windows, I use the old Thompson Toolkit from 1987
that had the grep written in assembly language for SPEED. Finding code
in 5,000+ subroutines across 60+ subdirectories requires SPEED.
http://www.tasoft.com/toolkit.html

Do you have a working nm? If not, debugging this will be pretty
much impossible.

Yes, I do. I am looking at the results right now. 35,932 lines of
stuff. I have confirmed that I am not using stdcall which may be wrong,
I am not sure yet. The Watcom F77, C, and C++ compilers used stdcall so
I am familiar with it.

Thanks,
Lynn

[Thomas Koenig]

Post by Lynn McGuire

Post by Thomas Koenig

Post by Lynn McGuire

Post by Thomas Koenig

Post by Lynn McGuire
I cannot get a small code sample with or without a DLL to exhibit the
problem. Like I said, I thought it was something related to size of my
DLL. And this is the small DLL, only 3 MB.

Regarding DLLs, I'm out... I don't think I have ever done one.
Which toolchain are you using? Msys/mingw64 is probably the
preferred one. (Personally, I use cygwin for Windows stuff (with
the mingw64 cross compiler), but that is because I like the
UNIXy look and feel of cygwin.)
Did you look at the symbols that can be found in the respective
DLLs, do they match your expectations? (I presume you follow
https://stackoverflow.com/questions/48021991/creating-dll-with-gfortran-on-windows
).

For compilers and IDE, I am using GCC 14.1 that is in Simply Fortran 3.38.
https://simplyfortran.com/

Hm, OK. I'm not familiar with how Simply Fortran operates; they do
not cooperate with the gfortran team (but rather make money off the
work of volunteers). If you have questions regarding teir toolbox,
this is best addressed to them.

Post by Lynn McGuire
For Unix utilities on Windows, I use the old Thompson Toolkit from 1987
that had the grep written in assembly language for SPEED. Finding code
in 5,000+ subroutines across 60+ subdirectories requires SPEED.
http://www.tasoft.com/toolkit.html

Do you have a working nm? If not, debugging this will be pretty
much impossible.

Yes, I do. I am looking at the results right now. 35,932 lines of
stuff. I have confirmed that I am not using stdcall which may be wrong,
I am not sure yet. The Watcom F77, C, and C++ compilers used stdcall so
I am familiar with it.

If you're trying to generate and use DLLs, you may want to look at

https://fortran-lang.org/en/learn/building_programs/managing_libraries/

which has some examples.

[baf]

Post by Thomas Koenig
Hm, OK. I'm not familiar with how Simply Fortran operates; they do
not cooperate with the gfortran team (but rather make money off the
work of volunteers). If you have questions regarding teir toolbox,
this is best addressed to them.

It is not strictly true that the Simply Fortran folks make money off the
work of volunteers. They do not charge for the use of gfortran. Anyone
can install their software for free, and that installation provides
gfortran (and friends) that can be accessed from the command line
without any license from Simply Fortran. What they do charge for is
their IDE.

[Lynn McGuire]

Post by baf

Hm, OK.   I'm not familiar with how Simply Fortran operates; they do
not cooperate with the gfortran team (but rather make money off the
work of volunteers). If you have questions regarding teir toolbox,
this is best addressed to them.

It is not strictly true that the Simply Fortran folks make money off the
work of volunteers. They do not charge for the use of gfortran. Anyone
can install their software for free, and that installation provides
gfortran (and friends) that can be accessed from the command line
without any license from Simply Fortran. What they do charge for is
their IDE.

+1

Lynn

[Steven G. Kargl]

Post by baf

Post by Thomas Koenig
Hm, OK. I'm not familiar with how Simply Fortran operates; they do
not cooperate with the gfortran team (but rather make money off the
work of volunteers). If you have questions regarding teir toolbox,
this is best addressed to them.

It is not strictly true that the Simply Fortran folks make money off the
work of volunteers. They do not charge for the use of gfortran. Anyone
can install their software for free, and that installation provides
gfortran (and friends) that can be accessed from the command line
without any license from Simply Fortran. What they do charge for is
their IDE.

I suppose that is one way to look at the situation. OTOH,
Simply Fortran would not exist if gfortran did not exist.
SF's homepage does not even bother to acknowledge that the
Fortran compiler is in fact gfortran. One does find on the
'Features' page: "Simply Fortran has been designed from the
start with GNU Fortran integration as the primary goal."
Additionally, there is no easily found information concerning
the actual version of GCC that comes with SF.

I suspect that Thomas's point is that the SF developer(s)
have not sent bug reports, patches to fix bugs, engaged
with any of gfortran's main contributors, or even said
"Thank you". Sure, the GPL does not require such behavior,
but the current lack of interaction appears to be somewhat
discourteous.

[baf]

Post by Steven G. Kargl

Post by baf

Post by Thomas Koenig
Hm, OK. I'm not familiar with how Simply Fortran operates; they do
not cooperate with the gfortran team (but rather make money off the
work of volunteers). If you have questions regarding teir toolbox,
this is best addressed to them.

It is not strictly true that the Simply Fortran folks make money off the
work of volunteers. They do not charge for the use of gfortran. Anyone
can install their software for free, and that installation provides
gfortran (and friends) that can be accessed from the command line
without any license from Simply Fortran. What they do charge for is
their IDE.

I suppose that is one way to look at the situation. OTOH,
Simply Fortran would not exist if gfortran did not exist.

That is probably true if no alternative Fortran compiler was available.
However, their IDE doesn't really depend that much a specific compiler,
and most of the operation could easily be used with any compiler that
had command line options.

Post by Steven G. Kargl
SF's homepage does not even bother to acknowledge that the
Fortran compiler is in fact gfortran. One does find on the
'Features' page: "Simply Fortran has been designed from the
start with GNU Fortran integration as the primary goal."
Additionally, there is no easily found information concerning
the actual version of GCC that comes with SF.

While it could be displayed more predominantly, they certainly don't
hide the version number they are distributing on their news page when
describing a new version of the IDE.

Post by Steven G. Kargl
I suspect that Thomas's point is that the SF developer(s)
have not sent bug reports, patches to fix bugs, engaged
with any of gfortran's main contributors, or even said
"Thank you". Sure, the GPL does not require such behavior,
but the current lack of interaction appears to be somewhat
discourteous.

I agree that they certainly could/should interact with the gfortran
developers. I know that they (it appears to be primarily a single person
operation) have put in a lot of effort to ensure that gfortran builds
correctly for windows, which based on my years of building the compiler
for Windows, is a horrible job.

[Steven G. Kargl]

Post by Lynn McGuire
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.
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.
I removed the Gfortran code "external" keywords, extern "C" the C++
functions, added the C++ function to my module list, and got a working link.

Need to see some actual code.

% cat > foo.c
int
foo(void)
{
return (1);
}
% gcc14 -c foo.c
% nm foo.o
0000000000000000 T foo
% g++14 -c foo.c
% nm foo.o
0000000000000000 T _Z3foov
% cat > foo.f90
integer*8 function foo()
foo = 1
end
% gfortran14 -c foo.f90
% nm foo.o
0000000000000000 T foo_

So, with gcc, you get the symbol foo. With g++, you get the mangled
named _Z3foov. With gfortran, you get foo_.

[Lynn McGuire]

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.
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.
I removed the Gfortran code "external" keywords, extern "C" the C++
functions, added the C++ function to my module list, and got a working link.
Thanks,
Lynn

I found and fixed the problem with my code along with one of my
programmers. I was not properly handling the size_t hidden argument
length value that GFortran adds to the character string arguments in my
C++ code. Things are going better now.

Thanks for all of the suggestions. Sorry to bother you all with my issues.

Lynn

[Thomas Koenig]

Post by Lynn McGuire
I found and fixed the problem with my code along with one of my
programmers. I was not properly handling the size_t hidden argument
length value that GFortran adds to the character string arguments in my
C++ code. Things are going better now.

Good to hear that.

Another thing that works well for gcc is to link everything with
the -flto option.

An example:

$ cat main.f90
program memain
character *1 c
call foo(c)
print *,c
end
$ cat foo.c
void foo_(char *c)
{
*c = 'A';
}
$ gfortran -flto main.f90 foo.c
main.f90:3:13: warning: type of 'foo' does not match original declaration [-Wlto-type-mismatch]
3 | call foo(c)
| ^
foo.c:1:6: note: type mismatch in parameter 2
1 | void foo_(char *c)
| ^
foo.c:1:6: note: type 'void' should match type 'long int'
foo.c:1:6: note: 'foo_' was previously declared here

[Lynn McGuire]

Post by Thomas Koenig

Post by Lynn McGuire
I found and fixed the problem with my code along with one of my
programmers. I was not properly handling the size_t hidden argument
length value that GFortran adds to the character string arguments in my
C++ code. Things are going better now.

Good to hear that.
Another thing that works well for gcc is to link everything with
the -flto option.
$ cat main.f90
program memain
character *1 c
call foo(c)
print *,c
end
$ cat foo.c
void foo_(char *c)
{
*c = 'A';
}
$ gfortran -flto main.f90 foo.c
main.f90:3:13: warning: type of 'foo' does not match original declaration [-Wlto-type-mismatch]
3 | call foo(c)
| ^
foo.c:1:6: note: type mismatch in parameter 2
1 | void foo_(char *c)
| ^
foo.c:1:6: note: type 'void' should match type 'long int'
foo.c:1:6: note: 'foo_' was previously declared here

I will try it.

Thanks,
Lynn

[Thomas Koenig]

Post by Lynn McGuire

Post by Thomas Koenig

Post by Lynn McGuire
I found and fixed the problem with my code along with one of my
programmers. I was not properly handling the size_t hidden argument
length value that GFortran adds to the character string arguments in my
C++ code. Things are going better now.

Good to hear that.
Another thing that works well for gcc is to link everything with
the -flto option.
$ cat main.f90
program memain
character *1 c
call foo(c)
print *,c
end
$ cat foo.c
void foo_(char *c)
{
*c = 'A';
}
$ gfortran -flto main.f90 foo.c
main.f90:3:13: warning: type of 'foo' does not match original declaration [-Wlto-type-mismatch]
3 | call foo(c)
| ^
foo.c:1:6: note: type mismatch in parameter 2
1 | void foo_(char *c)
| ^
foo.c:1:6: note: type 'void' should match type 'long int'
foo.c:1:6: note: 'foo_' was previously declared here

I will try it.

Just a warning - be prepared for loooong compile times.