On 2018-10-24 23:53, Joshua Root wrote:
> On 2018-10-2 08:50 , Joshua Root wrote:
>> Second, I'm not sure about changing the SDK only some of the time, or
>> not changing the deployment target. We've always recommended changing
>> the deployment target for an entire installation globally if it's go
On 2018-10-2 08:50 , Joshua Root wrote:
> Second, I'm not sure about changing the SDK only some of the time, or
> not changing the deployment target. We've always recommended changing
> the deployment target for an entire installation globally if it's going
> to be changed, and Apple only supports
The real downside is in 10.15, 32-bit programs will not run at all. I
understand why they did this for iOS but I’m less clear on the macOS side.
—Mark
On Wed, Oct 24, 2018 at 5:41 PM Joshua Root wrote:
> On 2018-10-25 07:55 , Randolph M. Fritz wrote:
> > I found Joshua Root's messages in the sp
On 2018-10-25 07:55 , Randolph M. Fritz wrote:
> I found Joshua Root's messages in the spam trap, so now I understand a
> bit more.
>
> When you say "The difference is that the 10.14 SDK no longer allows
> compiling for 32-bit" does that mean that particular capabilities have
> been removed from t
My understanding is library and XCode. Clang will still compile 32bit I
think since it compiles 32 bit everywhere else.
On Wed, Oct 24, 2018 at 4:55 PM Randolph M. Fritz
wrote:
> I found Joshua Root's messages in the spam trap, so now I understand a bit
> more.
>
> When you say "The difference i
I found Joshua Root's messages in the spam trap, so now I understand a bit
more.
When you say "The difference is that the 10.14 SDK no longer allows
compiling for 32-bit" does that mean that particular capabilities have been
removed from the compiler, the libraries, or Xcode?
--
Randolph M. Fritz
I have my weekends free too. Oct 27 13:00 UTC?
We really need to drive this fast so we can get going with the website and
SFC and annual meeting and everything before 2019.
On Tue, Oct 23, 2018 at 6:48 PM Mojca Miklavec wrote:
> On Mon, 22 Oct 2018 at 22:59, Clemens Lang wrote:
> > On Sun, Oct
FWIW I have tested the basic idea back as far as OSX 10.6, and it works
fine there with the system gcc 4.2.1
MacVM106 /Volumes/VMware Shared Folders/Projects/Test > g++ -I. time.cpp
-o mac106.exe
MacVM106 /Volumes/VMware Shared Folders/Projects/Test > ./mac106.exe
0 CLOCK_REALTIME 15403753
Hi,
I am interested in working on this, as I think it would ease some issues
in a few ports I have stumbled over recently. Let me try and put
something to test together.
I have started to put something together for this. I have a little new
project in github
https://github.com/cjones051073
Hi,
On 24/10/18 01:44, Ken Cunningham wrote:
On 2018-10-23, at 4:23 PM, Chris Jones wrote:
I see no reason to not just place them directly in the main MacPorts include
prefix, i.e. normally /opt/local/include. Placing them anywhere else requires
that specific folder to be included as well,
On 24/10/18 05:35, David Strubbe wrote:
In my experience, that code is also a nightmare to compile. I tried once
and gave up, because it made so many assumptions about the environment
that were not true on a Mac.
That could be viewed as a reason *for* making a port, as once someone
has fixe
On 24/10/18 03:40, Marcus Calhoun-Lopez wrote:
It would have to be something akin to the oracle-instantclient port, in which
the user is responsible for putting the files in the correct location.
This is also how FreeBSD apparently supports GAMESS.
Ah I see. Obviously didn't check the oracl
12 matches
Mail list logo
