libtorrent-rasterbar fails to install during an update attempt
port outdated The following installed ports are outdated: libtorrent-rasterbar 2.0.8_0 < 2.0.8_1 Downloads: sudo port -v -s upgrade outdated ---> Computing dependencies for libtorrent-rasterbar. ---> Configuring libtorrent-rasterbar Error: Failed to configure libtorrent-rasterbar: boost176 must be installed with +python311. Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_net_libtorrent-rasterbar/libtorrent-rasterbar/main.log for details. Error: Follow https://guide.macports.org/#project.tickets if you believe there is a bug. A small log file is attached. This is mostly an FYI because I'm not sure if I even need this port, although *something* needs it. Thanks, Ken Wolcott libtorrent-rasterbar_main.log.xz Description: application/xz
Re: [mysterious owner of 'libc++.1.dylib']
Hi, On Wed, Mar 15, 2023 at 06:00:44PM +, Maxim Abalenkov wrote: > Further inquiry with ‘pkgutil’ doesn’t shed more light either: > > pkgutil --file-info "/usr/lib/libc++.1.dylib" > volume: / > path: /usr/lib/libc++.1.dylib > > Would you please tell me, who is the mysterious owner of the ‘libc++’? It is provided by the Operating System, except you cannot see it in the filesystem. This is a trick that Apple has started with one of its recent OS releases, where you can link against libraries that do not exist in the filesystem, but the dynamic loader dyld(1) still knows where to find them. See for example, otool -L /bin/bash, which tells you that it links against /usr/lib/libncurses.5.4.dylib and /usr/lib/libSystem.B.dylib, none of which exist on your system. When compiling, Apple's compiler will search a MacOS SDK for this library. For example, the definition of libc++.1.dylib required by the compiler is at /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib/libc++.1.tbd You'll notice that this isn't a library either – it's a text file with some metadata about the real libc++.1.dylib. Apple's clang compiler still knows how to deal with this file format, and can link against the library, despite it not existing on disk. > libcxx @5.0.1_5 (lang) > libc++ is a new implementation of the C++ standard library with support > for C++11 and portions of C++14. > > macports-libcxx @11.1.0 (lang) > provides a newer libc++ from llvm for older systems Those are indeed other versions of that same libc++ you are looking for. These ports are only useful on older macOS versions that do not yet have their own copy of libc++, though. You should never install them on modern macOS, and you should not need to. HTH, Clemens
Re: [mysterious owner of 'libc++.1.dylib']
On 2023-03-15 at 14:00:44 UTC-0400 (Wed, 15 Mar 2023 18:00:44 +) Maxim Abalenkov is rumored to have said: Dear all, I need help please. I’m compiling a C/C++ code base with clang++ compiler installed via MacPorts. When I look at the libraries my executable relies on I see: otool -L /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1300.36.0) What macOS version? I'm guessing Ventura... That file doesn't exist on Big Sur (where there is a libc++.dylib elsewhere) but it does on El Cap, where it is (sensibly) part of the base OS. I suspect that the version there is an indicator of macOS 13. However, when I try to find out what package owns this library: sudo port provides "/usr/lib/libc++.1.dylib" /usr/lib/libc++.1.dylib does not exist. Yes. MacPorts doesn't install libraries into /usr/lib. That would be bad. Further inquiry with ‘pkgutil’ doesn’t shed more light either: pkgutil --file-info "/usr/lib/libc++.1.dylib" volume: / path: /usr/lib/libc++.1.dylib Interesting. On my El Cap machine pkgutil shows that com.apple.pkg.Essentials and multiple com.apple.pkg.update.10.11.* packages included a file with that path. Would you please tell me, who is the mysterious owner of the ‘libc++’? It is part of macOS itself. Specifically, it is the implementation of the standard C++ library developed by the LLVM project, which is used by the clang++ compiler. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
[mysterious owner of 'libc++.1.dylib']
Dear all, I need help please. I’m compiling a C/C++ code base with clang++ compiler installed via MacPorts. When I look at the libraries my executable relies on I see: otool -L /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1300.36.0) However, when I try to find out what package owns this library: sudo port provides "/usr/lib/libc++.1.dylib" /usr/lib/libc++.1.dylib does not exist. Further inquiry with ‘pkgutil’ doesn’t shed more light either: pkgutil --file-info "/usr/lib/libc++.1.dylib" volume: / path: /usr/lib/libc++.1.dylib Would you please tell me, who is the mysterious owner of the ‘libc++’? Looking for libc++ in the names of ports returns the following list: sudo port search libc++ gcc-devel-libcxx @13-20230226_1 (lang) libc++ header implementation to be used by gcc-devel gcc10-libcxx @10.4.0_5 (lang) libc++ header implementation to be used by gcc10 gcc11-libcxx @11.3.0_6 (lang) libc++ header implementation to be used by gcc11 gcc12-libcxx @12.2.0_4 (lang) libc++ header implementation to be used by gcc12 libcxx @5.0.1_5 (lang) libc++ is a new implementation of the C++ standard library with support for C++11 and portions of C++14. macports-libcxx @11.1.0 (lang) provides a newer libc++ from llvm for older systems Found 6 ports. — Best wishes, Maxim Maxim Abalenkov \\ maxim.abalen...@gmail.com +44 7 486 486 505 \\ www.maxim.abalenkov.uk
Setting environment and support of older OS/arch
(1) How is it possible to not only set a compiler using "port select", but add some -I directives too? Problem is that, using Tiger 10.5.8, nearly every relevant thing is below /opt/local (e.g. STL), but gcc consequently takes include files from /usr/include, so compilation will fail often. A maybe clearer variant of this question would be: Is it possible to replace (better: overlay in the sense of an overlay fs) system tools with those from macpports, as the current strategy seems to enforce consequent confusion? (2) As ports is of course more focused on recent OS', is/are there (a) branch(es) or related project(s) focusing on support of older ones? Maybe that could make things easier, even with the risk of drifting apart, but either I'm still ignorantly missing that, or there's none... Thanks in advance, Eckard
