Gentoo's package manager Portage reports various QA issues when installing a package. We got a bugreport about partially ignored LDFLAGS, see URL and original bugreport for gs 8.64 at http://bugs.gentoo.org/show_bug.cgi?id=209803. * QA Notice: Files built without respecting LDFLAGS have been detected * Please include the following list of files in your report: * /usr/bin/gsx Attaching a fix to solve this issue, written by Peter Volkov (Gentoo Developer).
Created attachment 5284 [details] ghostscript-gpl-8.64-respect-gsc-ldflags.patch
Thanks for the patch. I've committed a variation as r9948.
The fix for this bug in r9948 caused a regression in building dynamically linked gsc/gsx with 'make so'. When I do: > configure > make so > cd sobin > export LD_LIBRARY_PATH=`pwd` > ./gsc ../examples/tiger.eps Segmentation fault I will attach a patch to fix this.
Created attachment 5862 [details] 0001-Fix-unix-so-build-regression.patch
Please see the issue in comment 3. I am not sure this is critical for you, but as the 8.71 freeze is here, I think it is a good idea to look at this before releasing.
Created attachment 5952 [details] an alternative patch to fix 'make so' It does similiar thing as attachment 5862 [details] - the important thing is that the shared library needed to be compiled with a different LDFLAGS compared to those two binaries which depends on the library. I think this is a better patch than 5862 as it also applies user-supplied LDFLAGS to those two binaries, but feel free to comment and/or differ.
In reply to comment 6: The make rules to build $(GSSOC_XE) and $(GSSOX_XE) already contain LDFLAGS, so I think there is no need to specify LDFLAGS in the 'so' target. Personally I think we should never redefine the user variable LDFLAGS anywhere. The variable LDFLAGS must be part of the command lines that do the linking only. Therefore I think patch 5862 is better. But that being said, I would be happy if any of these patches fixing this bug would be applied, either 5862 or 5952.
Hmm, there were two things which I didn't like about patch 5862 - introducing another variable (GS_XE_LDFLAGS) which is essentially single-use and does not differ at all from LDFLAGS_SO, and it modifies the GS_XE target - see this sentence - 'Shared object is built by redefining GS_XE in a recursive make' It appears that the GS_XE target is used for many things. Actually just using LDFLAGS_SO where GS_XE_LDFLAGS is , is probably best, except again, the GS_XE target is used for multiple binaries, and also the include-order in most files is unixlink.mak then unix-dll.mak . In any case, the bottom of the problem is that shared libraries needs a different LDFLAGS from executables.
In reply to comment 8: I disagree with you :-). You say you do not like the fact that patch 5862 changes the GS_XE target, but in patch 5952 you do essentially the same thing and worse: by redefining LDFLAGS you add LDFLAGS_SO to it. What's worse about this, is that potentially, this LDFLAGS_SO gets passed to all other targets that use LDFLAGS. To prevent this, it is wise to use a target specific LDFLAGS: GS_XE_LDFLAGS. As you noted, shared objects are build by redefining GS_XE. In my opinion, because executables need different LDFLAGS then shared objects, when you redefine GS_XE, you should also redefine GS_XE_LDFLAGS, which is what I did in patch 5862. Keeping both LDFLAGS_SO and GS_XE_LDFLAGS, while GS_XE_LDFLAGS=LDFLAGS_SO is done because GS_XE_LDFLAGS is a 'build variable', whereas LDFLAGS_SO is a parameter that can change depending on the linker you build with or the platform you build on.
I am not sure I follow all the arguments. There are 3 ways the make system inherits variables definitions - as environment variables (export VAR1=value1), specified on the command line of invocation of make (e.g. "make VAR1=value1) or within the Makefile. the variable LDFLAGS has special/conventional meaning because there is an implicit linker rule if none is specified in the Makefile (and in such cases, the linker will take it from the environment variable). LDFLAGS to mean 'the (current) linker flags', given we have to have a different set of flags for shared libraries, there is a need for a 2nd variable _SO (or at least an 'additional' part to it), I am not sure where a 3rd one fit in, especially when it changes between invocations. Anyhow, even reverting r9948 is preferable to the current state where 'make so' does not give correct executables. I am against making more changes/additons to _the body of_ the GE_XE target, since it is the most important one.
*** Bug 691208 has been marked as a duplicate of this bug. ***
Created attachment 6124 [details] 0001-Fix-unix-so-build-regression.patch New patch, fixing a minor mistake.
(In reply to comment #12) > Created an attachment (id=6124) [details] > 0001-Fix-unix-so-build-regression.patch > > New patch, fixing a minor mistake. I'd prefer a solution that does not modify the GS_XE target itself. The reason being that the target is invoked multiple times with different environments to build different things, and to make it formally more complicated (and keeping track of how/where it is invoked and which variables are defined to what values) by introducing another variable which takes different values per invocation. But in any case, any solution is better than doing nothing.
Grabbing a Ralph's bugs.
My patch (attachment 5952 [details]) committed as r11169 , since I'll likely inherit new 'Build Process' bugs - I'd prefer to fix things I break, rather than others break.
Meant to close with the last comment.