Bug 699160

In version 9.23, LDFLAGS was added to GCFLAGS:

http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=469bd6ecf5b223b3e6e3f32ec5a4900866c35e57

This has a couple probably unintended consequences.

In MacPorts, by default we set LDFLAGS="-L/opt/local/lib -Wl,-headerpad_max_install_names -arch x86_64", to ensure that libraries installed by other ports can be found, that any libraries that are built have their install_names padded so they can be relocated later, and that everything is built for the desired architecture.

1. Because the build system combines the CFLAGS, CPPFLAGS and LDFLAGS into a single GCFLAGS variable, it can't provide the correct flags to each tool; it always supplies all flags to all tools. "-arch" flags are appropriate for the linker and the compiler, but "-L" flags and "-Wl,-headerpad_max_install_names" are only meant for the linker. This results in every invocation of the compiler printing the following warnings:

clang: warning: -Wl,-headerpad_max_install_names: 'linker' input unused [-Wunused-command-line-argument]
clang: warning: argument unused during compilation: '-L/opt/local/lib' [-Wunused-command-line-argument]

2. gsc and gsx are built using "$(GLCC) ... -L$(BINDIR) -l$(GS_SO_BASE)". Because of the way GLCC is defined, it contains GCFLAGS, which now contains LDFLAGS, which in our case contains "-L/opt/local/lib". And "-L$(BINDIR) -l$(GS_SO_BASE)" expands to "-Lsobin -lgs". "-lgs" means "search the library paths in order until you find a libgs.dylib library to link with". So it searches for libgs.dylib in /opt/local/lib first, since "-L/opt/local/lib" is the first "-L" flag. And libgs might be there from a previous ghostscript installation. If so, it will use the older libgs there, and will never look in sobin for the newer library.

Since the install_name of libgs changes with each version of ghostscript, that means that if there is a previous version of ghostscript installed, the newly-built gsc and gsx will be linked against the old libgs install_name. Then, when the old ghostscript is uninstalled and the new one is installed, gsc and gsx won't be able to launch because they're linked with the old libgs which no longer exists.

The solution is to change the order of the "-L" flags so that "-L$(BINDIR)" appears before any user-supplied LDFLAGS. But because of the complicated way that the ghostscript build system successively combines variables, including bundling the compiler executable and user-supplied flags into a single variable, rearranging the flags into the correct order is impossible without redesigning the build system.

More information on this problem is in the MacPorts project's bug report:

https://trac.macports.org/ticket/56137

We are working around the problem by putting "-Lsobin" at the front of our LDFLAGS.