Hi,
Chris Jones via macports-dev wrote:
b.t.w. this could well be the reason behind the previous issue.
even though you have gcc14 installed, it will most probably only be
the default x86_64 install. When you ran
sudo port -v upgrade openssl3 configure.compiler=macports-gcc-14
something is
On 03/02/2025 19.22, Ryan Carsten Schmidt wrote:
> I have not yet updated php84 to 8.4.0 stable or later.
>
> I realize this is overdue. I have other pending work to finish
> and commit to the php ports to fix some open tickets.
Besides, what I've already done, what can I do to help you ???
--
On 19/02/2025 11:29 am, Chris Jones via macports-dev wrote:
nothing to upgrade/install, nothing broken... where is the catch? User
error or a bug? where?
Something in your dependency tree is requiring i386, which is what is
triggering
Error: Cannot install libgcc14 for the archs '
nothing to upgrade/install, nothing broken... where is the catch? User
error or a bug? where?
Something in your dependency tree is requiring i386, which is what is
triggering
Error: Cannot install libgcc14 for the archs 'i386 x86_64' because
Error: its dependency libmpc cannot build for t
raf via macports-dev wrote:
Without you, no TenFourFox on Intel and also no ArcticFox on Macs.
Ooh, that's ineresting. I just tried to install TenFourFox
on intel 10.6 and it complained that it's only for ppc.
I'll have another look.
officially, TenFourFox was only PPC and it
Hi,
I have an apparently similar issue that I had with Leopard with older
gccs, but in this case with current gcc14.
I want to test building openssl3 with gcc instead of clang and I do this:
Irrlicht:Arctic-Fox multix$ sudo port -v upgrade openssl3
configure.compiler=macports-gcc-14
Hi,
Chris Jones wrote:
So, I see no problems now below...
now all is fine, indeed. But I wonder why things broke. A port was
installed, things upgraded, no other mention in upgrade outdated or
rev-upgrade, so not normal that I need to reinstall gcc7...
Riccardo
So, I see no problems now below...
On 17/02/2025 9:39 am, Riccardo Mottola wrote:
Hi Chris:
Chris Jones via macports-dev wrote:
> port rdeps gcc7
> sudo port install gcc7
and post what you get
Artax:~ multix$ port rdeps gcc7
The following ports are dependencies of gcc7 @7.5.0
Hi Chris:
Chris Jones via macports-dev wrote:
> port rdeps gcc7
> sudo port install gcc7
and post what you get
Artax:~ multix$ port rdeps gcc7
The following ports are dependencies of gcc7 @7.5.0_4:
xz
gettext
ncurses
gettext-tools-libs
libiconv
gperf
libtextstyle
gettext-runtime
c
The following extensions fail to configure -or- build:
@8.2.27 @8.3.16 @8.4.3
php-mysql_xdevapi x
php-rar x x x
php-openswoole x x
php-swoole x x
php-vld
age. This project does not have one, the two tarballs under the release
> notes are automatically generated by GitHub and (I think) is what
> `github.tarball_from tarball` will get you.
>
> Zhenfu
>
> On Feb 15, 2025, at 12:15, Dave Allured - NOAA Affiliate via macports-dev <
>
; On Feb 15, 2025, at 11:57, Dave Allured - NOAA Affiliate via macports-dev <
> macports-dev@lists.macports.org> wrote:
>
> I am trying to switch from "github.tarball_from tarball" to the
> recommended "releases". The original "tarball" setting wo
I am trying to switch from "github.tarball_from tarball" to the recommended
"releases". The original "tarball" setting works fine, but "releases"
fails to download. The upstream release and my Portfile lines are:
https://github.com/Unidata/netcdf-c/releases/tag/v4.9.3
github.setup
Artax:~ multix$ gcc-mp-7
gcc-mp-7: fatal error: no input files
compilation terminated.
Artax:~ multix$ gcc-mp-6
gcc-mp-6: fatal error: no input files
compilation terminated.
those errors are to be expected as you didn't give gcc anything to
compile ...
Please run
> port rdeps gcc7
> sudo port install gcc7
and post what you get
Chris
On 14/02/2025 3:53 pm, Riccardo Mottola via macports-dev wrote:
Hi,
some time ago we bumped to gcc14, I remember a long discussion. I had no
issues at a first glance on my systems. MDD G4, MB i386
terminated.
but if I use gcc7:
Artax:~ multix$ sudo port -vp upgrade xz-bootstrap
configure.compiler=macports-gcc-7
---> Computing dependencies for libgcc9
The following dependencies will be installed:
libgcc7
libgcc8
libgcc9
Continue? [Y/n]: y
Error: The following dependencies were
https://github.com/BjarneDMat/macports-ports/commit/8e1bcd9
OK - so what goes wrong here, is that the developer has made some
un-published changes to the code-base.
In particular :
1) https://github.com/derickr/vld/commit/d7abb0c
PHP_CHECK_GCC_ARG is now AX_CHECK_COMPILE_FLAG
2) https
https://www.php.net/manual/en/intro.mcrypt.php
This feature was DEPRECATED in PHP 7.1.0, and REMOVED in PHP 7.2.0.
https://pecl.php.net/package/mcrypt
This package is not maintained
https://github.com/BjarneDMat/macports-ports/commit/f89526a
Author: BjarneDM
Date: Wed Feb 12 19:20:10 2025
It builds with that change.
Thanks,
--Adam
> On Feb 12, 2025, at 8:08 AM, MacPorts wrote:
>
> #72050: py39-webcolors won't upgrade
> -+
> Reporter: dershow | Owner: (none)
> Type: defect
11, 2025, at 04:20, Graham A wrote:
>
> Hello,
>
> I'm not sure if this is the right place to send this email, but as a user of
> Tiger MacPorts, I think it is very unfortunate that you have decided to no
> longer support Tiger, and I hope there may be some room to recon
On Tue, Feb 11, 2025 at 02:36:03AM +, Gleb Mazovetskiy
wrote:
> Our port of DevilutionX to Tiger PPC, released yesterday and powered by
> macports and, has made the news:
>
> https://www.pcgamer.com/games/rpg/the-best-way-to-play-diablo-1-on-pretty-much-anything-just-got-an-upd
;s my impression too... at least this is how it came out.
At the same time, at least the ports tree was not fully functional on
10.4 for quite a while, I believe. So given that in any case users
will require either a full fork or at least a local overlay to have
MacPorts working, nothing ch
lost, or perhaps not really discussed as thoroughly as we might like. And
perhaps this is the disconnect, as I’m also somewhat surprised it was removed
so quickly following the support policy change.
Me too!
Ultimately the fact that MacPorts still supports Leopard and above, is awesome!
On Mon, Feb 10, 2025 at 11:33:53AM -0500, Christopher Nielsen
wrote:
> [...]
> It’s also important to separate our support policy toward Tiger -
> which is to now de-emphasize it - from what base supports. And that
> seems to have been lost, or perhaps not really discussed as thoroughly
> as we
ally discussed as thoroughly as we might like. And
> perhaps this is the disconnect, as I’m also somewhat surprised it was removed
> so quickly following the support policy change.
>
> Ultimately the fact that MacPorts still supports Leopard and above, is
> awesome! And hopefull
https://github.com/BjarneDMat/macports-ports/commit/0c4cd8e
php84-imagick rc1
fixes for
1) patching
2) default variant
On branch php84
Changes to be committed:
modified: php/php-imagick/Portfile
> It doesn't look like you're using ver
https://github.com/BjarneDMat/macports-ports/commit/0fb4448
php84-imagick beta1
!!NOT!! working correctly
1) patching
2) default variant
On branch php84
Changes to be committed:
modified: php/php-imagick/Portfile
new file: php/php-imagick
@7.4.33 doesn't like libxml2 @2.13.5_2 => fails to compile
logfile: https://macports.mathiesen.info/logs/php/php74/main.log
@8.0.30 doesn't like libxml2 @2.13.5_2 => fails to compile
logfile: https://macports.mathiesen.info/logs/php/php80/main.log
@8.1.31 builds - but segfaults wh
t-hash-config.w32.diff
DEBUG: Environment:
CC_PRINT_OPTIONS='YES'
CC_PRINT_OPTIONS_FILE='/opt/local/var/macports/build/_Volumes_Bjarne4TB_Users_Bjarne_BDMdata_GitMacintosh_MacPorts_macports-ports_lang_php/php83/work/.CC_PRINT_OPTIONS'
CPATH='/opt/local/include'
Bjarne, you reported build failure for `php-imagick` in your first draft.
Here are a couple fixes. Feel free to incorporate these into your branch,
or else let this PR go through as is. This could use some follow-up
testing which I can not provide.
https://github.com/macports/macports-ports
pspell was evicted from PHP core in version 8.4;
php81-pspell and later subports are now found in the separate php-pspell
Portfile.
On branch php84
Changes to be committed:
modified: lang/php/Portfile
new file: php/php-pspell/Portfile
--
Bjarne D Mathiesen
S
hopes to maybe redirect attention to
endeavors that might be beneficial to MacPorts holistically even if
funding and grants are rather orthogonal to the typical modus operandi
of the volunteer nature of the project on the whole.
Sometimes "the measure is full".. maybe he can return, I wou
On Wed, Feb 05, 2025 at 01:06:59AM +0100, Riccardo Mottola via macports-dev
wrote:
> Hi Ken,
> [...]
> Without you, no TenFourFox on Intel and also no ArcticFox on Macs.
Ooh, that's ineresting. I just tried to install TenFourFox
on intel 10.6 and it complained that it's only
Hi Ken,
Thanks for all the fish. It's much appreciated.
cheers,
raf
On Tue, Feb 04, 2025 at 09:44:24AM -0800, Ken Cunningham
wrote:
> First of all, I’ve been pretty strongly attacked, as you can see.
>
> Gagan has been around MacPorts for about two or three months. He has two
being said — and not strictly because of that interaction, but in
respect to other general life events, I have re-evaluated how I choose to spend
my time. Life is short, as we all know, and there are only so many hours in the
day. I have resigned from the MacPorts’ committer team, and deleted
imap was evicted from PHP core in version 8.4;
php83-imap and later subports are now found in the separate php-imap
Portfile.
Author: BjarneDM
Date: Tue Feb 4 23:59:41 2025 +0100
php-imap for php83 & php84 moved to separate Portfile
On branch php84
Changes to be committed:
. this was over a couple of weeks!
the github exchange is quite clear:
https://github.com/macports/macports-ports/pull/2603
they continued to repeat the falsity of all nodejs using the bundled libuv on a
bug ticket: https://trac.macports.org/ticket/71475
-again for the umpteenth time
Ken,
This was sad news indeed! I’m sorry, but respect your decision.
I had not much, if any at all, to contribute to the issue(s) of dispute.
However, I found the personal attack on you from this individual utterly
appalling.
I’m not aware of MacPorts have a Code of Conduct, a commonly used CoC
I've started working on php84 - 8.4.3
https://github.com/BjarneDMat/macports-ports/tree/php84
Author: BjarneDM
Date: Tue Feb 4 17:12:53 2025 +0100
1st version / try updating to stable version of php84 (8.4.3)
On branch php84
Changes to be committed:
mod
Please close https://trac.macports.org/ticket/51310 as fixed. Thanks.
These extensions havent been updated to php84
Error: Port php84-APCu not found
Error: Port php84-igbinary not found
Error: Port php84-imagick not found
Error: Port php84-imap not found
Error: Port php84-lzf not found
Error: Port php84-mailparse not found
Error: Port php84-mcrypt not found
Error: P
Joshua Root wrote:
By my count, 3 committers other than me have expressed unambiguous
support for dropping Tiger, and 0 have expressed opposition. That's
probably as clear a consensus as we're going to reach.
Although understandable from the point of who does the "hard work", it
is not a cle
On Fri, Jan 31, 2025 at 12:35:51PM +1100, Joshua Root wrote:
> By my count, 3 committers other than me have expressed unambiguous support
> for dropping Tiger, and 0 have expressed opposition. That's probably as
> clear a consensus as we're going to reach.
>
> - Josh
:(
Hi,
I long had issues seen from 10.5 to 10.7 with text display in Aqua GIMP
with gtk (and other apps too, but not e.g. Emacs).
It somehow "cured" itself on 10.7 but not 10.6/10.5
Today with a selfupdate broke
This combination works:
pango 1.48
librsvg 2.55.3
I held pango frozen to 1.48, or
Hi Ryan,
Ryan Carsten Schmidt wrote:
On Jan 26, 2025, at 18:25, Gagan Sidhu wrote:
Gagan, I'm pretty close to permanently banning you from this project. Ken is a
valued contributor and doesn't deserve your insults. MacPorts is a community
where people volunteer their time to m
just by organizing the code
better.
Wonderful!
I don't actually *use* 10.4 for anything myself, but I do support it
and test it, just for the benefit of people who do. When the
PowerBook that I used to use for PPC testing died, I spent my own
money on a used G4 Mini, as well as u
, git, subversion, to be able to work on 10.4. So e.g. I can use
a good version manager and connect with github repositories and test
code on the old system.
Without MacPorts that would be very hard.
But "upgrading" linux would defeat that.
Also, I have a PowerBook running Linux to t
ed behaviour.
>
> Gagan, I'm pretty close to permanently banning you from this project. Ken is
> a valued contributor and doesn't deserve your insults. MacPorts is a
> community where people volunteer their time to make things better for other
> Mac users, ostensibly beca
nightmare of
his own creation, since he loves playing hero ball?
he has previously conceded there are header clashes with his macports-libcxx
contribution that prevent people from using the legacy portgroup flag the way
it was intended, where the workaround is manually linking the library “by hand
ate me.
> On Jan 26, 2025, at 4:58 PM, Gagan Sidhu via macports-dev
> wrote:
>
> took you how long to think of a recovery, which is embedded with lies?
>
> rootie, are you going to do something about this pathological liar? should i
> dig up the tickets where he makes bas
y obvious, when someone gathers your
responses and attitude towards me, where it’s coming from.
be very careful.
> On Jan 26, 2025, at 4:51 PM, Ken Cunningham
> wrote:
>
> MacPorts defaults all builds on 10.6 to libc++, and has done for YEARS now,
> exactly so that supporting
; and that reality could not possibly have changed ever since.
>
> As a matter of fact, it is 10.6 on Intel that is completely hacked in
> MacPorts, and uses C++ runtime which Apple never had on 10.6. There is no
> such a thing as libc++ on 10.6. If you insist on ritualistic preservat
ould fix any problems on OS versions older
> than current-2. So practically speaking, this would mean removing all
> workarounds for 10.4 from base in the next major MacPorts release, closing
> all 10.4 specific tickets as "wontfix", and beginning the process of
> removing wor
is reasonable to expect that MacPorts on PowerPC
implies at least 10.5.8.
no, to be honest it is not "reasonable", although convenient.
Unfortunately 10.5.8 is a buggy/bloated OS. While very nice to look at
and it has the "beginnings" of new APIs that make it a little bi
speaking, this would mean
removing all workarounds for 10.4 from base in the next major MacPorts
release, closing all 10.4 specific tickets as "wontfix", and beginning
the process of removing workarounds for 10.4 from ports as they are
updated.
I use MacPorts on 10.4 for basic st
jimmy this isn’t twitter. you act like these shit processors are worth wasting
breath over.
save me with your benchmarks. i have no time for enthusiasm over inferior
architectures.
i tolerate powerpc, but this? i will not.
> On Jan 8, 2025, at 4:05 PM, Jimmy Yuen Ho Wong wrote:
>
> That's go
>>> These scripts have worked perfectly for years.
>>>
>>> They work fine for me now, and on all the buildbots.
>>>
>>> Please explain or demonstrate exactly what problem you believe you are
>>> experiencing. The problem is most likely in your
i think it’s an old and unneeded workaround for newer clangs. could someone
look into this?
i know that it’s not needed for newer clangs and, if anything, will frustrate
any potential users from staying with our package manager.
in my experience i’ve found this macro to be more of a hindrance t
ed to be here, as i have noticed others previously discussing 17664:
https://lists.macports.org/pipermail/macports-users/2021-April/049896.html
https://macports-tickets.macosforge.narkive.com/8GOtVcmE/macports-55008-py27-cython-0-27-1-does-not-build-on-snow-leopard-mac-os-x-10-6-8-after-upgrading
T
needs to link to macports-libcxx on lion with a newer
compiler, and i was hoping someone would have pushed a nice tidy solution for
this.
Thanks,
Gagan
Hi,
Ken Cunningham wrote:
https://trac.macports.org/ticket/71601#comment:3
and I mentioned there I had also noted that error here:
https://trac.macports.org/ticket/71503#comment:5
So I think we can makehttps://trac.macports.org/ticket/71601 about this.
And it may turn out to be a problem,
Hi!
I am churning updates on all my three 10.5 systems!
I just finished compiling gcc 14 on my PPC today.. even if it is a 2x
1GHz G4 with 2GB of RAM it took quite a bit. The first attempt froze the
terminal, so I restarted using xterm and it worked - maybe just by luck.
It also proves that
Hi,
I noticed the gcc14 upgrade has been merged. I previously tested it on
10.5 x86 and succeded.
Now I want it "official". On the system where I tested, I swhichted
again to rsync repository, hiding the github one, and am rerunning
upgrade... it is running.
On 10.5 PPC it is compiling lib
From: Ryan Carsten Schmidt
Date: Monday, December 16, 2024 at 3:52 PM
To: Langer, Stephen A. (Fed)
Cc: macports-dev@lists.macports.org
Subject: Re: testing a patch
On Dec 16, 2024, at 13:28, Langer, Stephen A. (Fed) wrote:
>
> I copied the Portfile to a directory in a local repositor
I hope this isn’t too dumb a question -- I’d like to test a patch to an
existing port to see if it fixes a problem I’m having. I copied the Portfile
to a directory in a local repository, put the patch in the files subdirectory,
and added a “patchfiles” line to the Portfile. But when I try t
on}.sdk
depends_build-appendport:MacOSX${configure.sdk_version}.sdk
}
The port uses C++17 so it needs a newer MacPorts clang. MacPorts picks clang-17.
The port uses cmake and ninja and it fails:
-- Check for working C compiler: /opt/local/bin/clang-mp-17
-- Check for working C compiler:
So the very first thing that someone should do is fix these three ports
libgcc8
libgcc10
libgcc11
See
https://github.com/macports/macports-ports/commit/eea28397c811c477a04407cbe3c105c76efd9219
https://github.com/macports/macports-ports/commit/06e249f837f36a877ea5dc0dd67d7b0caf964c40
On 21/11/2024 3:34 pm, Chris Jones via macports-dev wrote:
likewise, if I look at the compilers PG
https://github.com/macports/macports-ports/blob/master/_resources/
port1.0/group/compilers-1.0.tcl
the list there is also already restricted to
lappend gcc_versions 5 6 7 8 9
if I am
likewise, if I look at the compilers PG
https://github.com/macports/macports-ports/blob/master/_resources/
port1.0/group/compilers-1.0.tcl
the list there is also already restricted to
lappend gcc_versions 5 6 7 8 9
if I am parsing things correctly.
So, where exactly are the gcc
On 21/11/2024 3:11 pm, Chris Jones via macports-dev wrote:
On 21/11/2024 3:02 pm, Ken Cunningham wrote:
On 2024-11-21, at 6:56 AM, Chris Jones wrote:
On 21/11/2024 2:49 pm, Ken Cunningham wrote:
On Nov 21, 2024, at 6:44 AM, Chris Jones
wrote:
On 21/11/2024 2:44 pm, Ken
On 21/11/2024 3:02 pm, Ken Cunningham wrote:
On 2024-11-21, at 6:56 AM, Chris Jones wrote:
On 21/11/2024 2:49 pm, Ken Cunningham wrote:
On Nov 21, 2024, at 6:44 AM, Chris Jones wrote:
On 21/11/2024 2:44 pm, Ken Cunningham wrote:
On Nov 21, 2024, at 1:29 AM, Chris Jones via macports
On 21/11/2024 2:49 pm, Ken Cunningham wrote:
On Nov 21, 2024, at 6:44 AM, Chris Jones wrote:
On 21/11/2024 2:44 pm, Ken Cunningham wrote:
On Nov 21, 2024, at 1:29 AM, Chris Jones via macports-dev
wrote:
OOTH: If gcc10 is available and installed, why would you want to call in a
On 21/11/2024 2:44 pm, Ken Cunningham wrote:
On Nov 21, 2024, at 1:29 AM, Chris Jones via macports-dev
wrote:
OOTH: If gcc10 is available and installed, why would you want to call in a full
build of gcc13 unnecessarily to build the port?
If you are suggesting the builds should
OOTH: If gcc10 is available and installed, why would you want to call in a full
build of gcc13 unnecessarily to build the port?
If you are suggesting the builds should check to see what the user has
installed and pick a compiler based on that, then no, absolutely not.
That is just introduc
ne has more to say about it or thinks of some reason why something should be adjusted.I would continue to prefer the list be macports-wide, even if that means gcc13 instead of gcc10, or if one more gcc needs to be added. But we won’t bring down progress on the older systems arguing about that if tha
ne has more to say about it or thinks of some reason why something
>> should be adjusted.
>>
>> I would continue to prefer the list be macports-wide, even if that means
>> gcc13 instead of gcc10, or if one more gcc needs to be added. But we won’t
>> bring down prog
’ll leave this sit for a while while we see
> if anyone has more to say about it or thinks of some reason why something
> should be adjusted.
>
> I would continue to prefer the list be macports-wide, even if that means
> gcc13 instead of gcc10, or if one more gcc needs to be a
Hi,
Ken Cunningham wrote:
gcc48, gcc5, gcc6, gcc7, gcc10, and gcc14
This list seems workably short. I’ll leave this sit for a while while
we see if anyone has more to say about it or thinks of some reason why
something should be adjusted.
I would continue to prefer the list be macports
Hi,
Ken Cunningham wrote:
Any concrete example of something gcc-14 breaks that gcc-13 builds?
and that "only" gcc13 builds and gcc10 cannot build. You are not
proposing to remove all compilers.
Riccardo
Hi,
Ken Cunningham wrote:
apple-gcc42 stays, of course. unique and needed on 10.4
gcc4.8 … tenfourfox
and potentially for "other" old code.
gcc5 … for the java compiler used in pdftoolkit on older systems
Didn't know that... I don't know that port. No way it works with gcc 4.8
or 6.5?
gcc-4.8, gcc5, gcc7, gcc10, and gcc-14.
All those already build on the older systems, and are at least a manageable
list of versions to maintain.
Could we ask for thoughts and possible get consensus that the list of gcc
compilers supported by MacPorts be shortened to a list such as that?
Making th
, and are at least a manageable
list of versions to maintain.
Could we ask for thoughts and possible get consensus that the list of gcc
compilers supported by MacPorts be shortened to a list such as that?
Making this list is I think a trade-off between a newer compiler
breaking old code an
> dependencies at an absolute minimum, and especially with x11.
> But, of course, your mileage may vary :)
>
> Thank you for your input!
> Vincent
>
This seems relevant to my PR 26062:
https://github.com/macports/macports-ports/pull/26062
>>> I have the Python 3.12 and the matching PyObjC ports installed:
>>>
>>> ~ ❯ port installed python312
>>> The following ports are currently installed:
>>> python312 @3.12.7_0+lto+optimizations (active)
>>> ~ ❯ port installed py312-pyobjc
>>> The following ports are currently installed:
>>> py312-pyobjc @10.1_0 (active)
>>>
>>> As far as I know the py312-pyobjc port should provide this Quartz
>>> module, but this doesn’t work on my machine:
>>>
>>> ~ ❯ /opt/local/bin/python3.12
>>> Python 3.12.7 (main, Oct 5 2024, 01:39:55) [Clang 16.0.0
>>> (clang-1600.0.26.3)] on darwin
>>> Type "help", "copyright", "credits" or "license" for more information.
>>>>>> import Quartz
>>> Traceback (most recent call last):
>>> File "", line 1, in
>>> ModuleNotFoundError: No module named ‘Quartz'
>>>
>>> Does anyone know if this should work, or if I need any additional
>>> dependencies to get ‘import Quartz’ to work on macOS 15 with MacPorts
>>> Python 3.12?
>>>
>>> Thanks, Nils.
>
that users are able to build “any software you want”, but
>>> only with some involved _EDITS_ of the _CURRENT_ portfiles of the
>>> aforementioned ports.
>>
>>> are we expecting the macports user to know how to do all of this?
>>
>>> with some maintenan
Are the runners arm64 or x86_64 ? We have the buildbot for x86_64 macOS15 so
enabling runners for that should be OK I would guess.
> On 1 Oct 2024, at 4:09 am, Joshua Root wrote:
>
>
>>
>>> On Mon, Sep 30, 2024, at 7:51 PM, Ryan Carsten Schmidt wrote:
>>> > On Sep 30, 2024, at 18:47, Mark
ports.
>
>> are we expecting the macports user to know how to do all of this?
>
>> with some maintenance of existing portfiles for popular software, i think
>> macports popularity could increase significantly
>
> Certainly it is not expected for *every user* to need to kno
and probably 20 if it has the same
issues as the other two) and using your macports-libcxx.
>
> To a limit, we can work around these changes sometimes.
>
> But there comes a point where the compatibilty code is too unweildy and
> burdensome to maintain, and when that happ
thanks for the thoughtful response. just before i follow-up, i wanted to make
clear it wasn’t my intention to intertwine my position in libcxx with the
specific ports i mentioned earlier.
also, whilst you have distinguished libcxx from macports-libcxx, i think the
important thing is to
> On Sep 28, 2024, at 11:14 PM, Ken Cunningham
> wrote:
>
>
>
>> On Sep 28, 2024, at 8:47 PM, Gagan Sidhu via macports-dev
>> wrote:
>>
>
>> in my opinion, and while it’s clear the lack of weak references and thread
>> local storage in
installed on
> 10.7, 10.8, 10.9, or 10.10. I forget about where it comes in -- 10.13 is my
> best guess.
gotcha
>
> For any of those systems where libc++ is too old, we use macports-libcxx. It
> has some warts -- certain things break when using macports-libcxx. But most
> thin
i just wanted to follow up on this a little.
i noticed that *macports-libcxx* is the ‘good one’ and libcxx is the ‘old one’.
macports-libcxx+universal takes quite a while to install since it builds
llvm-11 from scratch, but i suspect it’s worth it.
i think a discussion needs to happen to
does anyone know why the APPUL gdb resolves the symbols in the binary, but the
newer GDB from ports does not?
i thought maybe it was because i didn’t have the universal binary, but now i
have that too (lol).
it’s way better, and my eyes have been opened to its realtime display of thread
spawni
hi all,
so with a little effort (not too much, mind you), i did manage to get
lldb-mp-5.0 built/installed in my vm.
the changes were very small, like:
- removing the .sdk member in one of the files,
- changing the @YES @NO definitions to @true @false since the 10.7.5
SDK uses d
The warning g is there for a reason. Just follow the instructions as given….
> On 27 Sep 2024, at 10:24 pm, Gerben Wierda wrote:
>
> The last update of MacPorts gets me a failure on a fresh install of rspamd on
> a further empty MacPorts (macOS Sonoma, latest update):
>
>
.1
and
> [legacysupport::get_library_link_flags]
in the LDFLAGS.
i assumed that meant it was included. or must
> legacysupport.use_mp_libcxx yes
still be added?
Thanks,
Gagan
> On Sep 25, 2024, at 2:05 PM, Ken Cunningham
> wrote:
>
> check out:
>
> https://
++ from newer llvms to supplement
the older /usr/lib/libc++ to take our game to the next level.
of course it may not be that simple. i’m far from a compiler expert,
acknowledge the library name clash of /usr/lib/libc++ and the static in
/opt/local/libexec/llvm-, and this may be what the macports
found the issue fred! it’s my kext that was attempting to patch the fdexec
issue from 10.7 that doesn’t exist in 10.8
it needs a little more work!
sorry about this!
Thanks,
Gagan
> On Sep 23, 2024, at 9:44 PM, Gagan Sidhu via macports-dev
> wrote:
>
> i guess my victory decla
again to install all the dependencies for lldb-5.0, it
arose on openssl-3.20.
- doesn’t seem to be a specific port. something up with 11g63, ports,
and bsdtar.
strange i know, but i thought i should share this.
Thanks,
Gagan
> On Sep 23, 2024, at 9:12 PM, Gagan Sidhu via macports-
at 7:57 PM, Fred Wright wrote:
>>
>>
>> On Mon, 23 Sep 2024, Gagan Sidhu via macports-dev wrote:
>>
>>> anyone else get this?
>>>
>>> and it just is stuck at the assembly file:
>> [...]
>>
>> I don't see that on 10.7 here,
1 - 100 of 489 matches
Mail list logo
