Re: Unable to access macports-infrastructure.git
> On Mar 12, 2024, at 19:46, Dave Allured wrote: > > > I am getting an unusual builder error that is blocking my recent port update > on all of the builders. Go to console view on build.macports.org, find port > `gjs-devel`, and look at the stdio logs below the commit message. > > `fatal: unable to access > 'https://github.com/macports/macports-infrastructure.git/': Server aborted > the SSL handshake` > > Now I know they put Dave detectors in all the traffic lights. I thought > maybe that was the problem here, but Ryan has one too. Please let me know > how to get my build started, and whether I owe money or something. Thank you. The build server has been under heavy load. Not completely sure why yet. It took me minutes to even pull up a buildbot web site. It's possible builds are failing as a result and will have to be retried once things calm down. I will try to make a change to reduce CPU use shortly.
Unable to access macports-infrastructure.git
I am getting an unusual builder error that is blocking my recent port update on all of the builders. Go to console view on build.macports.org, find port `gjs-devel`, and look at the stdio logs below the commit message. `fatal: unable to access ' https://github.com/macports/macports-infrastructure.git/': Server aborted the SSL handshake` Now I know they put Dave detectors in all the traffic lights. I thought maybe that was the problem here, but Ryan has one too. Please let me know how to get my build started, and whether I owe money or something. Thank you.
Re: inserting -stdlib=libstdc++ into cxxflags
> On Mar 13, 2024, at 4:07 AM, René J.V. Bertin wrote: > >> Building against libstdc++ is broken for Intel > > Not from what I can tell; I test built an OLD libxmlxx copy against libstdc++ > from GCC13 and that works. What I rather meant is that Macports cannot handle that properly, since it is kinda hardcoded to use clang and libc++ on anything besides powerpc. I think we have a few older ports broken now, which required libstdc++. > Yes, gcc 13 isn't yet compatible with libc++, but the current -stdlib=libc++ > implementation also fails (for me) on Qt5 (5.9) projects because libc++ has > its own version of (IIRC) cstddef and raises an error if the one from GCC has > already been included. To avoid that the c++/v1 directory must be before the > GCC C header dirs in the search list, and not after as GCC currently does it. > I've signalled that, and you can achieve the same thing with the traditional > recipe to use libc++ with GCC: `-nostdinc++ -isystem/path/to/c++/v1`. AFAIK nobody tested GCC with libc++, neither in upstream nor in Macports, so it is not overly surprising that it does not work :) It is worth opening a ticket on GCC Bugzilla, if there is none yet for this issue. > FWIW, I patched GCC 6 and 7 back in the day to add a `-stdlib=` argument. I > don't really know why I didn't use it, probably because the concurrent clang > versions were still faster. That's no longer the case; GCC 12 is about as > slow as clang 12 (but a lot more modern, with full, non-buggy C++20 support, > and apparently less resource hungry). On a side note, for older Intel systems it is not even clear if libc++ is a better choice.
Re: inserting -stdlib=libstdc++ into cxxflags
On Wednesday March 13 2024 03:44:17 Sergio Had wrote: >Which OS are we talking about? 10.9.5 but that what matters here is that it's a libc++-based OS version. >Building against libstdc++ is broken for Intel Not from what I can tell; I test built an OLD libxmlxx copy against libstdc++ from GCC13 and that works. Of course it's easy to break the application if you end up mixing libstdc++ with libc++. In fact, if libstdc++ were broken GCC itself wouldn't work: it can only be built against that C++ runtime. (You can imagine how complex my bootstrap flags are to build a gcc that uses libc++ by default ;) ) Yes, gcc 13 isn't yet compatible with libc++, but the current -stdlib=libc++ implementation also fails (for me) on Qt5 (5.9) projects because libc++ has its own version of (IIRC) cstddef and raises an error if the one from GCC has already been included. To avoid that the c++/v1 directory must be before the GCC C header dirs in the search list, and not after as GCC currently does it. I've signalled that, and you can achieve the same thing with the traditional recipe to use libc++ with GCC: `-nostdinc++ -isystem/path/to/c++/v1`. FWIW, I patched GCC 6 and 7 back in the day to add a `-stdlib=` argument. I don't really know why I didn't use it, probably because the concurrent clang versions were still faster. That's no longer the case; GCC 12 is about as slow as clang 12 (but a lot more modern, with full, non-buggy C++20 support, and apparently less resource hungry). I've caved and activated gcc12+stdlib_flag (i.e. the stock MP build) which will do what I want ATM without need for additional flags. I'm now rebuilding lld-17 with its minimal libLLVM & family. That build failed with -stdlib=libc++ (so gcc12 isn't perfectly compatible with any of our libc++ implementations I tested either) but the initial estimate is that the build would have completed in about 2/3 of the time as it would take with clang 16. Lld looks to depend on libc++ only through port:icu via libxml2 which is pure C afaik so the C++ runtimes should remain separated in this case. We'll see... anyway the only reason I'd keep the build is if it's a lot faster or a lot more compact than the one with clang 16. I mostly just want to compare build times on a hefty project. R.
Re: inserting -stdlib=libstdc++ into cxxflags
Which OS are we talking about?
Building against libstdc++ is broken for Intel and arm64, I believe, though it
should be fixable. But the problem is not passing the flag, but broken Apple
headers, it seems.
I managed to build some ports like CMake and a few others against libstdc++ on
Sonoma arm64, but kinda gave up, since too much stuff is broken, and there is
no immediate advantage in the switch.
I have this in macports.conf: `cxx_stdlib macports-libstdc++` (on Sonoma).
However you may need to pass both cxxflags and ldflags manually.
On PowerPC it is the reverse: building against libstdc++ is the default and
works fine, building against libc++ is very experimental and will likely need
fixups. Also, it requires enabling stdlib_flag variant for gcc and making it
use libcxx-powerpc port instead of clangs.
P. S. There is a bug in gcc13 which prevents it working correctly with libc++
headers (regardless of the arch, I think), should be fixed in upstream but
perhaps not in Macports, but gcc12 should be fine.
> On Mar 13, 2024, at 3:32 AM, René J.V. Bertin wrote:
>
> Hi,
>
> I've been tinkering a bit with a personal GCC12 build patched to use libc++
> by default, and now find myself unable to build against libstdc++.
>
> `configure.cxxflags-append -stdlib=libstdc++` appears to be filtered out
> somewhere in the "base" bowels, and `configure.cxx_stdlib libstdc++` appears
> not to have any effect either. I'm not seeing any warnings in the logfile,
> which is surprising (and rather bad practise IMHO).
>
> What am I missing here, and what backdoor(s) could I use? I notice that
> CXXFLAGS (aka Env(CXXFLAGS)) isn't yet set in `pre-configure`; I haven't yet
> checked if "base" preserves its settings when initialising it (have been
> assuming it won't). With autoconf-based projects one can set `configure.cxx
> ${configure.cxx} -stdlib=libstdc++` but that doesn't fly for cmake-based
> projects...
>
> Thanks,
> R.
inserting -stdlib=libstdc++ into cxxflags
Hi,
I've been tinkering a bit with a personal GCC12 build patched to use libc++ by
default, and now find myself unable to build against libstdc++.
`configure.cxxflags-append -stdlib=libstdc++` appears to be filtered out
somewhere in the "base" bowels, and `configure.cxx_stdlib libstdc++` appears
not to have any effect either. I'm not seeing any warnings in the logfile,
which is surprising (and rather bad practise IMHO).
What am I missing here, and what backdoor(s) could I use? I notice that
CXXFLAGS (aka Env(CXXFLAGS)) isn't yet set in `pre-configure`; I haven't yet
checked if "base" preserves its settings when initialising it (have been
assuming it won't). With autoconf-based projects one can set `configure.cxx
${configure.cxx} -stdlib=libstdc++` but that doesn't fly for cmake-based
projects...
Thanks,
R.
Re: jupytext port build cannot find jlpm
On Mar 12, 2024, at 10:00, Jonathan Stickel wrote:
>
> command not found: jlpm
>
> Recommendations for how to resolve this issue?
One solution is to figure out where this program is being called in the source
code, then patch it to use the program name as it appears in MacPorts (e.g. in
this case to add the python version to the end).
> Is there a way to set an alias during the build phase?
>
> alias jlpm="jlpm-${python.branch}"
I can't recall seeing a port that sets a shell alias so that may not be
possible.
Some ports do create a directory in workpath (e.g. ${workpath}/bin), then
create symlinks in there having the desired names, and add ${workpath}/bin to
PATH. But that's probably not needed in this case since you already have a
directory that contains the files with the desired names (below).
> Or add
> "${prefix}/Library/Frameworks/Python.framework/Versions/${python.branch}/bin"
> to the path? I haven't been successful implementing either approach.
You can find examples of how to do that by running:
port file all|sort -u|xargs grep '\sPATH='
Note that you want ${frameworks_dir}; don't assume its value is
${prefix}/Library/Frameworks
> I've been wondering if it is worth the trouble to create and maintain ports
> for some of these python packages. These days they are often using advanced
> python-internal build tools that are difficult to configure, while `pip
> install ` often just works. By comparison, there is a port for Julia
> but none of its packages, instead relying entirely on Julia's package
> manager. I'm curious about the thoughts of others on this matter.
I don't think it's been the intention to add all python modules to MacPorts.
Rather, we add modules that are dependencies of other ports or are useful on
their own (especially if requested by a user).
The python portgroup was enhanced to support many of the new build systems.
Check out the python.pep517_backend option.
Re: CI are forcing tests for ports where tests are disabled
I think I may have run into a similar issue with how tests have changed in CI with 2.9.x MacPorts and the OpenSSH 9.7p1 PR I submitted yesterday: https://github.com/macports/macports-ports/pull/22981 Going back to reverting to 9.6p1 locally and running port -d -v test I see that it fails with the same error; whereas when the CI checks for that ran with my PR in December of 2023, the CI checks passed. The man page for port test is pretty slim: test Tests portname. So I am guessing this is the spot to reference for more descriptive explanations of test.cmd and test.args https://guide.macports.org/#reference.phases.test Whereas the net/openssh Portfile just has these defined at the moment: test.runyes test.target tests I've include the output of manually invoking "make test" in the following Trac issue I opened regarding this CI buildbot failure: https://trac.macports.org/ticket/69478#comment:2 Which, as you can see, ends with "all tests passed"; so I don't think this is an issue with upstream/OpenSSH's tests. Not to mention, running make tests from the OpenSSH tarball is really quite time consuming and probably not the best use of CI buildbot resources? I can't make heads or tails of this commit from 2.9.0 which introduced the "simple default tests for all ports" https://github.com/macports/macports-base/commit/ddc26554e6ed49ce8501069b967284739fa6d34e But, I am guessing, it's either not that simple, or at a minimum, I might need some additional insights into how to placate it. Thanks!
jupytext port build cannot find jlpm
I'm trying to update the port `py-jupytext` since the recent updates to
Jupyterlab. The jupytext package now uses node.js and jlpm to build. The
port `py-jupyterlab` provides jlpm, but it is in the path as
`jlpm-{python.branch}`, and consequently jupytext cannot find it. I
tried patching `${worksrcpath}/pyproject.toml` to have
npm = ["jlpm-${python.branch}"]
This is similar to the Portfile for py-notebook. It helps get past the
first use of jlpm, but a later step fails:
command not found: jlpm
Recommendations for how to resolve this issue? Is there a way to set an
alias during the build phase?
alias jlpm="jlpm-${python.branch}"
Or add
"${prefix}/Library/Frameworks/Python.framework/Versions/${python.branch}/bin"
to the path? I haven't been successful implementing either approach.
Thanks,
Jonathan
P.S.
I've been wondering if it is worth the trouble to create and maintain
ports for some of these python packages. These days they are often using
advanced python-internal build tools that are difficult to configure,
while `pip install ` often just works. By comparison, there is
a port for Julia but none of its packages, instead relying entirely on
Julia's package manager. I'm curious about the thoughts of others on
this matter.
