Re: Git-devel has broken git-credential-osxkeychain.c for older systems
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 20? Trusty 68k systems and first PPCs on classic. Dial-up! Young and broke I got stuff from it like compilers, libraries and music. Now I have systems are obsolete but at the time I could only dream of :) Nice connections with hackers, it was a good community! But with the end of classic I supposed the end of it! Besides the big mess of the "evil" company, the disappearing programmer, unofficial clients... Or are they using blue box on PPC??? However, to stay on topic, is if those people just like to run some legacy software or try to have some current tools, like current git. I don't know anything about this community anymore, so I can't say. Riccardo
Re: Git-devel has broken git-credential-osxkeychain.c for older systems
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 that nobody uses git, only HTTP-based auth. well... the majority of github users? Since they switched (me and I don't know if everybody else) to a token, it is impossible to remember, so it needs to be saved. Up to then, I didn't mind typing passwords. I suppose the solution of storing to a textfile remains, but well... Riccarrdo
py-numpy and 32bit systems
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: https://trac.macports.org/ticket/69199 which is I understand related of this: https://trac.macports.org/ticket/66685 py-numpy doesn't build in its openblas variant on 32bit intel. Of course, best would be to fix it :) Second would be: how can I get the dependency chain? that is, why do I need it? I tried rdepof / rdependentof / rdepends and always get itself. I don't like nor use python, so any installed port of it is always a dependency :) Understanding what it needs would answer if it needs the openblas variant or not. Riccardo
Re: Git-devel has broken git-credential-osxkeychain.c for older systems
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 :) Probably most people developing or using these systems is on this mailing list. Others may be using them but with old software only, not trying to run latest on it. git/ssh/svn are some base tools we need to interact with repositories on all systems. Riccardo
Re: 10.5 and gcc8 x86-64 ok but ppc bails with dlerror
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 get libgcc7 and gcc7 on Tiger from scratch ... wanted to report that separately... older systems are slow :) If everyone wants all the gcc versions supported, we can do that. I don't care -- it's just a lot of building (and also fixing that will need to be done, but I presume you'll pitch in on the fixing of the broken gcc versions). well... if you have gcc10 fixed, can we do gcc7-gcc10+gcc13 ? I suppose that if we need an in-between compiler it can be added later? What about adding more stubs? Riccardo
Re: 10.5 and gcc8 x86-64 ok but ppc bails with dlerror
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 and gcc7 is "current". Who knows, maybe gcc13 replaces gcc7 in all its uses. Or maybe later we can add gcc8 or whatever. Let's switch? I hope gcc's can be added later, maybe even with libgcc stupped? If we do it today or tomorrow, I can leave my G4 building :-P Riccardo
issues with meld and python, full 99% forever
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 time when it worked well on 10.6, 10.7 and 10.11 up to 10.13, the only systems I have at hand. About 1-2 years ago, don't remember exactly. Then degradation happened of different nature 1) refresh of the file tree started to be bad, some items do not display, maybe on the left or the right side, rarely both. However, everything was functional and clicking on a file, even if not visible, got a correct compare 2) on 10.6 and 10.7 it stopped completely working, the main windows doesn't open anymore Yet on 10.11 and later, except the refresh issue, it continued working. Nice. Then 3) comparison of files takes 99% CPU forever. I waited for hours and see the python process there. However retrying sometimes help with another file. Sometimes, closing the offending file comparison yields back the CPU, sometimes not, hinting to some hanging. thread or so. I use meld on Linux and it works and doesn't have this problem. I tried enabling/disabling syntax highlighting and it is not related. I fear there is something that breaks python or broken in python itself. I don't know if problem 3) and 1) can be reproduced with small repositories. Someone said on 10.14 there were no issues, it needs to be tested again. Are there python tests to be run ? Maybe they could help diagnose. Riccardo
Re: 10.5 and gcc8 x86-64 ok but ppc bails with dlerror
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 and is a bit corroborated by experience on compiling on dozens of systems. but no trace on the gcc time. Odd/Even was an old practice, possibly not followed anymore. Riccardo
Re: 10.5 and gcc8 x86-64 ok but ppc bails with dlerror
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 always build "latest available" (currently gcc13).. but I don't understand the chain. We need a newer library. I agree with you that having all in-between version is nice but too much of a compile burden! I have following ideas: 1) not jump to gcc13, but "just" to gcc8, gcc10 or whatever. Bandaid.. until we decide to raise the bar more! 2) do what you propose is gcc7 - gcc13 3) a "good sense" of some between versions. I propose even versions or a subselection of them. I propose 3) but an fine with 2... let's just update! Riccardo
Re: 10.5 and gcc8 x86-64 ok but ppc bails with dlerror
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 hour.
Is gcc13 tested enough? I fear that since we are left at gcc7 for a long
time, that's the tested one.
And then — no more worries. Existing macports base infrastructure will
just work as it is. Some fairly minor tweaking of what compilers are
available on which systems will be done.
If we have to fix all the gcc versions between gcc8 and 12 — well that
will take a bit more time to fix and to build.
6-7-13?
6-7-8-10-12-13?
6-8-13?
giving numbers :) Keep odd compilers only if it is the last current
available.
What's actually to "fix" later and add in-between gcc's if needed?
For Riccardo’s bug, we always knew the gcc JIT was fragile on 32 bit
systems. It probably needs to be disabled there by tweaking this block
in the gcc8
so you think the issue is 32bit ppc and I would have issues on 32bit
intel too? I need to fix that fan and test :)
Portfile:
if {${subport} eq "gcc8"} {
# the jit is not building on i386 systems
# seehttps://trac.macports.org/ticket/61130
if {${build_arch} ne "i386"} {
lappend gcc_configure_langs jit
}
}
Maybe that’s all it needs.
add ppc 32bit only?
Riccardo
Re: 10.5 and gcc8 x86-64 ok but ppc bails with dlerror
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 gcc13 on 10.5 ppc following my instructions from the PR. What is the point of gcc8? Some people think it is good to have all versions. Other voice for directly gcc13. Would we keep gcc6 in this jump? what we do with the working gcc7 we have? I propose to keep even versions, because they are stable ones and often found long-term in Linux and BSD distributions. If you think, we still tinker with gcc4.8, gcc6... but I never felt the need for gcc5 (although one never knows for stubborn pieces of software) I just started with gcc8 because it contains already some libc++ features I was needing without jumping to gcc13 and because it was the next logical attmept. It was just a test to see how things are set on intel and PPC. I make the question the other way around. We have this "gap" because these older platforms were not updated in their gcc versions regularly. Otherwise, I suppose, we would have all versions up to gcc13. When gcc14 comes out, what will happen? Keep gcc13 and use libgcc14? Other question: why do we have to "chain" all gccs so that having them all means building them all? I supposed I just need the ealierst ancestor which is capable of correctly compiling that said version of gcc. So If gcc8 (supposed, not tested) is enough to compile libgcc13.. why can't I just have gcc8 and gcc13... and later if I want install gcc10 or if I don't want, not? Just ideas (and dumb questions). Riccardo
10.5 and gcc8 x86-64 ok but ppc bails with dlerror
Hi, after all the talk about gcc versions, I tried to build gcc 8 here. Officially it says "gcc8 is known to fail". I first did just "build" on Intel 64bit and PPC 32bit - Intel 32bit later, I fear my MacBook has fan issues. Intel 64bit finished build! Took several hours. I thus tried to install it... and it says again "libgcc8 is known to fail. Try to install anyway?" and yes, it just built! However then it asks about libgcc9 but I want to stay on libgcc8, that was the point... am Inheriting that it will go up to gcc13? On PowerPC instead build 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_rsync.macports.org_macports_release_tarballs_ports_lang_gcc8/gcc8/work/gcc-8.5.0/gcc/jit/jit-playback.c: In member function 'gcc::jit::result* gcc::jit::playback::context::dlopen_built_dso()': :info:build /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc8/gcc8/work/gcc-8.5.0/gcc/jit/jit-playback.c:2599:3: error: 'dlerror' was not declared in this scope :info:builddlerror (); :info:build^~~ Already seen this? Full build log is 6.7MB Should I open a ticket on this or is there already one for gcc8 efforts? didn't find it. Riccardo
wget errors - malloc
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: non-page-aligned, non-allocated pointer being freed *** set a breakpoint in malloc_error_break to debug wget(77577) malloc: *** error for object 0x7fff7020c120: Non-aligned pointer being freed (2) *** set a breakpoint in malloc_error_break to debug --2024-03-27 10:37:25-- https://github.com/macports/macports-ports/archive/70b148d6b0c465b2483ca2d6f9a12fb0841d639e.zip Resolving github.com (github.com)... 140.82.121.4 Connecting to github.com (github.com)|140.82.121.4|:443... connected. HTTP request sent, awaiting response... 302 Found I'll test on other systems and see what happens and if there is a batter, but please test too. Riccardo
Re: cmake-devel --> cmake coming .... please test if you care to
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 10.5 intel 64bit, 10.7, 10.11 Build when file on all systems. I think the best test is using it during more upgrades... I don't remember off-hand which ports use to test. I hope that w e don't get red-herrings of failures on other packages due to that. > > https://trac.macports.org/ticket/67540 > > If you are a keener with debugging on 10.7, and can sort out a proper > fix for 3.29.0 on 10.7, upstream will love you. Most likely eventually > we/they will use the commits they added to the 3.28.N branch to fix it > for those systems, although those commits are more involved that we > usually like to carry. At a first glance I don't understand the issue, it looks like compiler/linker gets confused. If you want... we can try to tinker on it. Riccardo
Re: MacPorts vs. Apple compiler issues, Handle
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 its windows fork. Riccardo
Re: MacPorts vs. Apple compiler issues, Handle
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 behaviour. Right.. I reduced optimization to O1 with no change, I have strange issues compiling with O0! Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 XUL 0x00010f5468e1 nsWindowWatcher::OpenWindowInternal(mozIDOMWindowProxy*, char const*, char const*, char const*, bool, bool, bool, nsITabParent*, nsIArray*, nsIDocShellLoadInfo*, mozIDOMWindowProxy**) + 273 And this is where it happened. Since this is not a full debug build, there is no line number information, but you at least know which method is doing the bad memory access. But it should be a debug build. Well a build with debug symbols (not a firefox-style debug which adds also a lot of debug code). I add: ac_add_options --disable-strip and this helps on Linux usually. Still, the nsWindowWatcher class gave me a clue and I found a couple of Firefox patches to import which initialized parameters, checked them, etc and now the error changed to> 0 XUL 0x0001035f5c44 JS::Rooted::registerWithRootLists(js::RootLists&) + 20 1 ??? 0x7ffeecb477f0 0 + 140732869670896 this is bad, since it is inside the JS engine. Also the JS engine works on other system when compiled with modern clang and gcc! Also here I don't have a class name which maps directly to a file which I can easily inspect. I will try clang 7 & 8, just so. Riccardo
Re: GTK on PowerPC: does anyone have it actually working?
Hi, Ken Cunningham wrote: gtk3 (x11 variant) is working fine for me on PowerPC Leopard, for one. I'm hacking on GTK2 and GTK3 quartz support for Leopard... intel first, they were working well enough to get gimp starting up (gtk2...) The only other GTK3 app I use is meld, which is now unusable (doesn't even show a window) on 10.6 and 10.7, so I didn't even attempt on 10.5. on 10.11-10.13 it has heavy redraw issues (has since about a year). But it is really a maze of dependencies, so I don't know if the bug is in GTK or one of the many dependent libraries. I will try to build on 10.5 PPC tomorrow and see how things fare What app(s) do you use? Riccardo
mailing list "dev" vs "user"
Hi, up to now I didn't subscribe to "macports-dev" mailing list, even if I use and collaborate in MacPorts for years! Questions about bugs (e.g. discussions similar to track) belong to which list best? Is "dev" only for "macports" itself or also for the ports in it? I thought the former, then I checked the archives casually and noticed there is lot of discussion going on on the "dev" list including support for old systems, PPC, things about GTK and so which I just missed and I am active and interested in. Thanks, Riccardo
