Re: Can gcc13 create fat binaries for Intel+ARM in one-liner?

hen. > > People occassionaly talk about updating driverdriver.c, and there are a > few shell scripts floating around that do some of it, but that’s as far as > it goes. > > K > > > On Jun 21, 2023, at 01:41, Ces VLC wrote: > > > >  > > Hi! > > > >

Can gcc13 create fat binaries for Intel+ARM in one-liner?

Hi! Last time I used gcc for creating fat binaries was in the days of Snow Leopard, using the Apple-bundled version of gcc, which, if I recall correctly had this behaviour of letting you specify several archs in the same invocation because of a patch written by Apple. I also seem to recall that

Re: Does the migration procedure keep ports versions?

> On Thu, 29 Sep 2022, chilli.names...@gmail.com wrote: > > The initial reported spec, "a High Sierra MBP," is ambiguous. That could > mean a 2010 MBP, that can be updated up to High Sierra with a third > party enabler, or more likely Ces VLC meant that the machine's

Does the migration procedure keep ports versions?

Hi! I'm planning an update of a High Sierra MBP up to Monterey, and I didn't find an explicit mention in the migration docs ( https://trac.macports.org/wiki/Migration) about if the described procedure keeps the ports versions or not. In this moment that's important for me, because I have some

Re: Workarounds for cross compiling to Windows?

On Fri, Jul 10, 2020 at 10:41 AM Ryan Schmidt wrote: > > [...] > > Ports should ideally segregate Mac-specific instructions and patches into > a "platform darwin" block, but many many ports don't do that and almost nobody > tries to use MacPorts in any way on other platforms, though there has

Build clang in stages? And how to run "make check-all"

Hi! I've always built the complete LLVM tree manually, on my own, but now for the sake of more convenient updates and more comfortable patching, I'll move to the MacPorts LLVM builds (*). I know there's a supposedly officially supported multistage build in LLVM (see

Re: Workarounds for cross compiling to Windows?

El El vie, 10 jul 2020 a las 20:45, Richard L. Hamilton escribió: > [...] > Then again, I haven't spent any significant time reading about or looking > at MacPorts internals, let alone experimental features. For someone with > really deep knowledge, it might not be THAT difficult; but for most

Re: Workarounds for cross compiling to Windows?

El El vie, 10 jul 2020 a las 18:15, Ken Cunningham < ken.cunningham.web...@gmail.com> escribió: > [...] > There is a full description on the point-by-point details here: > > > [...] Yes, I know how to do that, but I

Workarounds for cross compiling to Windows?

Hi! I know that MacPorts doesn't support building packages for other OSs, but anyway there are some features that even if they are not officially supported, do work because of the way it's designed (for example, installing MacPorts in your home directory with no root privileges needed). I build

Re: rsync and different UTF normalization in APFS vs HFS+ (macports-users Digest, Vol 167, Issue 3)

On Sat, Jul 4, 2020 at 2:43 AM Jim DeLaHunt wrote: > > [...] I hope you see the distinctions I'm trying to explain. And, I hope this helps you figure out a solution. Please let the list know what you find out. > Thanks a lot, Ryan and Jim, for your messages and for the great information you

rsync and different UTF normalization in APFS vs HFS+

Hi! Some of my disks are HFS+ and others are APFS. I've been using rsync for years, in order to sync some folders across all my disks. There were no problems until APFS was introduced into the game. Now, in filenames that have UTF international characters, I often hit the problem of rsync

Noah port (and alternatives?)

Hi! I'm looking for a Linux user mode emulation on Mac, and I just found Noah on github, and then realized there's already a port for it. From what I've read, it seems it's quite experimental (BTW: there were some merged PRs a few days ago, that are not included in the 0.5.1 tag that the port is

Re: Was the clang <> GCC 5 ABI incompatibility overcome at some point?

Thanks a lot, Ken. Yes, I understand that, but I believe there was some ABI incompatibility introduced with GCC 5, wasn't it? If I recall correctly, it wasn't just a matter of what C++ standard library you choose, but that even if you chose the same, GCC 5 still broke the ABI compatibility. At the

Was the clang <> GCC 5 ABI incompatibility overcome at some point?

Hi! I remember a few years ago when a change in GCC 5 caused ABI incompatibility with clang. I'm searching for updates on this, and it seems like clang applied the same change eventually, but can they considered binary compatible at this moment? Is it now safe to link object code coming from GCC

Re: mingw-w64 and gcc 9.3.0

On Sun, May 3, 2020 at 1:20 PM Mojca Miklavec < mojca.miklavec.li...@gmail.com> wrote: > [...] > Except that in this case a pull request was already there: > https://github.com/macports/macports-ports/pull/6822 > and now the latest version should already be available. > > Mojca Thanks a lot,

Re: MacOS libtool and GNU libtool: Recommended way for coexistence?

On Fri, May 1, 2020 at 6:41 AM Jeffrey Walton wrote: > [...] > > When you build libtool from sources, use the '--program-prefix=g' > option to avoid the name collision. > > The prefix is also used for some programs, like sed and awk, because > of all the forks floating around. > > Jeff Thanks a

32bit Docker containers in Catalina

Hi! Should I be beware of difficulties at running 32bit Linux containers in the macports docker in Catalina, or should the Catalina hypervisor be fine at virtualizing 32bit code? Thanks! César PS: Just found mingw-w64 just updated to 7.0.0 yay! Thanks a million Mojca!!

Re: Should I worry about this warning when installing mingw-w64 on 10.6.8?

Thanks a lot Ryan and Ken, both for the clarification about (the lack of relevance for) the warning, and for the situation regarding 10.6 I can confirm my build was successful for mingw-w64 (6.0.0+gcc9.2.0), for both crosscompilers (i686 and x86_64 targets) but both of them compiled as 64bit Mac

Should I worry about this warning when installing mingw-w64 on 10.6.8?

Hi! Just issued a "sudo port install mingw-w64" on 10.6.8. Most needed dependencies are downloaded prebuilt, except for gcc 9.2.0, which needs to be built from source. When building the bootstrap stage, I get this warning: [...] ---> Attempting to fetch gcc-9.2.0.tar.xz from

Re: Can LLVM be built so that its 'lib' directory has higher priority by default?

ports-ports/blob/master/lang/llvm-7.0/files/9001-macports-libstdcxx.diff> > for a clue as to how someone might proceed if they wanted to try that. > > Maybe there are easier ways I haven't thought of here -- this is just what > came to mind between events at work. > > Hope this at least gets

Can LLVM be built so that its 'lib' directory has higher priority by default?

Hi, I'm building LLVM 7.0.1 manually (well, following the MacPorts port file, but doing it manually), and I'm aiming for getting a clang/clang++ that by default looks for libs in the LLVMHOME/lib directory (where LLVMHOME is the installation prefix used when building LLVM) before looking at

Re: Experiences with union mounts in MacOS?

get basically this > back from apple support engineers. > > > On 2018-12-16, at 8:03 AM, Ces VLC wrote: > > Hi! > > Sorry for this partially off-topic post, but couldn't imagine another > place with more people likely to having experiences with little known MacOS &g

Experiences with union mounts in MacOS?

Hi! Sorry for this partially off-topic post, but couldn't imagine another place with more people likely to having experiences with little known MacOS UNIX features than this. In order to ease the testing of some builds, I had the idea of using union mounts ("mount -o union") to merge several

Re: User information about macOS Mojave

El El vie, 28 sept 2018 a las 18:50, Thomas Bodlien < creative-software-des...@t-online.de> escribió: > > But why? > What do you need 32-Bit Support for? I said it in a previous message: for testing purposes and code quality verification (yes, I can use a 32bit Linux VM for that, but I prefer to

Re: User information about macOS Mojave

On Thu, Sep 27, 2018 at 12:17 PM Dominik Reichardt wrote: > > At least for command line building of things this will be a way to keep old xxode around. Well, on second thought, if you want to generate 32bit executables with the newest compilers, it should be possible to build LLVM 7.0 and use it

Re: User information about macOS Mojave

On Thu, Sep 27, 2018 at 12:01 PM Richard L. Hamilton wrote: > > Clearly you can install 9.4.1 on Mojave...and it seems to work at least for trivial code, even compiling to 32 bit: [...] > I have both installed, and simply switched the command line instances with > [...] Thanks! I didn't consider

Re: User information about macOS Mojave

On Thu, Sep 27, 2018 at 11:41 AM Chris Jones wrote: [...] > As far as I am aware it is not possible, but even if it where its not a > solution, to require all macOS 10.13 users to stick with Xcode 9. Yes, it doesn't seem reasonable, but I admit I was asking this question not just thinking in

Re: User information about macOS Mojave

On Wed, Sep 19, 2018 at 7:54 PM Ryan Schmidt wrote: [...] > Mojave requires Xcode 10 which contains only the 10.14 SDK. Is it really required? Is it not possible to use Xcode 9.4.1 on Mojave? (I'm asking because I thought Xcode had a requirement for the minimum MacOS version it could run on,

Re: type_info availability issue when manually building LLVM 6.0.1rc3 libcxxabi on 10.6.8

On Tue, Jun 26, 2018 at 3:59 PM, Ces VLC wrote: > I started with libcxxabi, and I got an error I never saw before: > > /Users/cesar/LLVM/6.0.1rc3/libcxxabi/src/private_typeinfo.cpp:76:19: > error: '~type_info' is unavailable: > introduced in macOS 10.9 > __shim_type_info:

type_info availability issue when manually building LLVM 6.0.1rc3 libcxxabi on 10.6.8

Hi, This is not a pure MacPorts issue, as I'm doing the build manually and not through MacPorts, but I'm guessing that maybe you experienced this very same issue in recent LLVM versions, or that maybe you'll face it when you update to 6.0.1 (not released yet, but I'm trying release candidate #3,