macOS linker flags

[Karl-Michael Schindler]

At least on 10.13, the linker is not really happy with the linker flags "-flat_namespace -undefined suppress" in the file "configure/os/CONFIG.darwinCommon.darwinCommon". A better choice seems to be just "-undefined dynamic_lookup". The build succeeds, but I could not do a major test of the functionality, but if this works, this should be applied to all branches.

Regards - Michael.

[mdavidsaver (mdavidsaver)]

Please be more specific about "not really happy"? What error message(s) do you see? Capturing and attaching the output of a clean 'make' run would help.

[Karl-Michael Schindler (karl-michael-schindler)]

Good you asked for details, since i have to correct some. Plain vanilla make runs through without any problems, in particular linker problems. The unhappy party is actually not the linker but the package validator of fink, one of the package managers for macOS. I am currently creating a package description for epics-base. Fink has a package validator and it checks for the use of -flat_namespace and gives this warning:

SERIOUS WARNING: /sw/src/fink.build/root-epics-base3-shlibs-3.16.1-1/sw/lib/libdbCore.3.16.1.dylib appears to have been linked using a flat namespace.
       If this package BuildDepends on libtool2, make sure that you use
          BuildDepends: libtool2 (>= 2.4.2-4).
       and use autoreconf to regenerate the configure script.
       If the package doesn't BuildDepend on libtool2, you'll need to
       update its build procedure to avoid passing
          -Wl,-flat_namespace
       when linking libraries.

When removing -flat_namespace from the configure file, quite a number of perl-related undefined symbols all from Cap5.o show up as errors (complete list in the attachment). They go away by replacing -undefined suppress by -undefined dynamic_lookup in the configure file. I am not the ultimate expert on this topic, but this patch reflects my understanding of the Apple Developer docs at https://developer.apple.com/library/archive/documentation/DeveloperTools/Conceptual/MachOTopics/1-Articles/executing_files.html

[Karl-Michael Schindler (karl-michael-schindler)]

Scroll down the Apple docs to the subchapter "Searching for Symbols".

[Andrew Johnson (anj)]

Hi Michael (KMS),

Despite being responsible for the EPICS build system I don't know very much about the Apple linking stuff, but looking at the document you pointed at should we try to use the -bundle_loader flag for building modules like the Perl CA module?

If I've understood the text properly that tells the linker to check the Perl executable for the routines being called by the Cap5.c code. That might allow us to remove the -undefined suppress flag without having to use -undefined dynamic_lookup instead.

BTW, which versions of EPICS Base are you packaging for fink, and (if you don't mind, because I'm curious) what are you using EPICS for?

- Andrew

[mdavidsaver (mdavidsaver)]

FYI I find that Python distutils on mac uses only "gcc -bundle -undefined dynamic_lookup -arch i386 -arch x86_64 ....".

https://travis-ci.org/mdavidsaver/pipsnoop/jobs/403323791#L4463

[Andrew Johnson (anj)]

@MD - yeah, that's what @KMS is suggesting we use and I'm open to switching to that. I was just wondering though if the linker can do a full check at build-time of all the symbols needed by the bundle it might be interesting to try using that instead.

[Karl-Michael Schindler (karl-michael-schindler)]

I am packaging version 3.16.1 whereby finally aiming for xray-larch-py through pyepics-py (http://cars9.uchicago.edu/software/python/pyepics3). It is an optional addition and may actually never be used.

As already mentioned, my knowledge about the macOS linker is also rather limited. A naive try with -bundle_loader failed:

clang: error: invalid argument '-bundle_loader -install_name' not allowed with '-dynamiclib'

[Andrew Johnson (anj)]

If you're only concerned about the client-side of CA 3.16.1 is Okay, but there were some known issues with the IOC code that we haven't released a fixed version for yet (although they are fixed on the git branch).

AIUI the -bundle_loader flag only applies when building loadable libraries, and requires you to name the executable that will load the bundle (in my case /usr/bin/perl or the equivalent), so it requires cooperation from the Makefile to use that.

I've attached a patch (against 3.15, but it should apply against 3.16 too) which replaces the two flags "-flat_namespace -undefined suppress" with "-undefined dynamic_lookup" in both SHRLIB_LDFLAGS variables. Is this the same change you're suggesting? It seems to work for me, but I haven't fully tested it yet.

[Karl-Michael Schindler (karl-michael-schindler)]

Actually, the two libraries libca and libcom are all, what's needed for pyepics-py. They replace the prebuilt versions of pyepics, which have been built the same way, i mean with -flat_namespace.

The patch is exactly what I suggest. I did not really check the line numbers, but i had a look at the config files of all versions and the lines looked the same. So, i would expect that the patch can be applied to all versions.

[Andrew Johnson (anj)]

For the record I tried using "-bundle_loader /usr/bin/perl" but it didn't work (many "Undefined symbols for architecture x86_64" errors), presumably the Perl binary loads other shared libraries to provide the symbols we're looking for. I will apply this patch to the 3.15 branch and merge it up to the later branches, so it will appear in the Base-3.15.6, 3.16.2 and 7.0.2 releases.

[Karl-Michael Schindler (karl-michael-schindler)]

Looks good to me. Thanks.