OpenBLAS @0.3.21_2+gcc12+lapack: broken header symlinks

[jmroot (Joshua Root)]

% port provides /opt/local/include/lapacke_utils.h
/opt/local/include/lapacke_utils.h is provided by: OpenBLAS
% ls -l /opt/local/include/lapacke_utils.h        
lrwxr-xr-x  1 root  wheel  21  7 Feb 03:03 /opt/local/include/lapacke_utils.h -> cblas/lapacke_utils.h
% ls -l /opt/local/include/cblas/lapacke_utils.h
ls: /opt/local/include/cblas/lapacke_utils.h: No such file or directory

Running the symlinks utility reveals several more:

dangling: /opt/local/include/lapacke_utils.h -> cblas/lapacke_utils.h
dangling: /opt/local/include/lapacke.h -> cblas/lapacke.h
dangling: /opt/local/include/f77blas.h -> cblas/f77blas.h
dangling: /opt/local/include/openblas_config.h -> cblas/openblas_config.h
dangling: /opt/local/include/lapacke_config.h -> cblas/lapacke_config.h
dangling: /opt/local/include/lapack.h -> cblas/lapack.h
dangling: /opt/local/include/cblas_openblas.h -> cblas/cblas.h
dangling: /opt/local/include/lapacke_mangling.h -> cblas/lapacke_mangling.h

[mike142wood]

This seems to be blocking recompilation of python310, python311 and at least one port depending on the python310
the target .h files do appear in /opt/local/include/openblas which was updated on 5 Feb by an upgrade of port OpenBLAS

MacPorts base version 2.8.1 installed
macOS Monterey; Version 12.6.3

[kencu (Ken)]

there is a PR to fix this waiting for the maintainer to review and commit

​https://github.com/macports/macports-ports/pull/17662

[JDLH (Jim DeLaHunt)]

A workaround that was successful for me was to make a symbolic link cblas which points to openblas. This means that the incorrect symbolic links get redirected to the actual location of the include files. It approximates, less well, what ​PR 17662 does.

Create the symbolic link with the shell command:

sudo ln -s openblas /opt/local/include/cblas

Once this ticket gets fixed, the extra link probably does no harm. Still, it is better to delete that link with:

sudo rm /opt/local/include/cblas

[Gandoon (Erik Hedlund)]

Replying to JDLH:

A workaround that was successful for me was to make a symbolic link cblas which points to openblas. This means that the incorrect symbolic links get redirected to the actual location of the include files. It approximates, less well, what ​PR 17662 does.

Create the symbolic link with the shell command:

sudo ln -s openblas /opt/local/include/cblas

Once this ticket gets fixed, the extra link probably does no harm. Still, it is better to delete that link with:

sudo rm /opt/local/include/cblas

Since ther was no /opt/local/include/cblas and all the links were dangling, I just manually relinked the requested .h-file links to those in the openblas location, mirroring the effect of the PR. That works equally well, and I will not end up with the link that you mentioned.

When the PR is accepted, I expect my system to be identical to the new port revision (unless something new pops up).

[JDLH (Jim DeLaHunt)]

Replying to Gandoon:

Since ther was no /opt/local/include/cblas and all the links were dangling, I just manually relinked the requested .h-file links to those in the openblas location, mirroring the effect of the PR. That works equally well, and I will not end up with the link that you mentioned.

When the PR is accepted, I expect my system to be identical to the new port revision (unless something new pops up).

Good suggestion. I agree, this is a better way to work around the problem.

However, I did not want to take the trouble to find all the .h-files which are dangling simlinks to cblas/* and come up with the correct link for each to openblas/* . So, there is a choice of workarounds, some more work up front, some more work to clean up.

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

In 8ccc6f7e88f61676e870192bf91d26beb8a458c7/macports-ports (master):

OpenBLAS: fix broken links to header files

Fixes #66881

[JDLH (Jim DeLaHunt)]

The fix in 8ccc6f7e88f61676e870192bf91d26beb8a458c7/macports-ports (master) was effective for me. Thank you!

I tested it by removing my workaround symlink mentioned in comment:8, then uninstalling python310, then reinstalling it. python310 rebuilt successfully.

[ednl (Ewoud Dronkert)]

Found this ticket after submitting a new ticket for python310 because a search didn't return this thread. To recap, I did this to fix for now:

cd /opt/local/include
sudo ln -fs openblas/cblas.h cblas_openblas.h
sudo ln -fs openblas/f77blas.h f77blas.h
sudo ln -fs openblas/lapack.h lapack.h
sudo ln -fs openblas/lapacke.h lapacke.h
sudo ln -fs openblas/lapacke_config.h lapacke_config.h
sudo ln -fs openblas/lapacke_mangling.h lapacke_mangling.h
sudo ln -fs openblas/lapacke_utils.h lapacke_utils.h
sudo ln -fs openblas/openblas_config.h openblas_config.h

Note the odd one out (the first one) where the target file name and link name aren't the same.

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

Replying to ednl:

Found this ticket after submitting a new ticket for python310 because a search didn't return this thread. To recap, I did this to fix for now: ...

After ​a recent change, these types of workarounds should no longer be necessary.

[ednl (Ewoud Dronkert)]

Replying to MarcusCalhoun-Lopez:

After ​a recent change, these types of workarounds should no longer be necessary.

Perhaps, but I was stuck anyway. Someone suggested I needed to update openblas first and that might fix it, but how was I supposed to know?

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

Replying to ednl:

Replying to MarcusCalhoun-Lopez:

After ​a recent change, these types of workarounds should no longer be necessary.

Perhaps, but I was stuck anyway. Someone suggested I needed to update openblas first and that might fix it, but how was I supposed to know?

Fair point.
I just wanted to emphasize that the fix now exits.
Thank you for the input.