Created attachment 331661 [details] quota-3.17-r1:20121205-182007.log 4.00 is affected as well CFLAGS are missing from linking commands, but gnu docs say they should be included in _every_ gcc invocation. Correct me if I am wrong. https://www.gnu.org/prep/standards/html_node/Command-Variables.html#Command-Variables
gcc don't uses CFLAGS at link time, so, apart the gnu docs, for me is not a bug..
(In reply to comment #1) > gcc don't uses CFLAGS at link time, so, apart the gnu docs, for me is not a > bug.. that's what I thought, but a) it would only be true if all source files have been compiled prior to the gcc linking command and b) I see QA files bug for this too also: usually autotools standard behavior is to include cflags in all gcc invocations, same for libtool
(In reply to comment #1) that's not really true. gcc knows nothing of $CFLAGS or $LDFLAGS or such variables. people often times put flags into $CFLAGS that implicitly affect linking steps w/out also putting them into $LDFLAGS. we're not talking about just ABI flags but even simple stuff you might not realize *do* affect linking like -pthread or -fopenmp.
(In reply to comment #3) > (In reply to comment #1) > > that's not really true. gcc knows nothing of $CFLAGS or $LDFLAGS or such > variables. people often times put flags into $CFLAGS that implicitly affect > linking steps w/out also putting them into $LDFLAGS. we're not talking > about just ABI flags but even simple stuff you might not realize *do* affect > linking like -pthread or -fopenmp. @mike If these people will put linking stuff into CFLAGS, it's _obviously_ that they will put $(CFLAGS) into linking process. So, viceversa if there isn't $(CFLAGS) into linking 'string' means that in CFLAGS there is nothing that can interest the linking process. If there are people that put linking stuff into CFLAGS and they omit $(CFLAGS) from the linking process please let me know.
(In reply to comment #4) you missed my point. there are many gcc flags which obviously affect compiler output (e.g. -pthread or -fopenmp) but which are not obvious that they also affect linking steps. hence it is not uncommon for people to put them into CFLAGS and forget about LDFLAGS, especially when the linking behavior only happens on some platforms. i'm not talking about flags that are obviously linking related (like -lfoo or -Wl,-z,...).
yeah, but after talking with QA about this too I think it's mostly not worth a bug report unless it becomes an actual issue for a package
(In reply to comment #6) that depends on what you mean by "isn't an issue". if you have a toolchain which supports multiple ABIs and attempt to build with CFLAGS=<abi selector>, all packages (like this one) will most likely fail to link, or produce an unusable executable. we know this as a fact. if you mean you just want to wait for someone to complain, i suspect most people won't bother. they'll hack it up or do something else until it happens to work.
+ 21 Apr 2014; Julian Ospald <hasufell@gentoo.org> quota-4.01.ebuild, + +files/quota-4.01-cflags.patch: + respect CFLAGS in linking command wrt #446281
