openssl@1.1 spitting errors during installation with homebrew.

[marvindanig]

I get the following error due to openssl on my macos mojave & macos catalina machines:

https://gist.github.com/marvindanig/97e3d7175403e6b630a9a79c1caf8dbc

[mattcaswell]

This line looks significant:

ld: warning: ignoring file apps/libapps.a, building for macOS-x86_64 but attempting to link with file built for unknown-unsupported file format ( 0x21 0x3C 0x61 0x72 0x63 0x68 0x3E 0x0A 0x2F 0x20 0x20 0x20 0x20 0x20 0x20 0x20 )

As does this one earlier on:

ar: creating apps/libapps.a
ranlib -c apps/libapps.a || echo Never mind.
ranlib: invalid option -- c

So it seems that your ranlib implementation does not recognise the -c option. That option seems to be specific to macos and comes from these lines in 10-main.conf:

openssl/Configurations/10-main.conf

Lines 1508 to 1526 in 2c52a36

	##### MacOS X (a.k.a. Darwin) setup
	"darwin-common" => {
	inherit_from => [ "BASE_unix" ],
	template => 1,
	CC => "cc",
	CFLAGS => picker(debug => "-g -O0",
	release => "-O3"),
	cppflags => threads("-D_REENTRANT"),
	lflags => "-Wl,-search_paths_first",
	sys_id => "MACOSX",
	bn_ops => "BN_LLONG RC4_CHAR",
	thread_scheme => "pthreads",
	perlasm_scheme => "osx32",
	dso_scheme => "dlfcn",
	ranlib => "ranlib -c",
	shared_target => "darwin-shared",
	shared_cflag => "-fPIC",
	shared_extension => ".\$(SHLIB_VERSION_NUMBER).dylib",
	},

Clutching at straws I'd suggest editing 10-main.conf to replace ranlib -c with ranlib to see if it solves the problem.

Probably @levitte will come up with a better answer.

[jerry153fish]

I had the same issue with binutils installed, it seems that brew uninstall binutils fix the issue.

[follower]

In case it's useful, here's some potentially relevant information from man ranlib:

LIBTOOL(1)

NAME
       libtool - create libraries
       ranlib - add or update the table of contents of archive libraries
[...]
ARCHIVE (or statically linked) LIBRARIES
       Libtool  with -static is intended to replace ar(5) and ranlib.
       For backward compatibility, ranlib is still available, and it
       supports universal files.

[...]

      The following options pertain to the table of contents for
      an archive library, and apply to both libtool -static and ranlib:

[...]

       -c     Include  common  symbols as definitions with respect
              to the table of contents.  This is seldom the intended behavior 
              for linking from a library, as it forces the linking of a library
              member just because it uses an uninitialized global that is
              undefined at that point in the linking.   This  option  is
              included only because this was the original behavior of ranlib.
              This option is not the default.

[...]
Apple Inc.                            January 27, 2014       LIBTOOL(1)

So, it seems the -c may or may not be intentional but if things work without it, it might be reasonable to assume it's not essential? Presumably removing the binutils bin path from PATH for the build would also achieve the desired effect without requiring an uninstall.

Semi-related link about what executable actually gets run on a Mac when certain developer tools are used:

• https://macops.ca/developer-binaries-on-os-x-xcode-select-and-xcrun/

Edit: It appears the -c was intentional according to the (might I say, surprisingly informative & useful; nice work @levitte :) ) commit message where it was added: 0c87341

[levitte]

(might I say, surprisingly informative & useful; nice work @levitte :) )

Thank you :-)
It's quite self-serving, really. I hate it when, a year later, I can't for the life of me understand what I did, so that was an explanation to myself as much as to anyone else.

[levitte]

That being said, I have no idea what the correct course of action is now. I'm having vague ideas that one might check when ranlib version we're dealing with and act accordingly, the same we do with certain Windows and VMS target config attributes. But not having access to a MacOS machine, it's hard to tell how to detect the difference between the variants.

Any help appreciated

[fzyzcjy]

I had the same issue with binutils installed, it seems that brew uninstall binutils fix the issue.

This helps me compile protobuf in macos for ios! thanks you!
related: https://stackoverflow.com/questions/69335349/error-when-compiling-protobuf-for-c-in-ios-undefined-symbols-and-ld-warni?noredirect=1#comment122548676_69335349

[jaydorsey]

That being said, I have no idea what the correct course of action is now. I'm having vague ideas that one might check when ranlib version we're dealing with and act accordingly, the same we do with certain Windows and VMS target config attributes. But not having access to a MacOS machine, it's hard to tell how to detect the difference between the variants.

Any help appreciated

I'm not sure if this is helpful:

❯ which ranlib
/usr/local/opt/llvm/bin/ranlib
❯ ranlib -v
Homebrew LLVM version 13.0.1
  Optimized build.
  Default target: x86_64-apple-darwin21.3.0
  Host CPU: skylake

This is on macOS 12.2.1 with the latest xcode installed, and llvm 13.0.1 installed via homebrew. I'm not sure there's a great way to identify if it's installed or not, but $(brew --prefix)/opt/llvm/bin/ranlib is where the binary is installed, when it's installed.

Uninstalling llvm with brew uninstall llvm fixed this issue for me. This left the default executable as /usr/bin/ranlib. I think I could also have just updated my PATH to move /usr/bin/ranlib earlier (for some reason I couldn't see the default ranlib at first)