Re: Preventing other software from linking against MacPorts libraries
> On May 10, 2024, at 12:14 PM, Ryan Schmidt wrote: > > On May 10, 2024, at 09:57, Smith wrote: >> >> Thanks all for the replies. The software depends on openssl, libpng and >> libjpeg. > > And the name and version of the software that depends on those? https://github.com/istopwg/ippsample > >> In the past with other projects I left MacPorts in place but used Homebrew >> to install these dependencies, or just built those dependencies from >> scratch. It's not a "bad" thing for them to link to MacPorts libraries per >> se. > > Having Homebrew and MacPorts installed at the same time is likely to cause > you problems. If you're building software manually, you could end up linking > against one library from MacPorts and another library from Homebrew which is > not only messy but might actually be incompatible if the two libraries are > related. > > It's even possible, if you install a MacPorts port that has to build from > source, that it is hard coded to look for Homebrew first and fall back to > MacPorts, in which case your MacPorts port is now linked with a Homebrew > library. > > For these reasons we don't support having Homebrew installed at the same time > as MacPorts and recommend you pick one package manager and uninstall the > other(s). > > May I ask why you do not want to link your program with MacPorts libraries if > linking with Homebrew libraries is acceptable? Why are they ok and we aren't? > What can we change to become ok? I'll work on enumerating the problems I'm having in more detail in a future reply to this thread. > > >> Some of this might be due to my installing binary pre-built ports, which >> seem to not be code signed or not signed by me. I don't know if I were to >> install all ports in source form and build them locally would resolve some >> of my issues. I'm not sure how to cause port to reinstall everything >> installed from source and to use source ports rather than binary ports going >> forward. I'm sure it is documented somewhere... > > On Apple Silicon, everything is at least ad-hoc signed because that's what > the toolchain does by default. On earlier systems most things are not signed > because that's what the toolchain does by default. > > As far as I know there would be no difference if you built from source, > except that it would take a lot longer, use a lot more energy, and you might > encounter build failures. So I don't know why you would want to avoid the > binaries we spend so much effort providing. But if you do: > > https://trac.macports.org/wiki/BinaryArchives#disable Purely to explore that as a way of resolving the issue that I'm having.
Re: Preventing other software from linking against MacPorts libraries
On May 10, 2024, at 09:57, Smith wrote: > > Thanks all for the replies. The software depends on openssl, libpng and > libjpeg. And the name and version of the software that depends on those? > In the past with other projects I left MacPorts in place but used Homebrew to > install these dependencies, or just built those dependencies from scratch. > It's not a "bad" thing for them to link to MacPorts libraries per se. Having Homebrew and MacPorts installed at the same time is likely to cause you problems. If you're building software manually, you could end up linking against one library from MacPorts and another library from Homebrew which is not only messy but might actually be incompatible if the two libraries are related. It's even possible, if you install a MacPorts port that has to build from source, that it is hard coded to look for Homebrew first and fall back to MacPorts, in which case your MacPorts port is now linked with a Homebrew library. For these reasons we don't support having Homebrew installed at the same time as MacPorts and recommend you pick one package manager and uninstall the other(s). May I ask why you do not want to link your program with MacPorts libraries if linking with Homebrew libraries is acceptable? Why are they ok and we aren't? What can we change to become ok? > Some of this might be due to my installing binary pre-built ports, which seem > to not be code signed or not signed by me. I don't know if I were to install > all ports in source form and build them locally would resolve some of my > issues. I'm not sure how to cause port to reinstall everything installed from > source and to use source ports rather than binary ports going forward. I'm > sure it is documented somewhere... On Apple Silicon, everything is at least ad-hoc signed because that's what the toolchain does by default. On earlier systems most things are not signed because that's what the toolchain does by default. As far as I know there would be no difference if you built from source, except that it would take a lot longer, use a lot more energy, and you might encounter build failures. So I don't know why you would want to avoid the binaries we spend so much effort providing. But if you do: https://trac.macports.org/wiki/BinaryArchives#disable
Re: Preventing other software from linking against MacPorts libraries
Thanks all for the replies. The software depends on openssl, libpng and libjpeg. In the past with other projects I left MacPorts in place but used Homebrew to install these dependencies, or just built those dependencies from scratch. It's not a "bad" thing for them to link to MacPorts libraries per se. Some of this might be due to my installing binary pre-built ports, which seem to not be code signed or not signed by me. I don't know if I were to install all ports in source form and build them locally would resolve some of my issues. I'm not sure how to cause port to reinstall everything installed from source and to use source ports rather than binary ports going forward. I'm sure it is documented somewhere... Smith > On May 9, 2024, at 6:39 AM, Bill Cole > wrote: > > On 2024-05-09 at 02:03:15 UTC-0400 (Thu, 9 May 2024 00:03:15 -0600) > Smith via macports-users > is rumored to have said: > >> Hello, >> >> I occasionally run into a problem where I'm building software from a tarball >> or a git clone outside of MacPorts, and the build process somehow ends up >> linking or trying to link against libraries in the MacPorts space >> (/opt/local). How can I prevent this from happening? Sometimes I just end up >> deleting /opt/local to get it to build and then re-install MacPorts, which >> can be painful or at least tiresome. I have to assume there is a better way >> or that I'm doing something wrong? >> >> Thanks in advance for any thoughts, > > When building software outside of MacPorts, you should cleanse your > environment of any clues that /opt/local/ is a place to look for software. > Remove /opt/local/bin and /opt/local/sbin from your PATH when running any > 'configure' script (or other GNU auto* tools) that looks for tools and > libraries. > > Any software that is meant to be multiplatform should have some mechanism for > explicitly setting where to find libraries, such as options to an > autoconf-based configure script. You can use those or (less ideal) just > manually obliterate any hints of /opt/local in the Makefiles created by the > configure script. > > -- > Bill Cole > b...@scconsult.com or billc...@apache.org > (AKA @grumpybozo@toad.social and many *@billmail.scconsult.com addresses) > Not Currently Available For Hire
