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.
I can rejig the gsc and gsx targets into separate compile and link stages (which I think ought to be done anyway) and that would solve the compiler warnings. But RedHat/Fedora require that gsc and gsx be linked using the supplied LDFLAGS which, by the sound of it, will still cause problem #2. If I make the changes for separate compile and link stages first. Possibly I can rejig how the -L parameters are done to resolve problem #2. Probably going to need input from deekej on this one, so adding him to the CC list.
This is what I have in mind, that I *think* will work for both cases: http://git.ghostscript.com/?p=user/chrisl/ghostpdl.git;a=commitdiff;h=282560f5ae3 Comments?
Hey guys! The patch looks OK to me. It keeps the LDFLAGS as they are needed in RHEL/Fedora, and the builds pass OK on every system... So I'm okay with these changes. How about you, Ryan? :)
So, I am leaning towards committing the fixes: http://git.ghostscript.com/?p=user/chrisl/ghostpdl.git;a=commitdiff;h=3c4dd5103e1 and http://git.ghostscript.com/?p=user/chrisl/ghostpdl.git;a=commitdiff;h=654d6e88b77 and calling this closed....
Pushed: http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=59c722d075c