Page MenuHome GnuPG

Scute > 1.4.0 does not work with MacOS X
Closed, ResolvedPublic

Description

Scute 1.5.0 and the current master branch fail to compile on Mac OS X (tested on Sierra 10.12.6, triplet x86_64-apple-darwin16.7.0).

Compilation fails when attempting to link the test programs to the scute module:

*** Warning: lib scute.so is a module, not a shared library

*** And there doesn't seem to be a static archive available
*** The link will probably fail, sorry
libtool: link: gcc -Wall -Wno-pointer-sign -Wpointer-arith -g -O2 -o .libs/t-link t-link.o  ../src/.libs/scute.so -lassuan -L/Users/gattat01/macports/lib -lgpg-error
ld: can't link with bundle (MH_BUNDLE) only dylibs (MH_DYLIB) file '../src/.libs/scute.so' for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

I am not familiar with Mac OS, but it seems at least part of the problem stems from libtool generating a .so file instead of a .dylib file. With Scute-1.4.0, the compilation successfully yields a libscute.dylib file which works as expected with Firefox.

Reverting commit dc2211179 (which changed the name of the library from libscute to scute) allows to generate a .dylib file again and to pass the tests, but the resulting module cannot be loaded by Firefox (which simply complains of being Unable to add module).

Details

Version
scute-1.5.0, master

Revisions and Commits

Event Timeline

werner added a subscriber: werner.

Given that 1.5 already had that problem, I would suggest to ignore that bug for the 1.6 release. We can work on that later.

If I understand correctly, the problem stems from the -module flag added to the LDFLAGS in commit dc2211179. It's that flag that instruct libtool to create a bundle (.so file) instead of a dynamically linked shared library (.dylib file). But that flag is needed to force automake to accept that the library is to be named scute instead of libscute (without that flag automake errors out, complaining that scute.la is not a standard libtool library name).

An easy (if somewhat ugly) fix would be to revert to calling the library libscute, only on Mac OS. I just tested the attached patch, which seems enough to make it work. I think I will apply that for now. A better solution could always be found later

werner triaged this task as Normal priority.Sep 10 2019, 4:18 PM
gouttegd claimed this task.

A better solution could always be found later

In the end I’ve never found a better solution. But Scute is actually working fine on Mac OS X, so let’s just keep the current solution – its only drawback is that, as explained above, it forces us to call the library libscute.dylib on MacOS, instead of simply scute.dylib. I think we can live with that. Closing now.