C++ exception handling on PPC with gcc 6.4.0 doesn't work
I'm using gcc-mp-6 (MacPorts gcc6 6.4.0_0) from 2017 on a PowerPC MacOS system 10.5. For some reason, using C++ exceptions doesn't seem to work with the compiler. Whenever my program tries to throw an exception, it just hangs and I need to use Ctrl-C to kill it. Are C++ exceptions generally unsupported by the gcc-mp-6 version I'm using or is there any special compiler or linker flag that needs to be used to make C++ exceptions work with my gcc-mp-6 version? Any ideas? -- Best regards, Andreas Falkenhahn mailto:andr...@falkenhahn.com
Re: ld: can't write output file for architecture ppc
On 20.03.2024 at 00:00 Ryan Schmidt wrote: > As Josh explained, run: > port -v installed > If I wanted to downgrade from sqlite3 @3.45.2_0 which I installed > in March back to sqlite3 @3.45.1_1 which I installed in February, I would run: > sudo port activate sqlite3 @3.45.1_1 > If you reactivate all of the 2017 versions of your ports, you > should be back to where you were before trying to upgrade. Thanks, that really worked like a charm! I have deactivated and then uninstalled all 2024 ports and I can confirm that my old installation works again. Thanks a lot for the help! -- Best regards, Andreas Falkenhahnmailto:andr...@falkenhahn.com
Re: ld: can't write output file for architecture ppc
Macports-users wrote: > Are you on G3/G4 or G5 ? G5. > I would have a look at the linker, binutils and similar. But where should I look? When I examine /opt/local/bin it's pretty messy because 50% of the files have a timestamp of 2017 and the other half has a 2024 timestamp so it really looks like the installation is messed up because half of the components are from 2017 and the other half is from 2024. I don't see how I could restore my old installation here. Ironically, ld still has a 2017 timestamp so it looks like this is the correct old version but still it doesn't work. Probably because the MacPorts upgrade has messed up the installation... > When you upgrade, MacPorts will only deactivate the old versions of > ports (unless specifically told to immediately uninstall them). So you > should be able to activate the older versions to get back to the state > you were in previously. Hmm, how to do that please? As written above, /opt/local/bin is a complete mess as half of the components are from 2017 and the other half is from 2024. How should I restore the old versions here please? > does gcc fail when used outside MacPorts or does it always fail? Outside MacPorts gcc works fine. No problems with the gcc installed by Xcode but that is gcc 4.0.1. I installed MacPorts to get a newer gcc. -- Best regards, Andreas Falkenhahnmailto:andr...@falkenhahn.com
ld: can't write output file for architecture ppc
Hi, for several years I've been successfully using gcc-mp-6 on a PPC Mac running OS X 10.5. I installed MacPorts and gcc-mp-6 back in 2017 and haven't updated anything concerning MacPorts since. Now I wanted to install a new MacPorts package and in order to install the package it also forced me to update MacPorts. In hindsight that was a BIG, BIG mistake because of course it aborted somewhere in the middle of the update process and now it looks like my installation is f*** up because whenever I try to link something I now get the error: ld: can't write output file for architecture ppc gcc-mp-6 itself apparently is still working. I have compared the object files generated by it from before and after the attempted MacPorts update and they're identical but ld seems broken. Is there any way I can get ld back up and running? No, I don't have a backup of my old MacPorts installation, another mistake :( It's really annoying. I really could've sensed that updating a 2017 MacPorts installation on a 20 year old system nobody besides me is still using would never go through but still I tried... silly, silly me!! Any idea how I can get that fixed? -- Best regards, Andreas Falkenhahn mailto:andr...@falkenhahn.com
How to target older macOS version
Hi, I've installed MacPorts on a macOS 13 system but I'd like to build programs that run on all systems that have at least macOS 11. That's why I run gcc with the -mmacosx-version-min=11.0 argument. This, however, leads to warnings of the following kind during linking: ld: warning: dylib (/opt/local/lib/libfreetype.dylib) was built for newer macOS version (13.0) than being linked (11.0) ...more similar warnings for other dylibs installed by MacPorts... Is there any way to install the dylibs for macOS 11.0 on a macOS 13 system or how am I supposed to build MacPorts programs on macOS 13 that run on older macOS versions as well? -- Best regards, Andreas Falkenhahn mailto:andr...@falkenhahn.com
Re: Apple ARM binary codesign issue
On 12.01.2021 at 02:37 Ryan Schmidt wrote: > The automatic codesigning that the compiler/linker does must be > sufficient, because we're not doing anything beyond that with the > binary packages that MacPorts downloads when you install a port. Ok, that's good to hear. So the only benefit of codesigning seems to be to guarantee that binaries aren't modified. -- Best regards, Andreas Falkenhahnmailto:andr...@falkenhahn.com
Re: Apple ARM binary codesign issue
Slightly off-topic, but maybe someone here knows something about this: When distributing Apple ARM apps outside the App Store, is it sufficient to sign them using ad-hoc or self-signed certificates or is it mandatory now to pay the $99 per year even if the app is going to be distributed outside the App Store? On 30.09.2020 at 06:48 Andrew Udvare wrote: >> On 2020-09-29, at 15:02, Michael Dickens wrote: >> Excellent! Thanks for the heads-up. I've downloaded this file and will get >> it installed and start testing later today. - MLD >> On Tue, Sep 29, 2020, at 2:47 PM, Gary Palter wrote: >>> Apple today released Xcode 12.2 beta 2 and the Release Notes state >>>> Apple Clang Compiler >>>> Resolved Issues >>>> • Fixed an issue that caused strip, install_name_tool and vtool to >>>> corrupt the ad-hoc code signatures generated by the linker for arm64 >>>> Mach-O files. (51911417) >>> - Gary Palter >>> Principal Software Engineer >>> Clozure Associates >>> Cell: 617-947-0536 > Hi, > If you get a chance, could you try compiling this on your Apple Silicon > device? > https://github.com/Tatsh/re3/tree/macos (part of this PR > https://github.com/GTAmodding/re3/pull/734) > Once you clone it (with git clone --recurse-submodules --branch=macos): > cd re3 > port install --unrequested premake5 openal-soft glew glfw mpg123 > libsndfile (if this step fails, stop here and let me know) > premake5 --with-librw gmake2 > cd build > make config=release_macosx-amd64-librw_gl3_glfw-oal -j5 > Just want to see the output and find out if it can build > successfully. Does not need the GTAIII game anywhere to build. > Thanks -- Best regards, Andreas Falkenhahnmailto:andr...@falkenhahn.com
Re: How to resolve libstdc++.6.dylib dependency
On 24.03.2018 at 17:34 Mojca Miklavec wrote: > Sorry about the wrong advice about stdlib. No worries, I've had another idea. I can just link statically against libgcc and libstdc++, like so: -static-libgcc -static-libstdc++ This increases the executable size by about 1 MB but the resulting executable works like a charm on a naked 10.5 system without any Mac Ports stuff... very nice! -- Best regards, Andreas Falkenhahnmailto:andr...@falkenhahn.com
Re: How to resolve libstdc++.6.dylib dependency
On 24.03.2018 at 14:07 Mojca Miklavec wrote: > On 24 March 2018 at 13:35, Andreas Falkenhahn wrote: >> When I compile my C++11 project on a 10.5 PPC system using gcc6 and try to >> run it on another 10.5 PPC system that doesn't have gcc6 installed, I get an >> error that a symbol cannot be imported from /usr/lib/libstdc++.6.dylib. I >> guess this is because the libstdc++.6.dylib that is shipped with 10.5 >> doesn't contain those new features required by C++11 programs. >> So what is the recommended way of getting the libstdc++.6.dylib required by >> my program onto a user system? Of course I wouldn't like to bother users to >> install gcc6 from Mac Ports just to be able to run my program. Is there an >> easier way? Is the latest libstdc++ available as its own package in Mac >> Ports maybe or what is the suggested way of dealing with this? > You need to compile with ABI 4 compatibility (add > "-D_GLIBCXX_USE_CXX11_ABI=0" to CXXFLAGS) and then relink them to > /usr/lib/libstdc++.6.dylib with install_name_tool. > The first step might soon no longer be required (see > https://github.com/macports/macports-ports/pull/1469), but you'll > probably need to keep running install_name_tool on the resulting > libraries/binaries, I assume that your binaries link against > /opt/local/lib/libstdc++.6.dylib rather than > /usr/lib/libstdc++.*.dylib Yes, it does. Unfortunately, compiling with -D_GLIBCXX_USE_CXX11_ABI=0 and then changing /opt/local/lib/libstdc++.6.dylib to /usr/lib/libstdc++.6.dylib using install_name_tool doesn't work. It still can't find some symbols. Here's the error I get when trying to dlopen() my project: dyld: lazy symbol binding failed: Symbol not found: __ZSt16__ostream_insertIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_PKS3_i Referenced from: test.dylib Expected in: /usr/lib/libstdc++.6.dylib dyld: Symbol not found: __ZSt16__ostream_insertIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_PKS3_i Referenced from: test.dylib Expected in: /usr/lib/libstdc++.6.dylib -- Best regards, Andreas Falkenhahnmailto:andr...@falkenhahn.com
How to resolve libstdc++.6.dylib dependency
When I compile my C++11 project on a 10.5 PPC system using gcc6 and try to run it on another 10.5 PPC system that doesn't have gcc6 installed, I get an error that a symbol cannot be imported from /usr/lib/libstdc++.6.dylib. I guess this is because the libstdc++.6.dylib that is shipped with 10.5 doesn't contain those new features required by C++11 programs. So what is the recommended way of getting the libstdc++.6.dylib required by my program onto a user system? Of course I wouldn't like to bother users to install gcc6 from Mac Ports just to be able to run my program. Is there an easier way? Is the latest libstdc++ available as its own package in Mac Ports maybe or what is the suggested way of dealing with this? -- Best regards, Andreas Falkenhahn mailto:andr...@falkenhahn.com
Re: Installing gcc6 on a PPC Mac Mini 10.4 gives me hell
On 22.03.2018 at 19:59 Christopher Jones wrote: > Lets leave this here, as we aren’t going to agree on this it seems. It has never been my aim to make you agree with me. I was just trying to make it a little more plausible why some people might still want to stick with outdated software ;-) -- Best regards, Andreas Falkenhahnmailto:andr...@falkenhahn.com
Re: Installing gcc6 on a PPC Mac Mini 10.4 gives me hell
On 20.03.2018 at 23:59 Chris Jones wrote: > You can call these OSes ‘retro’ if you want, to make it sound good, > but all they really are, are outdated and insecure. By the way, another reason to use "outdated and insecure" operating systems from a programmer's point of view is backwards compatibility. Of course, the latest Xcode versions allow you to target older Mac OS versions with just a mouse click but this stuff is often hardly tested and I've seen the strangest things happen when building for 10.6 on 10.13 let's say. Upwards compatibility, however, is a completely different case because there are lots of binaries compiled on 10.6 or even older versions around and Apple usually tries hard to keep binary compatibility. They even support real ancient stuff like QuickDraw in binaries which have long been removed from the SDKs. So it's a much better idea to keep older versions of the operating system and build on these than trying to build for older versions on newer versions. It's also worth mentioning that APIs declared obsolete are often quickly removed from the SDK. So the only chance to be able to use APIs declared obsolete often is to keep your old installation. -- Best regards, Andreas Falkenhahnmailto:andr...@falkenhahn.com
Re: Installing gcc6 on a PPC Mac Mini 10.4 gives me hell
On 20.03.2018 at 23:51 Ryan Schmidt wrote: > There is not a great deal of interest in Tiger anymore, but I > understand that the computers that are still running Tiger are slow > and are thus the ones that might most benefit from the existence of binaries. Definitely. Having binaries would be a great benefit for those old systems. -- Best regards, Andreas Falkenhahnmailto:andr...@falkenhahn.com
Re: Installing gcc6 on a PPC Mac Mini 10.4 gives me hell
On 21.03.2018 at 00:34 David Strubbe wrote: > For the record, you can always stop a build by typing CTRL-C, and > it will not corrupt anything. Only at the install stage are any > files permanently changed. If you do "port clean" after stopping the > build, you will be right back where you were before the build. Thanks, that's good to know! -- Best regards, Andreas Falkenhahnmailto:andr...@falkenhahn.com
Re: Installing gcc6 on a PPC Mac Mini 10.4 gives me hell
On 20.03.2018 at 23:59 Chris Jones wrote: > You can call these OSes ‘retro’ if you want, to make it sound good, > but all they really are, are outdated and insecure. I've always preferred freedom over security. And by the way, I have a feeling that with each new Mac OS version the system becomes more and more curious about me, tries to collect data, hides things from me, and tries to infantilize me by pretending to know what is good and bad for me (Gatekeeper anyone?) In that regard, the older Mac OS versions are really much more pleasant than the latest releases which seem to take away more and more control from the user. That might be very good for people without a clue about computing but for coders it's a pain in the "donkey". It's time to regain control - the OS is here to serve, not to spy on me or impose its will on me :-) $0.02 -- Best regards, Andreas Falkenhahnmailto:andr...@falkenhahn.com
Re: Installing gcc6 on a PPC Mac Mini 10.4 gives me hell
On 20.03.2018 at 21:58 Rainer Müller wrote: > Personally, I do not understand why you are still running such an old > machine with macOS. It's retro, there doesn't have to be a rational reason for it :-) Besides, in the retro scene 10.4 is quite popular because it's the last Mac OS capable of running Mac OS 9 software. I also have a 10.6 installation which I won't update because 10.6 has Rosetta (PPC emulation). It's vintage - it needn't make sense. -- Best regards, Andreas Falkenhahnmailto:andr...@falkenhahn.com
Re: Installing gcc6 on a PPC Mac Mini 10.4 gives me hell
On 20.03.2018 at 21:35 Ken Cunningham wrote: > On 10.5 you installed a prebuilt binary. > gcc6 takes 12 to 24 hrs to build on a PPC machine. Oh my, that's too much for me, I've just hit CTRL-C. Of course this might leave me with a corrupt installation but I'm just too paranoid about Mac Ports killing my hardware. IMHO there really should be prebuilt binaries for 10.4. It's a waste of energy and resources to have everybody build this on his own... -- Best regards, Andreas Falkenhahnmailto:andr...@falkenhahn.com
Installing gcc6 on a PPC Mac Mini 10.4 gives me hell
So I installed gcc6 on my 10.5 G5 PowerMac a few days ago and it was a breeze. It took just a few minutes. It looked like the installer just grabbed the binaries and installed them. No big deal at all. Now I am trying to install gcc6 on my 10.4 G4 Mac Mini and it seems to build everything from sources and it's taking ages. Building apple-gcc42 took two hours alone and that was just the first of many packages to come. I'm worried about my hardware because the CPU is at 100% all the time causing the Mac Mini fan to be in full ventilation all the time. It has been running like that for 3 hours now and there are still many more packages to go. If it's going to continue at that speed, I'd estimate the gcc6 installation to take about 12 hours or so. Where does this difference come from? On my 10.5 G5 PowerMac it really was just a few minutes and now it's taking hours. Yes, the G5 is faster but certainly not that much. To me it looked as if on 10.5 binaries were downloaded and installed whereas on 10.4 everything is built from scratch. Is that right? If it is, there really should be a warning that this is going to take ages because once the thing has been started there's no way out since I don't want to interrupt it in the middle of installing for fear of breaking something. And I'm worried about my hardware. It's 13 years old and now has to run under full stress for hours and hours and hours :-/ Why doesn't Mac Ports simply provide ready to run binaries for 10.4 PPC? The current installation process feels a little bit like maximum overdose for my poor old PPC Mac Mini... -- Best regards, Andreas Falkenhahn mailto:andr...@falkenhahn.com
Re: Trouble compiling with gcc 4.8 on 10.5 PowerPC
Hi Kenneth, On 17.03.2018 at 23:30 Kenneth F. Cunningham wrote: > As a first step, if you don't specifically require gcc-4.8, try > instead with gcc-6 (macports-gcc-6) which works quite a bit better in most > cases. Thanks, this indeed solved all my problems! The malloc errors have disappeared and the linker warning as well. Thanks a lot for the hint! There's just one little problem remaining: I cannot use gcc-ar-mp-6 because it reports the following error: "Cannot find plugin liblto_plugin.so". So I just use the "ar" that came with Xcode and it worked fine but maybe gcc-ar-mp-6 should be fixed. Another question: How can I make my program compatible with 10.4? I currently compile on my G5 system which has 10.5 installed. When I try to run the program on a G4 10.4 system I get a symbol import error from /usr/lib/libstdc++.6.dylib. Do I have to install macports-gcc-6 on the 10.4 system in order to be able to run my program on 10.4 or is there anything else that needs to be taken care of? > After that, we slog through. It's a great system, PPC, but there > are not so many of us using it any more. We need to stick together! Definitely. PPC rules. I'm also running MorphOS on my PowerPC Macs. This is another PPC operating system inspired by AmigaOS. -- Best regards, Andreas Falkenhahnmailto:andr...@falkenhahn.com
Trouble compiling with gcc 4.8 on 10.5 PowerPC
Hi, I need to compile C++11 sources for PowerPC OS X so I installed gcc48 using Mac Ports. Although the binary generated by gcc-mp-4.8 actually works, I do get some warning messages which are worrying me. When linking my project, I get this warning: ld: warning: 32-bit absolute address out of range (0x100521C58 max is 4GB): from _REQUIRED_TAGS + 0x0034 (0x00521C5C) to 0x100521C58 For reference, this is how I link my project: gcc-mp-4.8 -fPIC -dynamiclib -exported_symbols_list exports.def -o macppc48/plugin.dylib macppc48/plugin.o -Llibharu/macppc48 -Llibapng/macppc48 -Lpdfium/macppc48 -L../freetype-2.8/macppc48/objs/.libs -lharu -lapng -lpdfjpeg -lfreetype -lcms -lopenjpeg -lagg -lpdfium -lfdrm -lfpdfdoc -lfpdfapi -lfpdftext -lfxcodec -lopenjpeg -lfxcrt -lfxge -lpwl -lformfiller -ljavascript -lpdfiumbase -lfdrm -lfreetype -lpdfjpeg -lagg -lcms -lm -lpwl -lfpdfdoc -lz -lstdc++ -framework AppKit -framework CoreFoundation When running my project, I get lots of these errors: testprogram(151,0xa0b96820) malloc: *** error for object 0x41384d0: Non-aligned pointer being freed (2) *** set a breakpoint in malloc_error_break to debug My project is a cross-platform project which already runs fine on many other platforms (x86/x64 Mac; Windows; x86/x64/ppc/arm Linux, etc.) so I'm pretty certain that those issues are not related to bugs in my code but that either something is wrong with gcc 4.8 or that I'm not using it correctly. Anyone here who knows how to solve these issues? As I said, despite those warnings the program seems to work correctly but of course these warnings are worrying me and I want them to disappear. Thanks! -- Best regards, Andreas Falkenhahn mailto:andr...@falkenhahn.com
