Building subsurface on Mac OS 11.x (Big sur)

[Ryan Gardner]

Thanks for the tips.

It turns out that there was one minor tweak I had to do to the build.sh to
get it to work on my machine.

In the build.sh - it first looks for the SDKROOT:

if [ -d /Developer/SDKs ] ; then
     SDKROOT=/Developer/SDKs
elif [ -d
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs
] ; then

 SDKROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs
else
     echo "Cannot find SDK sysroot (usually /Developer/SDKs or"
     echo
"/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs)"
     exit 1;
fi

In my case, I don't have a /Developer/SDKs, but I DO have Xcode 12.5
installed. So it sets the SDKROOT to the XCode directory.

Then the script tries to find the BASESDK inside the SDKROOT - which is
where the problem is:

 BASESDK=$(ls $SDKROOT | grep "MacOSX10\.1.\.sdk" | head -1 | sed -e
"s/MacOSX//;s/\.sdk//")


With XCode 12.5 (at least my installation of it) - that doesn't find
anything because all I have in the SDK directory is:

ls
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs



DriverKit20.4.sdk MacOSX.sdk MacOSX11.3.sdk



When I installed the xcode command line tools, it puts the SDKs under a
different path than either of those specified above:

ls /Library/Developer/CommandLineTools/SDKs

MacOSX.sdk MacOSX10.15.sdk MacOSX11.1.sdk MacOSX11.3.sdk MacOSX11.sdk




I modified the script to have it look in that directory for the SDKROOT
prior to looking in XCode and it found it and set the base SDK to 10.15
(because grep is able to find it).


I wonder if maybe upgrading some older versions (or not installing a full
XCode 12.5?) may have kept an older 10.x sdk in a place that the build.sh
script would find it?


I think that the command-line tools default place for SDKs is now "
/Library/Developer/CommandLineTools/SDKs " - adding that to the path to the
list of places to look for the BASESDK seems like it would be helpful.


I was following the "Manual option" instructions (not using homebrew
packages) - but hidapi failed with an error: Apparently Apple has a version
of libtool but does not have a binary provided for "libtoolize"


Can't exec "libtoolize": No such file or directory at
/usr/local/share/autoconf/Autom4te/FileUtils.pm line 293.

autoreconf: error: libtoolize failed with exit status: 2


I used homebrew to install libtool and then symlinked the 'glibtoolize' to
'libtoolize' and got around that issue:


ln -s /usr/local/bin/glibtoolize /usr/local/bin/libtoolize


I was able to build everything except for the google maps part which
complained "is your environment set up?" or something to that effect - I
can re-run it to get the exact error message but given how long the builds
with "build-deps" take to run, I just had it do a "-quick" build next to
skip over it. Then my build actually worked.


Do you want me to put together a PR with the change to the script to find
the SDKs in the /Library/Developer/CommandLineTools?


Ryan

On Mon, May 17, 2021 at 12:37 PM Dirk Hohndel <dirk at hohndel.org> wrote:

>
>
> On May 17, 2021, at 9:32 AM, Robert Helling via subsurface <
> subsurface at subsurface-divelog.org> wrote:
>
> Hi,
>
>
> I was able to build fine on OS X before I upgraded to Big Sur - when
> running the build scripts now it fails very quickly with two errors:
>
>
> last weekend, I finally got around to update my Mac to Big Sur as well. By
> now, I can successfully build here as well but I remember, in the process I
> also saw a complaint about -lSystem but I cannot remember how that went
> away. Reinstalling Xcode command line tools and throwing away the old build
> directory were definitely required at some point.
>
> But what kept took me the longest was understanding why my builds with
> debug symbols and without optimisation (so the debugger is usable) failed
> with realy strange error messages: Realising that the compiler flag for
> this is not „-G“ but in fact „-g“ (and that -G requires another argument so
> the next bit on the command line get eaten up).
>
>
> Oh, yes, definitely. Blow away your build directory, your install-root
> directory and any other build artifact that you have.
> You have to restart with a fresh build. Big Sur breaks a lot of things
> (and is IMHO the worst macOS release since OS 9 - I haven't upgraded a
> single system to it with the exception of that one build VM... BigSur
> breaks so many things, so many devices, including trivial stuff like wired
> ethernet adapters, HDMI adapters, tons of software... and depending on how
> things go, in the "upgrade" you sometimes end up with a complete second set
> of all apps in some random directory, including a second system preferences
> app, which prevents system preferences from working with inanely stupid
> non-sensical error messages... what a mess)
>
> /D
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20210517/168ee343/attachment.htm>