Showing posts with label mac. Show all posts
Showing posts with label mac. Show all posts

Wednesday, 7 June 2023

Alire on macOS, revisited

This note covers some of the considerations that’ll apply when running Alire on macOS.

Wednesday, 22 March 2023

Libadalang, Alire, and macOS

Background

This exercise was prompted by the need for Scripted Testing to be supported by – as far as possible – code generation. The need is for the public or interfacing view of a supporting part (domain) of a system to be able to log calls made to it and to provide values on calls to it, using a scripting mechanism.

Monday, 6 February 2023

Sunday, 20 November 2022

Building GCC 12.2.0 on Ventura for aarch64

These are notes on building GCC 12.2.0 and GNAT tools for Apple silicon.

There were two main problems:

  • the base package was built on an Intel machine (lockheed - named after Shadowcat’s companion dragon), running Monterey (macOS 12).
  • the build machine, an M1 mac Mini (temeraire - named after Naomi Novik’s dragon) was by this time running Ventura (macOS 13), but I wanted to make sure that users could continue to run on Monterey.

Saturday, 12 March 2022

Which SDK? choices, choices ...

This note is about configuring GCC on macOS so that your built compiler can be used independently of which Software Development Kit (SDK) is installed.

Sunday, 20 February 2022

SPARK2014 and FSF GCC

This is a note about building SPARK (i.e. gnatprove) against an FSF GCC.

Where’s that library?

This note is about some difficulties using shared libraries (.dylibs) on macOS.

Friday, 8 October 2021

Word, templates, rage

This is with Word 2019 for Mac. Why am I using Word, anyway? - because LibreOffice has stopped working with our membership database in SQLite, and wasn’t working at all well with a CSV export. Oh, and Word doesn’t work with SQLite either.

I managed to create a Word template by careful editing of the LibreOffice version; painful to have to work with CSVs, but better than filling in 100 membership letters by hand (most of our members have email, so a Python script using email.mime, smtplib, sqlite3 etc worked for them, leaving the diehards ...)

OK, the organisation has a new chair, time to update the template.

Where is it? Turns out, ~/Library/Group Containers/UBF8T346G9.Office/User Content/Templates. Well done, Microsoft.

And then, the challenge is to find a way of editing the template. Whatever I try, whatever tips I follow on the net, all I can do is edit a document based on the template, which is not what I need to happen!

I would look into PDFs via fpdf2, but I should only have another year in this post and the next person might have an issue with that. (The same applies to using SQLite, of course. Hmm.)

So I guess its back to LibreOffice.


Monday, 10 June 2019

MacOS Software Development Kit changes

This post is based on the README from the corresponding Github repository.

That repository attempts to cope with expected changes in Apple’s approach to software development kits, specifically where to find the system headers (you’d expect /usr/include).

Monday, 19 November 2018

Mojave vs. GCC

After you've installed Xcode (or, my preference, the Command Line Tools via xcode-select -install) so that you can install and use GNAT, you may expect to be able to compile C code too.

Mojave may surprise you with

$ gcc casing.c -o casing
casing.c:1:10: fatal error: stdio.h: No such file or directory
    1 | #include <stdio.h>
      |          ^~~~~~~~~
      compilation terminated.

The reason, according to this question and its answers, is that Apple's developer tools, in particular the clang compiler, know where to find the include files under /Library/Developer; GCC doesn't (I'm sure it could be made to, but ...) and so we have to add an extra step to install them in the normal place:

$ sudo installer -pkg /Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg -target /
Password:
installer: Package name is macOS_SDK_headers_for_macOS_10.14
installer: Installing at base path /
installer: The install was successful.
You may need to repeat this after macOS or Command Line Tools (or Xcode) updates.

Mojave vs. GDB

Apple's software development tools are based on LLVM, and Apple don't seem to feel it necessary to keep GCC and friends up to date with changes in the Apple tools or security policies.

GDB has been particularly affected by this. You can see why a tool which is capable of interacting with running programs would have to be treated with caution.

Friday, 21 July 2017

Controlling a Crazyflie

This is a note on getting set up to work on a Crazyflie 2.0.

After unpacking, testing and assembling the drone, you need to get some software to talk to it.

Monday, 13 February 2017

GDB vs macOS Sierra

We probably feel downhearted if we need to use the debugger to find out what's wrong with our Ada code.

Under those circumstances, we feel even more frustrated if the debugger doesn't work!

This is exactly what has happened with gdb and macOS Sierra.

Sunday, 14 August 2016

Audacity 2.1.2 and El Capitan

I wanted to update Audacity, but the 2.1.2 version (from the official download site) wouldn’t run: I got can’t open application Audacity.

Sunday, 10 July 2016

The application is damaged and can't be opened

I downloaded a new version of eclipseArduino (Arduino development within Eclipse). After unpacking and moving to /Applications, I get the message

"eclipseArduino" is damaged and can't be opened. You should move it to the Trash.

Huh.

After a lot of poking around, I found this:

  1. Open Gatekeeper settings located in System Preferences > Security & Privacy.
  2. Set Allow applications downloaded from: to Anywhere and confirm by pressing Allow From Anywhere.
  3. Run the application.
  4. Once the application has been successfully launched, it no longer goes through Gatekeeper; so, restore Gatekeeper settings to the default option Mac App Store and identified developers after successfully launching the application.

Saturday, 12 March 2016

Sunday, 30 November 2014

Relocating GCC

AdaCore's doinstall is an excellent way of installing the compiler where you want to. Unfortunately, GCC 4.9 uses the shared libgcc_s.1.dylib, which has no @rpath-type constructs, and so the compiler executables expect to find libgcc_s.1.dylib in the place it was built for. (Not to mention libstdc++.6.dylib.)

Tuesday, 11 November 2014

Building GNAT GPL 2014 for arm-eabi

These notes describe building GNAT GPL 2014 for the Cortex M4 on Mac OS X.

My target board was the STM32M4F29I Discovery.

Friday, 14 February 2014

C libraries and the runpath

This was prompted by a posting on comp.lang.ada; under Mac OS X, if you write a binding to a C library that's in a non-standard place, it's tricky to link against the binding so that the C library is found at run time.