# Critical Issue: CLT16 Linker Fails to Initialize BLOCK DATA
**URL:** https://fortran-lang.discourse.group/t/critical-issue-clt16-linker-fails-to-initialize-block-data/8931
**Category:** GNU
**Created:** [December 5, 2024, 2:15pm UTC](https://fortran-lang.discourse.group/t/critical-issue-clt16-linker-fails-to-initialize-block-data/8931 "2024-12-05T14:15:22Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@luillo](https://fortran-lang.discourse.group/u/luillo)
#### Post date: [December 5, 2024, 2:15pm UTC](https://fortran-lang.discourse.group/t/critical-issue-clt16-linker-fails-to-initialize-block-data/8931/1 "2024-12-05T14:15:22Z")
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:
```auto
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`
```auto
PROGRAM BUG
include 'part.inc'
write(*,*) AM(1:2)
END
```
`bd.f`
```auto
BLOCK DATA BD
include 'part.inc'
DATA ( AM ( I ), I = 1, 2 ) /
& 3.72738025692891D+00, 2.80839223660482D+00/
END
```
and `part.inc`
```auto
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
---
### Author:  [@everythingfunctional](https://fortran-lang.discourse.group/u/everythingfunctional)
#### Post date: [December 5, 2024, 5:35pm UTC](https://fortran-lang.discourse.group/t/critical-issue-clt16-linker-fails-to-initialize-block-data/8931/2 "2024-12-05T17:35:32Z")
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`
```auto
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`
```auto
PROGRAM BUG
use bd
write(*,*) AM(1:2)
END
```
---
### Author:  [@wspector](https://fortran-lang.discourse.group/u/wspector)
#### Post date: [December 5, 2024, 5:41pm UTC](https://fortran-lang.discourse.group/t/critical-issue-clt16-linker-fails-to-initialize-block-data/8931/3 "2024-12-05T17:41:57Z")
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 `use`ing 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.
---
### Author:  [@RonShepard](https://fortran-lang.discourse.group/u/RonShepard)
#### Post date: [December 5, 2024, 6:19pm UTC](https://fortran-lang.discourse.group/t/critical-issue-clt16-linker-fails-to-initialize-block-data/8931/4 "2024-12-05T18:19:52Z")
> [@luillo](#):
>
> Has anyone else experienced this issue?
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.
---
### Author:  [@wspector](https://fortran-lang.discourse.group/u/wspector)
#### Post date: [December 5, 2024, 6:30pm UTC](https://fortran-lang.discourse.group/t/critical-issue-clt16-linker-fails-to-initialize-block-data/8931/5 "2024-12-05T18:30:30Z")
> [@RonShepard](#):
>
> 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.
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.