Bug 699160 - Consequences of adding LDFLAGS to gsc / gsx build
Summary: Consequences of adding LDFLAGS to gsc / gsx build
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: Build Process (show other bugs)
Version: 9.23
Hardware: All MacOS X
: P4 normal
Assignee: Chris Liddell (chrisl)
QA Contact: Bug traffic
Depends on:
Reported: 2018-03-28 09:52 UTC by Ryan Schmidt
Modified: 2018-04-16 06:17 UTC (History)
1 user (show)

See Also:
Word Size: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Ryan Schmidt 2018-03-28 09:52:47 UTC
In version 9.23, LDFLAGS was added to GCFLAGS:


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:


We are working around the problem by putting "-Lsobin" at the front of our LDFLAGS.
Comment 1 Chris Liddell (chrisl) 2018-03-29 07:24:27 UTC
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.
Comment 2 Chris Liddell (chrisl) 2018-03-30 06:45:12 UTC
This is what I have in mind, that I *think* will work for both cases:


Comment 3 David Kaspar [Dee'Kej] 2018-04-03 05:30:01 UTC
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? :)
Comment 4 Chris Liddell (chrisl) 2018-04-12 04:49:45 UTC
So, I am leaning towards committing the fixes:




and calling this closed....
Comment 5 Chris Liddell (chrisl) 2018-04-16 06:17:41 UTC