Please write to list addresses at lists.macports.org, not at the old hostname that we discontinued using in late 2016.
On Sep 13, 2021, at 15:40, Epstein, David wrote: > > MacPorts base version 2.7.1 installed > MacOs 11.5.2 > MacBook Pro (Retina, 15-inch, Mid 2015) > > I get the error message in the Subject Line. So I looked at the discussion at > https://github.com/openslide/openslide-python/issues/27 > and carefully followed all the advice given there, but the error persists. > > bgilbert locked the topic on github in December 2019, saying that the problem > was resolved. He also said: > "This is likely to be a problem with your installation, so I'll close. If > you're still seeing this with OpenSlide installed in your library search > path, please reopen.” I don’t know how one can reopen a locked topic on > Github. Perhaps this will do the trick. I would guess you cannot reopen someone else's issue unless you are a member of the project. > Here is the command I gave to macports, and the response from macports.This > seems to mean that openslide file(s) are installed, > $ port search openslide > openslide @3.4.1_1 (graphics) > A C library for reading virtual slides. > > py-openslide @1.1.2_1 (python, graphics) > Python binding for the OpenSlide library. > > py27-openslide @1.1.2_1 (python, graphics) > Python binding for the OpenSlide library. > > py34-openslide @1.1.2_1 (python, graphics) > Obsolete port, replaced by py35-openslide > > py35-openslide @1.1.2_1 (python, graphics) > Python binding for the OpenSlide library. > > py36-openslide @1.1.2_1 (python, graphics) > Python binding for the OpenSlide library. > > py37-openslide @1.1.2_1 (python, graphics) > Python binding for the OpenSlide library. > > py38-openslide @1.1.2_1 (python, graphics) > Python binding for the OpenSlide library. > > py39-openslide @1.1.2_1 (python, graphics) > Python binding for the OpenSlide library. > > Found 9 ports. "port search" shows you what ports are available. It does not say anything about whether they are installed. "port installed" tells you what ports are installed. > but is there a way of checking further, "port contents" tells you the files MacPorts believes it has installed for a port. You can verify that the list contains the right files. You can then actually check the filesystem and see if the listed files do exist. (Something other than MacPorts could have removed the files after MacPorts installed them. If so, a "sudo port deactivate" followed by "sudo port activate" should bring them back.) > in particular checking that there is nothing wrong with the files? How would you define "wrong"? How should MacPorts know if the files are wrong? MacPorts does include a feature called rev-upgrade which checks one specific way in which files could be wrong, specifically whether they are linked with libraries that don't exist. This could happen for example when a library provided by a dependency is upgraded to a new major version. Port maintainers should notice and fix this problem, but sometimes it is overlooked. If this situation is discovered, MacPorts automatically rebuilds the ports to fix them. rev-upgrade runs automatically after every port installation or upgrade. If things are still broken after rebuilding, it tells you that. > From the discussion on Github, it seems that the problem may be with > Macports. I could (very reluctantly) delete my Macports installation and > reinstate it. Does anyone have some wise advice? I don't see any reason why you should uninstall MacPorts for this. I don't think that will bring you any closer to solving the problem. The error message you showed didn't tell us the exact path and name of the library it is looking for. Discover that first. Then check if the library exists at that path. If yes, why can't it be used? Does it have the wrong install_name or is it the wrong version or broken due to linking with a nonexistent library? If no, why not? What should be providing that library? Why isn't it? Or is the issue perhaps that it is not looking for the library in a specific path, expecting you instead to be setting DYLD_LIBRARY_PATH to tell it where the library is? If so, don't do that; report the problem to the author of the software so that they can fix it so that it does not require setting DYLD_LIBRARY_PATH. No program should require a user to set DYLD_LIBRARY_PATH. Setting DYLD_LIBRARY_PATH will cause other problems.
