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

Assigned To

Authored By

	gouttegd
	Sep 9 2019, 3:32 PM

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

rS Scute
	rSd551cf9884c2 Fix build on MacOS.

Related Objects

Mentioned In: T5394: scute: Build failure with slibtool
Mentioned Here: rSdc2211179ea7: Apply patch from Debian.

Event Timeline

gouttegd created this task.Sep 9 2019, 3:32 PM

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

scute-fix-macos-build.diff2 KBDownload

gouttegd added a commit: rSd551cf9884c2: Fix build on MacOS..Sep 9 2019, 9:06 PM

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

gouttegd mentioned this in T5394: scute: Build failure with slibtool.Apr 12 2021, 10:57 PM

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.