[Bug-gnucap] Patch to fix build issues on macOS

[Ryan Schmidt]

Hi,

I wanted to let you know that I updated the gnucap port in MacPorts to the 
latest stable version, and added a gnucap-devel port for the latest development 
version. I think I have been successful, to the extent that it prints this:

Gnucap : The Gnu Circuit Analysis Package
Never trust any version less than 1.0
Copyright 1982-2013, Albert Davis
Gnucap comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome
to redistribute it under the terms of
the GNU General Public License, version 3 or later.
See the file "COPYING" for details.
main version: develop 2018.08.31
core-lib version: develop 2018.08.31
default plugins: develop 2018.08.31
gnucap>

I don't know anything about gnucap so I don't know how to exercise it further.

I needed to patch the build system to get it to build on macOS and to work the 
way I wanted so I'm sharing the patch with you in the hopes that you might 
include it or something similar in an upcoming release so that we don't have to 
maintain this patch forever:

https://github.com/macports/macports-ports/blob/6087abd855bc3197394a3d6a818c0f9f56f6669d/science/gnucap/files/fix-build-system.patch

To explain the patch:

Where other UNIX-like operating systems use LD_LIBRARY_PATH to find shared 
libraries that haven't been installed yet, macOS uses DYLD_LIBRARY_PATH for 
that purpose, so I made the Makefile use the right variable based on OS.

Where other UNIX-like operating systems use the flag -shared to build shared 
libraries and loadable modules like plugins and use the suffix .so for both, 
macOS distinguishes between the two. It prefers the flag -dynamiclib and the 
suffix .dylib for shared libraries that are linked to programs, and it uses the 
flag -bundle for loadable modules. I kept the .so suffix for the plugin since 
that seems to be common in software that didn't originate on macOS, though 
Apple would apparently prefer it if the suffix were .bundle; the extension 
shouldn't matter though.

Building the plugin failed at link time, citing undefined symbol errors. These 
symbols are presumably provided by the program into which the plugin gets 
loaded, so I added the flag -undefined dynamic_lookup which silenced the 
errors. The macOS linker defaults to requiring all symbols to be resolvable at 
link time. My understanding is that the Linux linker defaults to allowing 
dynamic lookups.

Shared libraries on macOS embed their absolute installation path. This is 
unimportant for loadable modules since you already know where you're loading 
them from, but for shared libraries linked to an executable (or to other 
libraries) it's essential that the path is specified correctly. The easiest way 
to do it is to supply it via the -install_name flag at link time.

I wanted to be able to specify environment variables like CXX, CXXFLAGS, 
CPPFLAGS and LDFLAGS at the time that I ran the configure script and to have 
these be honored at build time, as would be the case for an autotools-based 
project, so I modified the build system to do that.

Let me know if you have any questions or need anything else.