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

[Ces VLC]

Thanks a lot, Ken.

César


On Wed, Jun 21, 2023 at 3:34 PM Ken Cunningham <
ken.cunningham.web...@gmail.com> wrote:

> The necessary parts Apple added (driverdriver.c) to enable that have not
> been updated since gcc-4.2, so one-pass universal is not available since
> then.
>
> 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!
> >
> > 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 years later I tried a genuine (non-Apple) gcc, and creation of fat
> binaries as a one liner was no longer available.
> >
> > I know that gcc support for Apple Silicon comes as a patch, and it's not
> upstreamed yet AFAIK, but I was wondering if that patch lets you build
> Intel+ARM universal fat binaries in a single invocation as well, or if
> that's not supported.
> >
> > Kind regards and thanks a lot!
>

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

[Ces VLC]

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 years later I tried a genuine (non-Apple) gcc, and creation of fat
binaries as a one liner was no longer available.

I know that gcc support for Apple Silicon comes as a patch, and it's not
upstreamed yet AFAIK, but I was wondering if that patch lets you build
Intel+ARM universal fat binaries in a single invocation as well, or if
that's not supported.

Kind regards and thanks a lot!

Re: Does the migration procedure keep ports versions?

[Ces VLC]

> 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 original
> and default OS from Apple was High Sierra, indicating a 2018 model,
> which is still supported by Apple up to current, or Ventura.

Yep, Chilli got it right. When I said "High Sierra MBP" I meant "a MBP
which came with High Sierra preinstalled", and, yes, it's a 2018 MBP.
Regarding the big jump 10.13.6 -> 12.6 my wish would have been to keep it
with 10.13.6 forever (my 2010 MBA wouldn't boot in 10 seconds -which it
does- if I had updated it from Snow Leopard). However, the pace of macOS
versions is now very different from what it was 10 years ago (meaning that
10 years ago, an OS release was considered as something valuable, worthy of
being supported, but today is considered something unworthy of putting a
support effort on it). I have the feeling, anyway, that Monterey might be
the macOS release I'll keep in this MBP until the end of its service life.

Regarding my question, MacPorts, my installed ports seem to work fine (if I
invoke the "port" command, I get the error notifying a mismatch between the
ports and the macOS version, but if I just run their executables, they run
fine).

Updating compilers implies debugging my source code tree (I mean, not ports
sources, but my own source code) because of the usual new warnings (or
errors) that usually appear when you update compilers, as well as
potentially changing compiler flags in my build scripts). I can have that
work done in a few days, but I don't have those days now, so I'll be
keeping a broken MacPorts until I have the time for checking a compiler
update properly.

Kind regards and thanks a lot everybody,

César

Does the migration procedure keep ports versions?

[Ces VLC]

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 compilers (like mingw-w64, for example), and I want to
keep them at the same version they are now, because of some compatibility
needs.

Kind regards and thanks a lot,

César

Re: Workarounds for cross compiling to Windows?

[Ces VLC]

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
been a
> little interest from a couple people recently in using it in a very
minimal way on
> Linux.
>
> Even though our ports collection is intended for use on macOS, MacPorts
base
> should compile and run on other operating systems. We used to generate
the
> PortIndex files on a Linux server and we also had a buildbot task that
verified that
> every MacPorts base commit built successfully on Linux. But near the end
of 2016
> we moved to new servers and phased out those Linux parts so it's possible
that
> some Linux incompatibilities have crept into base since then.
>
> [...]
>
> It's certainly feasible to make your own private ports collection for
your own purposes.
> I for example have a collection of ports that manage the configuration of
all the ports
> used to drive the buildbot system. There are a few common things I do in
each port
> so I make a new portgroup that I include in each of my ports that does
those things.
>
> So it might be doable to define a new cross-compile-for-Windows portgroup
that you
> could include into each of your custom ports, and the portgroup could
take care of
> setting the compiler variables and flags properly, for example.
>
> The software you want to build will probably also have dependencies on
programs
> that get run at build time, and those would need to be compiled normally
for macOS
> so that they can run on your Mac.
>
> You might be able to set up your custom portgroup to install all your
Windows software
> to a different location, like /opt/windows (maybe setting up a new
variable like $wprefix
> with that value so that you can use it in your portfiles) while leaving
$prefix to be the
> compiled-for-Mac prefix for build dependencies.
>
> Or perhaps Wine figures into your build process, in case you need to run
> compiled-for-Windows programs on your Mac as part of the build.

Thanks a lot for such detailed information, Ryan. It's going to be very
helpful. Yes, I'm going to do a private ports collection for just the
packages I need to cross-compile to Windows. I believe it can be a bit
difficult at the beginning, while I figure out how to do the plumbing, but
it will pay off in the long run, and it's exactly the approach I need.

By the way, I'm sorry for the delay in my reply: your message got into the
spam filter and I hadn't seen it :-(

Kind regards and thanks a lot,

César

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

[Ces VLC]

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 https://llvm.org/docs/AdvancedBuilds.html). I've never used it (mainly
because LLVM is usually a bit lagging in terms of documentation: before the
monorepo you even had to guess where each subproject was supposed to be
downloaded in the tree).

Anyway, despite not using this official multistaging, I've always built
LLVM in manual stages (at least two: first stage with my current compiler,
second stage with the first stage compiler). At the end I issued a "make
check-all" for checking how the result looks in terms of tests
passes/failures.

Now, looking at the portfile, it seems like LLVM/clang is built with one
stage only in MacPorts and no checks are performed (unless I'm missing some
bits, because I'm still no expert at portfile syntax).

Don't you check the validity of the resulting compiler in some way? I
suppose you do, at least for internal tests, don't you?

Kind regards and thanks a lot,

César
(*) When I say "LLVM", I mean the whole tree (including flang when LLVM 11
gets released --I'm tempted to try the RC1, but there seem to be some fatal
reports from release testers in the mailing list, so maybe it's wiser to
wait for at least RC2 --although the developer doing the MacOS build
reported total success with RC1 --he didn't build flang, though). Looking
at the portfiles, it looks like the port for "everything" is clang rather
than llvm, if I'm not mistaken.

Re: Workarounds for cross compiling to Windows?

[Ces VLC]

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 of us,
> it would be if not impossible, at least a lot of trouble.
>

I’m used to crosscompiling to Windows, so I’m used to set configuration
options and toolchains for that (but using my own build scripts, not
MacPorts).

So, the only important point here is whether you can write a portfile that
doesn’t assume the target to be MacOS. If that’s possible, moving the code
from my build scripts to the portfiles would be straightforward.

Kind regards, and thanks a lot,

César

Re: Workarounds for cross compiling to Windows?

[Ces VLC]

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 assumed MacPorts will build for MacOS
only. Can you write a portfile that will crosscompile to other OSs such as
Windows? And, if affirmative, can you also write portfiles that build to
iOS and Android? That would greatly improve my workflow!!

Kind regards and thanks a lot,

César

Workarounds for cross compiling to Windows?

[Ces VLC]

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 apps for both MacOS and Windows from the same Mac (so I cross
compile to Windows, using mingw-w64). And, because apps usually depend on
libraries, I build such dependencies both for MacOS and for Windows.

Until now, I used my own build scripts when cross-compiling to Windows, but
I'm wondering if I could use MacPorts in some way for making this task more
comfortable.

I know there are things that wouldn't apply (like patches, which are
Mac-specific). In fact, MacPorts is very Mac-specific in itself.

But I'm wondering if there's some way of tricking the system so that I
could write for example a custom portfile for the packages I need, with
this portfile modified for cross compiling to windows.

Do you think this would be feasible? Or do you recommend to keep using my
scripts? Or perhaps you know of any package manager designed for cross
compiling?

Kind regards and thanks a lot,

César

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

[Ces VLC]

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 provided. It's very complete, and, yes, Jim, what you described is the
cause of the problem: rsync just transmits file names as verbatim raw
sequences of bytes with no conversion at all.

IMHO, the correct way of fixing this shouldn't be by manually converting
the encodings yourself with the '--iconv' flag, but actually with a flag
for performing the check after normalization, which AFAIK doesn't exist (it
wouldn't matter what normalization, just apply the same normalization to
all file names before comparing them, and then discard the normalization).
What I mean is, what's the purpose of rsync considering as different two
files whose name is identical when being displayed in a terminal? Two
identical text strings can be normalized in different ways (for example:
accents in separated codes, or in composed codes), but they are the same
text. So, if the text is the same, why consider them as different file
names?

I don't understand why such '--normalize-before-compare' flag doesn't exist
(I insist: no need to specify the normalization algorithm, just apply the
same algorithm to all file names). It would fix all these problems in an
elegant and clean way, and, BTW, this would be the behaviour everybody
expects, if I'm not missing any point here.

Another surprising thing is that I don't see any serious alternatives to
rsync. It's good because if everybody uses rsync, it will be better tested
and more reputable, but it also has the bad side of what happens when it
doesn't support the feature you need...

Kind regards,

César

rsync and different UTF normalization in APFS vs HFS+

[Ces VLC]

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 deleting a file and then rewriting it again, just because
the UTF normalization is not the same in both disks. Other users have been
reporting this (see here for example:
https://superuser.com/questions/1513326/rsync-from-mac-os-to-synology-with-btrfs-having-issues-with-file-and-directories
 ).

For over a year I've been tolerating this because I considered it
non-critical, but I feel I should fix it. However, I didn't find any posted
solution that could address this in a convenient and proper way.

People suggest to use the --iconv flag, but... does this mean that you need
to use different iconv settings depending on whether your transfer is
APFS->HFS+ or HFS+->APFS? If affirmative, it would be a bit clumsy, IMHO
(first detect the disk FS, then choose proper flags).

Isn't there some way for dealing with this more conveniently, in a way that
you don't need to check the disk FS before invoking rsync?

Thanks!

César

Noah port (and alternatives?)

[Ces VLC]

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
downloading right now).

Said this, do you know of any other attempt at Linux user-mode emulation on
Mac, or is Noah the only project you've seen about this? (note that qemu
has user mode emulation, but, AFAIK, it requires the host system and the
guest system to be the same, making it useful only for running binaries for
other architectures in the same OS).

If you don't know of any other alternatives or attempts, maybe I should
consider improving Noah, but I'd prefer not to reinvent the wheel...

Kind regards,

César

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

[Ces VLC]

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 time
the rumors said that the reason was an attempt to break compatibility with
LLVM because GCC saw it like a competitor, but that was just a rumor.

Kind regards and thanks a lot,

César


On Tue, May 19, 2020 at 5:08 PM Kenneth F. Cunningham <
ken.cunningham.web...@gmail.com> wrote:

> > 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 and from clang?
> >
> > Thanks!
> >
> > César
>
> The issue is not so much with the compiler as with the c++ standard
> library.
>
> Any compiler can use any c++ standard library.
>
> But *by default* (1) clang will use libc++ and gcc will use libstdc++, and
> these are not compatible with each other.
>
> So if you are going to mix objects (and libraries) coming out of clang and
> gcc, you have to be sure that they all use the same c++ standard library.
>
> With c++ code, that is quite tricky to do properly.
>
> If you use gcc just to build "c" code, or fortran code, there is no
> problem mixing those libraries or objects with clang c++ code.
>
> Ken
>
>
>
>
> 1. By default, on current MacOS and on all MacOS on MacPorts. Further
> needless and sometimes confusing detail omitted for clarity of focus, ask
> if truly curious. -K

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

[Ces VLC]

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 and from clang?

Thanks!

César

Re: mingw-w64 and gcc 9.3.0

[Ces VLC]

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, Mojca!!

César

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

[Ces VLC]

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 lot, Ryan and Jeff. Yes, the key was the "--program-prefix=g".
With it, both versions can coexist.

Thanks a lot!!

César

mingw-w64 and gcc 9.3.0

[Ces VLC]

Hi!

I'd like to use gcc 9.3.0 with mingw-w64 (the list of bugfixes in 9.3.0
looks significant). I don't know how much effort will this update require,
I just add my vote for it here, thanking your great support once more!

Kind regards and thanks a lot!

César

MacOS libtool and GNU libtool: Recommended way for coexistence?

[Ces VLC]

Hi!

Today I got lots of errors when building one of my projects, about
"-static" not being supported by libtool... then I realized that the reason
is that such project was developed with the MacOS libtool in mind, and by
installing GNU's libtool (because of it being required by CUnit), the GNU
version takes higher precedence over the MacOS version, and then it breaks
the build for my project.

So... can you give some advice on how to manage the coexistence of both
libtools?

Thanks a lot!

César

32bit Docker containers in Catalina

[Ces VLC]

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?

[Ces VLC]

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 binaries only (didn’t try neither universal nor 32bit, so I
cannot confirm if the issue noted by Ken is still there).

Now I really look forward for the mingw-w64 port to be updated to the just
released 7.0.0 (I very rarely update mingw-w64 —mind you, my mingw-w64 was
still at gcc4.6.3, but the new 7.0.0 release notes talk about significant
“math fixes”... which looks like a good reason for updating, although OTOH
it seems strange that there have been math bugs in mingw-w64 for so many
years, maybe they are not that important, I don’t know).

Kind regards, and thanks a lot for your work in MacPorts,

César



El El mar, 19 nov 2019 a las 5:56, Ken Cunningham <
ken.cunningham.web...@gmail.com> escribió:

> > It is interesting that you were able to build
> i686-w64-mingw32-gcc-bootstrap @9.2.0 on 10.6. Our regular gcc9 port is
> programmed to error out on 10.6 and earlier saying it doesn't work. But if
> i686-w64-mingw32-gcc-bootstrap @9.2.0 works on 10.6, maybe the normal gcc9
> @9.2.0 would work too.
>
> I have had gcc 9.2.0 building on 10.6.8 since about May, and  there was
> once a PR up to update it (and the libgcc ports).
>
> However, there is a small issue with the i386 build, so it's been held
> back while I work out the general fix for that.
>
> K

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

[Ces VLC]

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
http://mirror.cc.columbia.edu/pub/software/gnu/gcc/gcc-9.2.0/
--->  Verifying checksums for
i686-w64-mingw32-gcc-bootstrap
--->  Extracting i686-w64-mingw32-gcc-bootstrap
--->  Applying patches to i686-w64-mingw32-gcc-bootstrap
--->  Configuring i686-w64-mingw32-gcc-bootstrap
--->  Building i686-w64-mingw32-gcc-bootstrap
--->  Staging i686-w64-mingw32-gcc-bootstrap into destroot
Warning: i686-w64-mingw32-gcc-bootstrap installs files outside the common
directory structure.
--->  Installing i686-w64-mingw32-gcc-bootstrap @9.2.0_0
--->  Activating i686-w64-mingw32-gcc-bootstrap @9.2.0_0
--->  Cleaning i686-w64-mingw32-gcc-bootstrap
[...]

And then the build continues with the next dependency. It's still building
in this moment. No errors for the moment.

Should I worry about that "Warning: i686-w64-mingw32-gcc-bootstrap installs
files outside the common directory structure.", or is it expected?

Thanks!

César

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

[Ces VLC]

Thanks a lot for all the provided info. Yes, I'm building libc++ and
libc++abi, but I'm doing it in-tree (ie: inside llvm/projects, so that
libc++ and libc++abi are being built at the same compile invocation as the
whole LLVM). And one thing that I find really confusing is that the LLVM
build system treats libc++ in a very weird way (or at least weird from my
point of view). Yes, it builds everything... but clang is linked against
the system libc++ instead of the one in llvm/projects (I'd expect the
contrary: if you build libc++ is because you will be using it, and if you
will be using it, why wouldn't clang be linked against it?).

To make things more confusing, when running the tests, it seems that the
newly just-built libc++ is the one being tested (why test the newly built
if clang is linked against the system one?).

I usually build LLVM in several "stages" (like GCC does), so that at the
end I'm using a LLVM built with the same version (just for pedantic
correctness if you wish). And I usually find that I'm able to force the
clang/clang++ drivers to be linked against the libc++ compiled in the
previous "stage" (by telling so through brute-force CXXFLAGS or similar
variables at build time), but not with the one being compiled in the
current stage.

At the end, the only conclusion I arrive to is that libc++ and libc++abi
are treated as second-class citizens by the LLVM build tree, as if they
were libraries that you are building but without wanting to use them (?!),
so maybe the only possible approach is the one followed by MacPorts, with
each "stage" being something like: first build libc++ and libc++abi (out of
tree), and then build LLVM with the proper brute-force environment
variables in order to link against them.

Obviously LLVM doesn't consider the scenario of developers trying to
isolate system dependencies (my case), so I think my best bet is going to
imply some chroot-ing...

Thanks!

César




On Tue, Jan 22, 2019 at 1:53 AM Ken Cunningham <
ken.cunningham.web...@gmail.com> wrote:

> Hi,
>
> WIth the way MacPorts builds llvm/clang, libc++ is not actually built or
> installed in the directory you mention. It could be -- the source is there
> -- but it isn't. We just use the source for the llvm build, and install the
> headers, but don't build or install libc++ that way.
>
> The MacPorts-sanctioned way to do what you want to do is to use the libcxx
> port, and if you look at the variants, there is a "replacement" libcxx that
> forces a new libcxx to install in "/usr/lib/". This is presently set to be
> the libc++ that comes with llvm-5.0. I have personally built the libc++
> that corresponds to llvm-7.01, but haven't yet pushed that through as I've
> been working with the libcxx port quite a bit lately and didn't want to do
> too many changes at once.
>
> Certainly if I was going to do that on a current system I'd back up my
> libc++ first, I'd bump the libcxx port to the 7.0.1 release, and then cross
> my fingers :> It will almost certainly work fine, but you need a method to
> get the original libc++ and libc++abi back in place in case of gremlins,
> because if there is a gremlin, your system won't boot.
>
> It is possible to adjust clang's library search paths, but it's not quite
> as easy as we thought. Ideally you should be able to pass -syslibroot, but
> that didn't really work out <https://trac.macports.org/ticket/57612>.
> Even if you did alter and SDK and use isysroot to build against a different
> libc++, you'd wind up using the one in /usr/lib at runtime.
>
> If you dig into the clang source code, you can quite easily find where the
> behaviour to look for libraries is handled;  there is a custom modification
> to clang on MacPorts where we allow it link against a different libstdc++
> by passing in an added stdlib Marcus made up. So it would be possible, I
> believe, to set up a clang modification to use another custom stdlib (ie
> -stdlib=myspeciallibc++) that uses directories and headers you choose. It
> would be a slightly "advanced" project to do that, but do-able, I believe,
> in a day or three (or less, if you eat this stuff for breakfast).
>
> See <
> https://github.com/macports/macports-ports/blob/master/lang/llvm-7.0/Portfile>
> and <
> https://github.com/macports/macports-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 you started !
>
> Ken
>
>
>
> On 2019-01-21, at 1:54 PM, Ces VLC wrote:
&

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

[Ces VLC]

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 /usr/lib and
at /usr/local/lib

The main purpose is that I want that the LLVM libc++ is always used by
default, instead of the MacOS one.

Of course I know I can add LLVMHOME/lib as a -L option passed to clang++,
but I want it to be a default rather than a -L option, because some
packages come with broken Makefiles that overwrite any tuning that you wish
to perform through environment variables such as LDFLAGS or CXXFLAGS.

How can I build LLVM with this behavior?

Thanks a lot!

César

Re: Experiences with union mounts in MacOS?

[Ces VLC]

Thanks a lot, Michael, Daniel, and Richard, for your comments. Union mounts
are a very powerful feature that solves many needs, but, sadly, it's not
something you can rely on for critical-mission projects, because it seems
to be very little tested, if at all. Anyway, there are workarounds that can
provide at least similar functionality, and working with DMGs and symlinks
will help me.

Thanks, and happy new year!!

César




On Sun, Dec 16, 2018 at 8:47 PM Michael  wrote:

> Yea. Short answer: DON'T.
>
> Long answer: Mac OS does not support union mounts. They're there, they are
> honored by posix programs, but everything that using the apple file system
> interface bypasses it.
>
> Which means that just about anything based on cocoa framekworks ...
> optimizes and bypasses union mount visibility.
>
> I ran into  this back on 10.7, and complained, only to 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
> 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 DMGs together in the same folder.
>
> But I'm a bit afraid because it seems to be a little used feature in the
> Mac, so, if I'll be the only one in the planet using it, I guess it can be
> like sort of a minefield walk, likely to use little-tested stuff.
>
> I searched for it, and the only problems I saw reported is that Finder
> doesn't seem to honor union mounts, but that wouldn't be a problem for me,
> as I won't be using Finder for browsing the mount directory. If it works
> fine at the Terminal, then it's fine for me.
>
> Do you have any experience using union mounts on MacOS? Did it work fine
> for you? Did you find any problem/issues?
>
> Thanks!
>
> César
>
>
>
>
>
>
> ---
> Entertaining minecraft videos
> http://YouTube.com/keybounce
>
>

Experiences with union mounts in MacOS?

[Ces VLC]

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 DMGs together in the same folder.

But I'm a bit afraid because it seems to be a little used feature in the
Mac, so, if I'll be the only one in the planet using it, I guess it can be
like sort of a minefield walk, likely to use little-tested stuff.

I searched for it, and the only problems I saw reported is that Finder
doesn't seem to honor union mounts, but that wouldn't be a problem for me,
as I won't be using Finder for browsing the mount directory. If it works
fine at the Terminal, then it's fine for me.

Do you have any experience using union mounts on MacOS? Did it work fine
for you? Did you find any problem/issues?

Thanks!

César

Re: User information about macOS Mojave

[Ces VLC]

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
keep MacOS as primary development platform for a bit more, although it
seems it’s time to “put the wheels in motion”).

César

Re: User information about macOS Mojave

[Ces VLC]

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 with
the MacOS 10.13 SDK. So, no need to be limited to older compiler versions.
And I think that's in fact what I'm going to do in Mojave.

César

Re: User information about macOS Mojave

[Ces VLC]

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 installing both, but it could be a nice idea!
Thanks!

César

Re: User information about macOS Mojave

[Ces VLC]

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 MacPorts, but also because I'd like to be able to continue
building 32bit code (not for deployment, but for internal testing: I build
and test code in both 32bit and 64bit, as a check that our code doesn't
make assumptions on the architecture word size). Apple, Apple, Apple...
with this attitude Macs will end up being used for final builds only (well,
I don't wish to go off-topic, we'll probably move development from
MacOS-native to encapsulated environments in VMs, --this will be the most
practical solution, putting feelings and likes/dislikes aside).

Anyway, copying the 10.13 SDK into Xcode 10 should work, but I was feeling
curious on why Xcode 9.4.1 won't work on Mojave.

César

Re: User information about macOS Mojave

[Ces VLC]

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, rather than the maximum MacOS version... obviously
with the limit of course that you cannot use new features from SDKs newer
than those provided with your Xcode version).

César

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

[Ces VLC]

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::~__shim_type_info()
>   ^
> /Users/cesar/LLVM/6.0.1rc3/libcxx/include/typeinfo:122:13: note:
> '~type_info' has been explicitly marked
>   unavailable here
> virtual ~type_info();
>
>
>
I think I found the reason:
https://github.com/llvm-mirror/libcxx/commit/907c1196a7c153e6040dd850dc194abc62aabc80

In that commit, type_info is marked unavailable for <10.9

However, that commit is from May 2017, so it's also present in llvm 6.0.0,
and I didn't find any MacPorts patch for reverting it, so I'm wondering why
this isn't affecting MacPorts but affects me when manually building llvm...

Cheers,

César

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

[Ces VLC]

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,
which might be the one tagged as final).

I first built it by using a previous 3.8.0 build I had on my Snow Leopard
Mac. It went really smooth (although I didn't build lldb, openmp, nor
compiler-rt), and I'm actually surprised I was able to build it without any
patch at all (while I remember I had to apply some MacPorts patches in
order to build 3.8.0). So, to my surprise, the compatibility of the LLVM
source has increased with the years (I say "to my surprise" because usually
compatibility gets worse with the years in recent open source projects).

Said this, I'm now trying to self-host 6.0.1rc3. So I'm building 6.0.1rc3
with the 6.0.1rc3 build I got through 3.8.0

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::~__shim_type_info()
  ^
/Users/cesar/LLVM/6.0.1rc3/libcxx/include/typeinfo:122:13: note:
'~type_info' has been explicitly marked
  unavailable here
virtual ~type_info();

I raised my eyebrow, tried to build it with 3.8.0, and it built fine. Same
flags, same everything. Even a diff on the included headers (got from
invoking clang++ with '-H' argument) gets the very same results (except for
the 3 headers that are inside the include dir of the installed LLVM, but
they are identical except for minor differences in stdint.h which shouldn't
be affecting here).

Same flags, same included files, same everything... and 3.8.0 builds the
file, while 6.0.1rc3 stops with the above error...

Any clue on what could be happening here?

Thanks!!