Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

[BUG] Fortran source files don't propagate through `library-manifest` dependency resolution outside `task: 'build'`

Abierto
  • ¿Algo no está bien?
#11,930 9 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
48/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
fortran, javascript
Área
build-system, tooling

Línea de trabajo

Reproduce el fallo de lib/node_modules/@stdlib/blas/base/dger/benchmark/fortran con make y, después, inspecciona @stdlib/utils/library-manifest y los archivos manifest.json de dger y xerbla. Comprueba tools/scripts/compile_fortran_benchmark y los Makefiles de benchmarks de Fortran fusionados en comparación con la ruta del benchmark de C. Se considera terminado cuando la resolución de dependencias del benchmark expone el código fuente de Fortran de xerbla sin rutas codificadas de directorios hermanos y el benchmark se enlaza correctamente.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Description

Error is encountered when a Fortran benchmark for a Level-2+ BLAS routine whose Fortran source declares an EXTERNAL Fortran dependency on another stdlib package (e.g., dgemm calling xerbla, dger calling xerbla). The benchmark fails to link with a missing-symbol error for the dependency.

The underlying defect is in @stdlib/utils/library-manifest. When the resolver is queried with any task other than build (notably task: 'benchmark'), Fortran source files belonging to dependencies are not surfaced.

Fortran sources are currently declared only inside the build task entry of each Fortran-using package's manifest — so when library-manifest walks the dependency tree under task: 'benchmark', it merges each dependency's benchmark entry, which contains only C sources, and the dependency's .f files never appear in the merged result.

For example, in blas/base/xerbla/manifest.json:

  • task: 'build', os: 'linux', blas: '', wasm: false → src: ["./src/xerbla.f", "./src/xerbla.c"]
  • task: 'benchmark', os: 'linux', blas: '', wasm: false → src: ["./src/xerbla.c"] (no .f)

The native-addon build path works bc binding.gyp/include.gypi calls library-manifest with no explicit task, defaulting to task: 'build', where the .f declarations exist.

The same condition silently affects every merged Fortran benchmark for a Level-2+ BLAS routine that exercises a cross-package Fortran symbol. Level-1 BLAS Fortran benchmarks (e.g., daxpy, dscal, dasum) have no cross-package Fortran dependencies and link cleanly, which is why the gap has not surfaced more broadly.

The recurring local fix is a Makefile patch in the consuming package that hardcodes a relative path to a sibling package's .f file (e.g., ../../../xerbla/src/xerbla.f inside dger's benchmark Makefile). This couples one package to another package's file-tree layout. If xerbla is ever moved within the package tree (e.g., to @stdlib/blas/base/utils/xerbla), every consumer's hardcoded path silently breaks, and a contributor performing the migration has no way to discover the breakage short of running every affected benchmark. The manifest-based @stdlib/... reference model exists precisely so packages don't reach into each other's file trees this way. See @kgryte's comment on PR #11332.

A second, downstream contributor to the symptom is that tools/scripts/compile_fortran_benchmark only resolves include directories from the manifest, while its C counterpart tools/scripts/compile_c_benchmark resolves include, src, libraries, and libpath. Patching only this wrapper might be too narrow, since it wouldn't address future Fortran-linking contexts that go through library-manifest.

Per office hours discussion, the fix should live in @stdlib/utils/library-manifest so that Fortran source files are resolved uniformly when resolving a package's dependency tree, regardless of the task the caller queried.

Once the resolver is correct, downstream cleanup for the Fortran benchmark wrapper in tools/scripts/ should consume the resolved source list (mirroring its C counterpart), and the merged Fortran benchmark Makefiles' hardcoded SOURCE_FILES defaults should match the C-benchmark Makefile convention.

Related Issues

Related PRs #11332 and #11333.

Questions

No.

Demo

No response

Reproduction
# In a checkout of stdlib develop:
cd lib/node_modules/@stdlib/blas/base/dger/benchmark/fortran
make
Expected Results

Benchmark links successfully; xerbla resolves via the manifest dependency graph (dger's manifest already lists @stdlib/blas/base/xerbla as a dependency under task: 'benchmark'.

Actual Results
Undefined symbols for architecture arm64:
  "_xerbla", referenced from:
      _dger in ccCfvnCt.o
ld: symbol(s) not found for architecture arm64
collect2: error: ld returned 1 exit status
make: *** [benchmark.length.out] Error 1

Linker fails with an unresolved reference to xerbla. The dependency's .f source is never surfaced because library-manifest only declares Fortran sources under task: 'build'.

Version

develop

Environments

N/A

Browser Version

No response

Node.js / npm Version

No response

Platform

Reproduces on any platform with gfortran + make (linux/macOS verified).

Checklist
  • Read and understood the Code of Conduct.
  • Searched for existing issues and pull requests.
Lenguaje dominante
JavaScript
Estrellas
6k
Forks
1.3k
Merge medio
1 d 10 h
PR fusionados (30 d)
568

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de stdlib-js/stdlib

Todos los issues de stdlib-js/stdlib

Issues similares

Más issues de JavaScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.