UPCxx build fails on Scott's Mojave system

Dan Bonachea

changed title to UPCxx build fails on Scott's Mojave system
changed version to 2018.9.0 release

UPC++ is building nightly in our Mojave VM, so it must be something about how your system differs from that one.

Here is the point of failure in the provided logs:

Building GASNet...
(in /Users/baden/uxx/upcxx/.nobs/art/d142e839ae5d682a545f81fc51fefa9e4a4aa17a)
make

*** Something FAILED! ***
UPC++ Installation failed. Please report the entire log above to: upcxx@googlegroups.com

Unfortunately this doesn't tell us anything except that configure seems to have succeeded. Presumably the error output from make got lost somewhere.

Suggest you try to manually cd /Users/baden/uxx/upcxx/.nobs/art/d142e839ae5d682a545f81fc51fefa9e4a4aa17a into that directory and run make to see what you get..

2018-11-19T04:53:57+00:00

Scott Baden reporter

I cd’ed into that directory and ran make. The typescript is attached. Scott

2018-11-19T05:20:07+00:00

Dan Bonachea

The typescript is attached. Scott

@sbbaden - I think you forgot to attach the file.

2018-11-19T06:14:40+00:00

Scott Baden reporter

It was attached, I attached it to my email. Scott

2018-11-19T07:40:09+00:00

Dan Bonachea

It was attached, I attached it to my email. Scott

I don't think email attachments are added to comments. You need to login to the BitBucket issue tracker to attach a file.

2018-11-19T07:46:41+00:00

Dan Bonachea

attached scott-mojave-build.txt

Attaching Scott's make output

2018-11-19T07:48:35+00:00

Dan Bonachea

The problem is here:

ld: warning: ignoring file ./libamudp.a, file was built for archive which is not the architecture being linked (x86_64): ./libamudp.a
ld: warning: ignoring file ../../libgasnet_tools-seq.a, file was built for archive which is not the architecture being linked (x86_64): ../../libgasnet_tools-seq.a

somehow part of GASNet got built for a different architecture! However the commands that caused that are not visible because this is a partial remake.

cd back into that dir and run these commands to try and identify the problematic archives:

lipo -info libgasnet_tools-seq.a other/amudp/libamudp.a
otool -hv -arch all libgasnet_tools-seq.a other/amudp/libamudp.a

then try again and this time do make clean all so that we get a complete log of how it goes wrong.

Side note: the fact that nobs hid this make failure from the install script output is separate bug that @jdbachan should probably look into. This could make diagnosis of user errors in the field much harder..

2018-11-19T08:03:03+00:00

Scott Baden reporter

The lipo command tells me the following

lipo -info libgasnet_tools-seq.a other/amudp/libamudp.a
Non-fat file: libgasnet_tools-seq.a is architecture: x86_64
Non-fat file: other/amudp/libamudp.a is architecture: x86_64

The otool output is below.

otool -hv -arch all libgasnet_tools-seq.a other/amudp/libamudp.a106> otool -hv -arch all libgasnet_tools-seq.a other/amudp/libamudp.a
Archive : libgasnet_tools-seq.a
Mach header
      magic cputype cpusubtype  caps    filetype ncmds sizeofcmds      flags
MH_MAGIC_64  X86_64        ALL  0x00      OBJECT     5       1896 SUBSECTIONS_VIA_SYMBOLS
Archive : other/amudp/libamudp.a
Mach header
      magic cputype cpusubtype  caps    filetype ncmds sizeofcmds      flags
MH_MAGIC_64  X86_64        ALL  0x00      OBJECT     5       1576 SUBSECTIONS_VIA_SYMBOLS
Mach header
      magic cputype cpusubtype  caps    filetype ncmds sizeofcmds      flags
MH_MAGIC_64  X86_64        ALL  0x00      OBJECT     5       1816 SUBSECTIONS_VIA_SYMBOLS
Mach header
      magic cputype cpusubtype  caps    filetype ncmds sizeofcmds      flags
MH_MAGIC_64  X86_64        ALL  0x00      OBJECT     5       1656 SUBSECTIONS_VIA_SYMBOLS
Mach header
      magic cputype cpusubtype  caps    filetype ncmds sizeofcmds      flags
MH_MAGIC_64  X86_64        ALL  0x00      OBJECT     5       1656 SUBSECTIONS_VIA_SYMBOLS
Mach header
      magic cputype cpusubtype  caps    filetype ncmds sizeofcmds      flags
MH_MAGIC_64  X86_64        ALL  0x00      OBJECT     5       1736 SUBSECTIONS_VIA_SYMBOLS
Mach header
      magic cputype cpusubtype  caps    filetype ncmds sizeofcmds      flags
MH_MAGIC_64  X86_64        ALL  0x00      OBJECT     4       1800 SUBSECTIONS_VIA_SYMBOLS
Mach header
      magic cputype cpusubtype  caps    filetype ncmds sizeofcmds      flags
MH_MAGIC_64  X86_64        ALL  0x00      OBJECT     4       1400 SUBSECTIONS_VIA_SYMBOLS
Mach header
      magic cputype cpusubtype  caps    filetype ncmds sizeofcmds      flags
MH_MAGIC_64  X86_64        ALL  0x00      OBJECT     4       1320 SUBSECTIONS_VIA_SYMBOLS
Mach header
      magic cputype cpusubtype  caps    filetype ncmds sizeofcmds      flags
MH_MAGIC_64  X86_64        ALL  0x00      OBJECT     4       1720 SUBSECTIONS_VIA_SYMBOLS

2018-11-19T16:18:58+00:00

Scott Baden reporter

Heres the outcome of doing the make clean and then the ‘make’ I couldn’t see a way to attach files. To the Image tracker post Scott

2018-11-19T16:40:36+00:00

Dan Bonachea

Heres the outcome of doing the make clean and then the ‘make’ I couldn’t see a way to attach files

Scott - please visit this issue in the issue tracker and click the "More" button in the top right to attach your file.

Also, when pasting multi-line formatted console output, please surround it with blank lines containing three backquotes (```) to preserve the formatting:

like this

2018-11-19T17:53:18+00:00

Scott Baden reporter

attached typescript

2018-11-19T18:34:57+00:00

Scott Baden reporter

attached. Formatting is good now

2018-11-19T18:35:25+00:00

Dan Bonachea

@sbbaden : I suspect this is the issue:

/usr/local/bin/ar cru libamudp.a amudp_cdefs.o amudp_ep.o amudp_reqrep.o amudp_spawn.o amudp_spmd.o exc.o sig.o socklist.o sockutil.o 
/usr/local/bin/ar: `u' modifier ignored since `D' is the default (see `U')
/usr/local/bin/ranlib -s -c libamudp.a
ranlib: invalid option -- s
ranlib: invalid option -- c

it appears your build is using /usr/local/bin/{ar,ranlib}, which may not be compatible with your current OS version.

Please try rebuilding from scratch after removing /usr/local/bin from your PATH. You could also explicitly set AR=/usr/bin/ar RANLIB=/usr/bin/ranlib, but there might be other incompatible toolchain binaries still sitting there from your old OS.

2018-11-19T19:24:46+00:00

Paul Hargrove

In regards to Dan's observation about /usr/local/bin, one think to try is xcode-select --install in a terminal window.
I am not sure, but this might help ensure that the command-line tools match the Xcode (GUI) version.

Another thing is to ensure homebrew (or other external package manager) has been updated after the upgrade to Mojave. For homebrew the command is brew update; brew upgrade.

2018-11-19T19:28:39+00:00

Scott Baden reporter

xcode was already up to date and so was brew This fails in the same way as on another mac
This is unresolved.

Here is the compiler I use

/usr/bin/g++ -v
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/c++/4.2.1
Apple LLVM version 10.0.0 (clang-1000.11.45.5)
Target: x86_64-apple-darwin18.0.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

2018-11-19T20:05:44+00:00

Scott Baden reporter

I am on the master branch

On branch master Your branch is up to date with 'origin/master'.

2018-11-19T20:07:23+00:00

Dan Bonachea

xcode was already up to date and so was brew This fails in the same way as on another mac
This is unresolved.

Scott - please remove /usr/local/bin from your PATH and start from scratch

2018-11-19T20:30:37+00:00

Scott Baden reporter

This will prevent me from taking advantage of brew https://apple.stackexchange.com/questions/49389/amending-path-so-that-usr-local-bin-is-ahead-of-usr-bin https://stackoverflow.com/questions/34984870/order-of-usr-bin-and-usr-local-bin-and-more-in-path

Scott

2018-11-19T21:28:52+00:00

Dan Bonachea

This will prevent me from taking advantage of brew

Yes but if the ranlib and ar you have installed in /usr/local/bin have not been updated to be compatible with the latest XCode toolchain, then the combination will never work. In short:

using only the XCode toolchain in /usr/bin (and nothing from brew) should work.
Using only the brew toolchain in /usr/local/bin might work, but it needs to include every necessary program (including gcc) all updated to work in Mojave.
Using a combination of the two (as you currently have) is causing a failure and will probably never work.

2018-11-20T00:15:57+00:00

Scott Baden reporter

We need to clarify this in the README. Some users, like me, might conclude not to work on their laptop, because they couldn't work in the environment they are accustomed to and lack specific instructions guidelines for how to ensure that their environment conforms to what upcxx requires. This is our responsibility; users should know how they can work on their own laptop without running awry of upcxx.

2018-11-20T01:50:30+00:00

Dan Bonachea

This is our responsibility; users should know how they can work on their own laptop without running awry of upcxx.

Scott: Keep in mind that Mojave was released a few days before this UPC++ release, well after our code freeze. It's frankly luck that this release works there at all (under the right conditions). We had virtually no real testing there before release.

When our new Mac VM server is installed, we can finally dedicate a VM to run beta versions of Mac OS to help get ahead of these types of issues before the OS is released, which is important since we have such a long release cycle.

I'm not sure documentation is the right solution here, but I agree that we clearly need to do a better job with avoiding build errors when possible, and making unavoidable build failures more transparent.

2018-11-20T03:50:26+00:00

Scott Baden reporter

changed status to resolved

This was resolved

2019-02-27T19:59:33+00:00

Comments (22)