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:
Attaching a fix to solve this issue, written by Peter Volkov (Gentoo Developer).
Created attachment 5284 [details]
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:
> make so
> cd sobin
> export LD_LIBRARY_PATH=`pwd`
> ./gsc ../examples/tiger.eps
I will attach a patch to fix this.
Created attachment 5862 [details]
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:
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
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]
New patch, fixing a minor mistake.
(In reply to comment #12)
> Created an attachment (id=6124) [details]
> 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.