Critical Issue: CLT16 Linker Fails to Initialize BLOCK DATA

Compilers GNU
1

Hello,
We’ve encountered a critical issue with the new linker in Xcode 15’s CLT16 (version 16.1.0.0.1.1729049160) that prevents the proper initialization of BLOCK DATA .

I’m using GNU gfortran installed via MacPorts
gcc version 13.3.0 (MacPorts gcc13 13.3.0_2+stdlib_flag)

Currently, the workaround is to use the -ld_classic linker option. However, this option is deprecated and will be removed in a future release, as indicated in the Xcode release notes.

Here’s a minimal example that reproduces the problem:

gfortran -c bd.f 
gfortran -c main.f

ar rv libtest.a bd.o main.o 

gfortran -ld_classic -o good.x -L. libtest.a 

gfortran -o bad.x -L. libtest.a

where main.f

        PROGRAM BUG
        include 'part.inc'
        write(*,*) AM(1:2)
        END

bd.f

      BLOCK DATA BD
      include 'part.inc'
      DATA ( AM ( I ), I =   1, 2 ) /
     & 3.72738025692891D+00, 2.80839223660482D+00/
      END

and part.inc

        IMPLICIT DOUBLE PRECISION (A-H,O-Z)
        COMMON / PART / AM (2)
        SAVE / PART /

Has anyone else experienced this issue? and how to fix the problem?
Thanks

1 Like
2

I’m sure the real code you are working with is more complicated, but the long term answer is that block data is obsolete, as are common blocks. The “correct,” long-term solution would be

bd.f

      module bd
      double precision :: am(2)
      integer, private :: i
      data ( am(i), i = 1, 2 ) /
     & 3.72738025692891D+00, 2.80839223660482D+00/
      end module

main.f

        PROGRAM BUG
        use bd
        write(*,*) AM(1:2)
        END
1 Like
3

I 100% agree with @everythingfunctional. Convert to a module and be happy. If there are a lot of files that include the common block, you can even temporarily keep the common statement inside the module while converting to simply useing the module.

For historic completeness though, when a block data program unit resides in a library, you may need a external statement (as in external bd) in your main program to get the linker to recognize things. This is not needed when using modules.

4

One general approach that seemed to work with most compilers during the f77 era was to place the block data into the same file as the main program. Maybe that will still work with the modern combination of compilers, linkers, and library files.

5

That would work - because the linker doesn’t need to access the block data unit from the library. Bit of a pain when you have a suite of programs that all access the same library and don’t want to replicate the block data unit (or use includes) in all of their source files.

Technically the external trick wouldn’t work in f66 - because naming block data units wasn’t Standard until f77. However it was a somewhat common extension in f66 compilers.