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,
the mach_kernel that i
replaced) that needed restoration.
but perhaps this caused an issue.
will look into it. thanks.
Thanks,
Gagan
> On Sep 23, 2024, at 7:57 PM, Fred Wright wrote:
>
>
> On Mon, 23 Sep 2024, Gagan Sidhu via macports-dev wrote:
>
>> anyone else ge
L_ASM -DECP_NISTZ256_ASM -DGHASH_ASM -DKECCAK1600_ASM
> -DMD5_ASM -DOPENSSL_BN_ASM_GF2m -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5
> -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DPOLY1305_ASM -DRC4_ASM -DSHA1_ASM
> -DSHA256_ASM -DSHA512_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DX25519_ASM
>
lable, so it
could be its just too old for macOS15. Can you please try forcing any
build that is falling back to using clang-17 to use clang-18 and/or
clang-19 instead ? you can do that by appending
configure.compiler=macports-clang-18
to your port install command, e.g.
> sudo port ins
I am puzzled as to why SuiteSparse_GraphBLAS drags in clang17 and
SuiteSparse_LAGraph drags in both clang16 and clang17 as build
dependencies. I don't see anything in the SuiteSparse Portfile showing
those dependencies.
See this line
https://github.com/macports/macports-ports
tensions running high lads!
it’s like APPUL’s (now) piece of shit operating system and kit (SDK) problems
have finally had the proper effect on the endless abuse over the past decade
plus.
let’s cool ‘er down and not talk about Napster (linux), shall we?
i’d rather us flog the stupid brand th
ote:
>
> Currently nothing in MacPorts sets libdir for CMake ports. On MacOS this is
> no issue. On Linux this leaves multiple ports broken, since CMake throws libs
> into ${prefix}/lib64, where nothing looks for them, so all dependents are
> broken.
> As a few examples: libd
sary toolchain via rustup. That worked like a charm, and it fact it
> still does on Linux. Annoyingly builds that succeeded a year ago now fail on
> Mac (under 10.9) with a SEGV under fseek64 or a similar syscall, without any
> incrimination of an updated dependency in MacPorts. Several ho
I figured it out. Thanks all!
https://github.com/macports/macports-ports/pull/24978
> On Jul 18, 2024, at 12:47, Joshua Root wrote:
>
> Yes. If you want to use a Portfile with subports that isn't in an indexed
> location listed in sources.conf, you have to both specify
So do I have to have the dports directory generated by pypi2port in my
sources.conf in order for them to be detected?
> On Jul 18, 2024, at 10:57, Renee Otten wrote:
>
> I would recommend trying to use the “upt” package (available in MacPorts) to
> generate Python portfiles, bu
Hello,
I’m trying to package a Python module. I found the port pypi2port, which does
generate a basic Portfile for me, but when I try to build the port, it gives me
a puzzling error:
> ---> Computing dependencies for py-fmf
> Error: Dependency 'py311-fmf' not found.
The entire Portfile is:
On Sat, Jul 13, 2024 at 1:58 AM Richard L. Hamilton wrote:
>
>
>
> > On Jul 13, 2024, at 01:46, Daniel J. Luke wrote:
> >
> > On Jul 12, 2024, at 4:54 PM, David Gilman wrote:
> >> Is there any opposition to dropping all unsupported PostgreSQL
> >&
Hi,
Sergio Had wrote:
I have finally built the thing and it works, from looks of things, but
I get a message on startup:
36-25%
/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_java_openjdk8/openjdk8/work/jdk8u-jdk8u372-ga/build/openjdk8/images/j2sdk-image/bin/java
-version
2024-07-09
.
Best regards,
Nicklas
[1] https://github.com/macports/macports-ports/pull/23462
> On 12 Apr 2024, at 08:33, Nicklas Larsson via macports-dev
> wrote:
>
> I have now put up a PR [1] to address this PROJ issue. The changes I propose
> to make are in summary:
>
> - ren
;
>> Thanks,
>> Gagan
>>
>>> On Jun 10, 2024, at 10:17 AM, Ken Cunningham
>>> mailto:ken.cunningham.web...@gmail.com>>
>>> wrote:
>>>
>>> Yes but I still don't see -lobjc on your link line...
>>>
>>> K
>
ink line...
>>
>> K
>>
>>
>>
>>> On Jun 10, 2024, at 9:15 AM, Gagan Sidhu via macports-dev
>>> mailto:macports-dev@lists.macports.org>>
>>> wrote:
>>>
>>> oh does the list parse out indented comments? if so my apolo
progressui_osx.o:(symbol OBJC_METACLASS_$_UpdaterUI+0x8)
>>> referenced 1 more times
with or without -lobjc
Thanks,
Gagan
> On Jun 10, 2024, at 10:14 AM, Ken Cunningham
> wrote:
>
> I can't see lobjc on the link line.
>
> Could you show us a failed
to help if we can see the link line you're using, but in short
>> you need to make sure that lobjc is in the link libs, sometimes by
>> explicitly adding it:
>>
>> LDFLAGS="$LDFLAGS -framework Cocoa -lobjc"
>>
>> K
>>
>>> On Jun 1
hi team,
first of all, i just built the clang-18 properly and wow am i amazed. here i
was asking about wasm and stuff, i should have been a little more thorough, my
bad.
-really this thing is a work of art. great yob
now to my question, which i also posted to
stackexchange(https://stac
hi marcus,
thanks for getting back to me.
what i find interesting is, in spite of your 10.14 target, the macports rust
compiler seems to reduce the warnings compared to the firefox toolchain’s
(which uses a 10.12 target).
for example these are the warnings when i use the firefox toolchain
hi marcus
i’m working on making a firefox that works all the way back to 10.9
right now i am using it on 10.14 without issue, and i think the only thing left
is ensuring rust honours my macosx_deployment_target
it seems rustc from macports (1.77.1) honours this variable for the most part,
but
… let’s just say… um, imaginative.
\m/
Thanks,
Gagan
i see you valerio! be ready dawg!
> On May 24, 2024, at 10:08 AM, Gagan Sidhu via macports-dev
> wrote:
>
> do we got it?
>
> tried a few a week ago and it seems like we don’t, as the firefox mach build
> system would fa
… let’s just say… um, imaginative.
🤘
Thanks,
Gagan
> On May 24, 2024, at 10:08 AM, Gagan Sidhu via macports-dev
> wrote:
>
> do we got it?
>
> tried a few a week ago and it seems like we don’t, as the firefox mach build
> system would fail at the webassembly checks for
do we got it?
tried a few a week ago and it seems like we don’t, as the firefox mach build
system would fail at the webassembly checks for clang.
Thanks,
Gagan
Hi,
Sergey Fedorov wrote:
Some on MacRumors, for instance; quite likely that those who are on
KDX and Hotline also run those on 10.4–10.5, though I have no
statistics on that.
this is a little off-topic and gave me a little tear. Hotline and KDX
were my thing many years ago, like more than 2
Hi!
Kirill A. Korinsky wrote:
Keep in mind that suggested method removes support osx keyring from that
system. User still be able to use SSH-based auth or enter password by hand
for HTTP-based push.
My point: I assume that nobody uses HTTP-based auth on git on 10.5 and 10.6,
I do not assume tha
Hi,
I have a situation where I am unable to upgrade cleanly on my MacBook,
took me a bit to realize.
In the past, I had a complete systems, maybe also helped to have Ken's
ports overlay.
While doing upgrade, I am stuck on several rebuild failures (not
installing anything new). One is:
http
Hi,
Kirill A. Korinsky wrote:
I really doubt that anyone care about of macOS 10.6 these days with
exception for a few folks in the world, and probably half of them read this
mail list:)
But propose a patch for git isn't bad idea, indeed.
I care for 10.5 and 10.6, but I read this mailing list
dependant.
Nicklas
[1] https://github.com/macports/macports-ports/pull/23462
> On 9 Sep 2023, at 09:43, Sergey Fedorov wrote:
>
> This just amounts to switching the existing proj port from proj5 to the
> latest.
>
> On Sat, Sep 9, 2023 at 12:26 AM Dave Allured - NOAA Affiliate v
Hi,
I actually agreed with you, just skip from gcc7 to gcc13.
Ken Cunningham wrote:
Just yesterday I fixed gcc10-bootstrap to build on Tiger PPC and pushed that to
master, which required YA new bootstrap compiler. So the parts are now in place
for the attempt.
ohhh :) it took me 4 days to g
Hi,
Ken Cunningham wrote:
Up to now, though, older systems have used gcc7, and in a few cases gcc5 or
gcc48 are used for specific issues. So those gcc versions may still be needed
... time will tell.
for me it is gcc48 (or apple 4.2 on tiger or such) for old software.
gcc6 covers most needs
Hi,
I use meld to compare and develop, especially ArcticFox against full
Gecko tree. I don't know if there are alternatives, but it proves to
handle big trees and also complicated compare details. However, it is
highly complex in its dependencies being in python, gtk3 and related.
There was a
Hi,
Ryan Schmidt wrote:
I propose to keep even versions, because they are stable ones
Do you have a source for this claim? It's the first I've heard of it. As far as
I know, all gcc version numbers are stable.
I did a quick search and couldn't find one. It is something I pked up
years ago
Hi,
Ken Cunningham wrote:
To have libgcc7, the way it is now, you need to build libgcc13, 12, 11, 10, 9,
8, and then 7.
That is -- a lot of gcc building for a questionable benefit.
on my PowerMac dual-G4 about a week of compilation, given the time to
build gcc8...
But I understand we alwa
Hi,
Ken Cunningham wrote:
My only question is whether to skip over gcc8-12, or include them.
If we skip over gcc8-12, we can probably have a new release that uses
gcc13 as the primary gcc on all systems in macports done by Monday.
Less maybe. Last time I jumped the version, it took me an
Hi,
Sorry - I missed these replies, ended up in the wrong mail folder. Was
about to re-write!
We had discussions in many points, tickets, ecc... lots of different
opinions.
Sergio Had wrote:
You should not need gcc8. I had gcc11 working on 10.5 ppc (and ppc64
too). I have seen people using
endency if the new
dependency isn't yet available via "port upgrade"?
Thanks.
-- Steve
From: Joshua Root
Date: Sunday, March 31, 2024 at 10:42 PM
To: macports/macports-ports
Cc: Langer, Stephen A. (Fed) , Mention
Subject: [macports/macports-ports] Update ImageMagick to 6.9.13-
fails (and ultimate goal is to enable newer
gccs on PPC too, where it is needed)
:info:build cc1plus: warning: '-mdynamic-no-pic' overrides '-fpic',
'-fPIC', '-fpie' or '-fPIE'
:info:build
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsyn
so, I'm on macOS 10.15.7 Catalina.
according to https://ports.macports.org/port/openjdk22/builds/ openjdk22
fails to install on anything lower than macOS 11 Big Sur.
when I try to build it, I get the following at the end of main.log :
==>
/opt/local/var/macpo
Hi,
I just noticed this on 10.5 intel 64bit... Often I don't check the
console so I don't know if it is fresh.
Artax:~ multix$ wget
https://github.com/macports/macports-ports/archive/70b148d6b0c465b2483ca2d6f9a12fb0841d639e.zip
wget(77577) malloc: *** error for object 0x7fff7020c200
Hi Ken,
Ken Cunningham wrote:
> the cmake port is very very far behind.
>
> cmake-devel has been updated to the newest version currently available
> (3.29.0) for most systems, and then newest supportable (3.28.4) for 10.7
> and < 10.6.
>
I deactivated cmake and installed cmake-devel as test on
rote:
>
>> I also think that the `ruby` port needs to be renamed to `ruby18` and `port
>> install ruby` should *either* fail (like `port install python` or `port
>> install python3` does) or it should install the latest stable version
>> (updated on Christmas Day every y
Hi,
Sergio Had wrote:
Could you refer me to the beginning of this discussion please?
it started on the Mac Users mailing list, you can find in the archives!
I am also involved in AF project:)
Oh, I am curious, how?
I am essentially the only active developer currently, except Roy who
does
Hi,
Joshua Root wrote:
(Moving to macports-dev as it is a better fit for this topic.)
indeed, it is a development issue, although well, not for a MacPorts
package (yet?) but use of MP development tools.
Issues that only appear at higher optimisation levels also often
involve undefined
On 3/14/24 10:33 AM, Riccardo Mottola via macports-dev wrote:
What app(s) do you use?
can you please give a try to 'ReSolve':
https://github.com/efa/ReSolve
depends on GTK3.
I normally create binaries and DMG for x86_64,
targeting Quartz, last one is:
https://github.com/efa/ReSolv
1 - 100 of 445 matches
Mail list logo
