Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 308373 - LDFLAGS in profile make.defaults need -Wl escaping
Summary: LDFLAGS in profile make.defaults need -Wl escaping
Status: RESOLVED OBSOLETE
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Eclasses (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo Toolchain Maintainers
URL: http://www.gnu.org/software/automake/...
Whiteboard:
Keywords:
Depends on:
Blocks: portage-multilib
  Show dependency tree
 
Reported: 2010-03-07 20:29 UTC by Nathan Phillip Brink (binki) (RETIRED)
Modified: 2017-08-29 18:16 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
profile-multilib-LDFLAGS-escape.patch (profile-multilib-LDFLAGS-escape.patch,4.55 KB, text/plain)
2010-03-07 20:35 UTC, Nathan Phillip Brink (binki) (RETIRED)
Details
-L flags are fixed just for completeness (profile-multilib-LDFLAGS-escape-r1.patch,4.54 KB, patch)
2010-03-08 18:46 UTC, Nathan Phillip Brink (binki) (RETIRED)
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Nathan Phillip Brink (binki) (RETIRED) gentoo-dev 2010-03-07 20:29:30 UTC
LDFLAGS in /etc/make.conf has always been given the -Wl escaping. There exists flag-o-matic.eclass:raw-ldflags() to strip LDFLAGS of -Wl in the proper circumstances. Thus, the LDFLAGS specifications in profiles should be properly/consistently escaped.

See attached patch.
Comment 1 Nathan Phillip Brink (binki) (RETIRED) gentoo-dev 2010-03-07 20:35:31 UTC
Created attachment 222569 [details]
profile-multilib-LDFLAGS-escape.patch
Comment 2 Nathan Phillip Brink (binki) (RETIRED) gentoo-dev 2010-03-07 21:14:53 UTC
See URL where autotools documentation explains that LDFLAGS is defined as:
``Extra flags to give to compilers when they are supposed to invoke the linker, `ld'. ''
Comment 3 Harald van Dijk (RETIRED) gentoo-dev 2010-03-08 02:05:05 UTC
That's LDFLAGS_${abi}, not LDFLAGS. LDFLAGS_${abi} isn't supposed to be used in anything like Makefiles. Compare CFLAGS_${abi} which automatically gets passed to gcc, g++, g77, while CFLAGS get passed to gcc when Makefiles let it. To be honest I'm not sure where LDFLAGS_${abi} get used, so I can't say that your suggestion is wrong, but if it needs to be done it's for different reasons.
Comment 4 Nathan Phillip Brink (binki) (RETIRED) gentoo-dev 2010-03-08 02:59:59 UTC
(In reply to comment #3)
> That's LDFLAGS_${abi}, not LDFLAGS. LDFLAGS_${abi} isn't supposed to be used in
> anything like Makefiles. Compare CFLAGS_${abi} which automatically gets passed
> to gcc, g++, g77,
How does this mechanism work and where is it used? Unfortunately, the only experience I have in dealing with CFLAGS_${ABI} is within tommy's portage-multilib. So far, portage-multilib cycles through ABI=amd64 and ABI=x86 and looks into CFLAGS_${ABI} when it needs to coax the compiler into producing code for a specific ABI. The end effect is that CFLAGS and CXXFLAGS have `` -m32'' appended to them when building ABI=x86 code.

> while CFLAGS get passed to gcc when Makefiles let it. To be
> honest I'm not sure where LDFLAGS_${abi} get used, so I can't say that your
> suggestion is wrong, but if it needs to be done it's for different reasons.
I would like to see LDFLAGS_${ABI} used by portage-multilib in the same way it uses CFLAGS_${ABI}. When one has X, X_A, and X_B, one would assume that X="${X} ${X_A}" and X="${X} ${X_B}"; one would assume that X_A and X_B share the same syntax as X as there is obviously a semantic similarity between X_${blah} and X.

Tommy and you seem to suggest that LDFLAGS should only contain flags that may be passed directly to ld. However, this is obviously not the case or at least the current practice; there is the well-known LDFLAGS="-Wl,--as-needed" in  /etc/make.conf. I'd like to presume an amd46 multilib setup in the following. If LDFLAGS_x86 contains the flags necessary to convince the linker to use 32-bit support, then I'd expect to be able to append them to the similarly-named LDFLAGS variable.

Now, there is a slight issue here. On such a system, CFLAGS_x86="-m32" and (I would like) LDFLAGS_x86="-Wl,-m,elf_i386". When compiling a 32-bit app, I'd append ${K}FLAGS_${ABI} to ${K}FLAGS. This would result in a command like:
$ x86_64-pc-linux-gnu-gcc -o myapp -m32 -Wl,-m,elf_i386 myapp.c -lconfuse
But this would have the same effect as:
$ x86_64-pc-linux-gnu-gcc -o myapp -m32 myapp.c -lconfuse
This will be redundant and useless for most packages, especially those allowing automake to handle all calls to the compiler.

But there _are_ package which call ld directly (such as media-plugins/live). It is for these packages that the raw-ldflags() function from flag-o-matic.eclass was written. When a package calls ld directly, it doesn't (and shouldn't) consider the presence of ``-m32'' in CFLAGS. But it will have to, by Gentoo policy, respect the value of a LDFLAGS (although Gentoo has to preprocess -Wl in this case).

I am merely requesting that portage-multilib be allowed to treat LDFLAGS_${ABI} in the same way that it has been treating CFLAGS_${ABI}. I would appreciate a pointer to where LDFLAGS_${ABI} would be used outside of multilib-portage; I don't really have an idea of where to look. I suppose that portage-multilib could have a function to automatically add ``-Wl,'' quoting to the values of LDFLAGS_${ABI} instead. And sorry for this lengthy argument, I just want to clarify my understanding so that it may be better criticized ;-).
Comment 5 Harald van Dijk (RETIRED) gentoo-dev 2010-03-08 17:41:18 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > That's LDFLAGS_${abi}, not LDFLAGS. LDFLAGS_${abi} isn't supposed to be used in
> > anything like Makefiles. Compare CFLAGS_${abi} which automatically gets passed
> > to gcc, g++, g77,
> How does this mechanism work and where is it used? Unfortunately, the only
> experience I have in dealing with CFLAGS_${ABI} is within tommy's
> portage-multilib. So far, portage-multilib cycles through ABI=amd64 and ABI=x86
> and looks into CFLAGS_${ABI} when it needs to coax the compiler into producing
> code for a specific ABI. The end effect is that CFLAGS and CXXFLAGS have ``
> -m32'' appended to them when building ABI=x86 code.

I don't know about multilib portage, but on a standard Gentoo system gcc-config handles this. Look in gentoo-x86/sys-devel/gcc-config/files/wrapper-1.5.1.c.

> I would like to see LDFLAGS_${ABI} used by portage-multilib in the same way it
> uses CFLAGS_${ABI}. When one has X, X_A, and X_B, one would assume that X="${X}
> ${X_A}" and X="${X} ${X_B}"; one would assume that X_A and X_B share the same
> syntax as X as there is obviously a semantic similarity between X_${blah} and
> X.

It would make sense, but if anything relies on the current LDFLAGS_${abi} format, things would break.

> Tommy and you seem to suggest that LDFLAGS should only contain flags that may
> be passed directly to ld.

No, that's not what I'm saying. LDFLAGS, as you rightly pointed out, get passed to gcc, which will strip them of -Wl options. I'm saying LDFLAGS_${abi} may be different from LDFLAGS, despite the deceptively similar name.

> But there _are_ package which call ld directly (such as media-plugins/live). It
> is for these packages that the raw-ldflags() function from flag-o-matic.eclass
> was written. When a package calls ld directly, it doesn't (and shouldn't)
> consider the presence of ``-m32'' in CFLAGS. But it will have to, by Gentoo
> policy, respect the value of a LDFLAGS (although Gentoo has to preprocess -Wl
> in this case).

It probably shouldn't consider any LDFLAGS_x86 variable either; such variables should be handled as transparently as CFLAGS_x86 so that they are also useful outside of portage. And if binutils-config would read ABI and LDFLAGS_${abi}, in the same way that gcc-config reads ABI and CFLAGS_${abi}, then LDFLAGS_x86 must definitely not be escaped.

@toolchain: any comments on this? Would an update of binutils-config to support ABI LDFLAGS be acceptable to you?
Comment 6 SpanKY gentoo-dev 2010-03-08 18:27:45 UTC
off the top of my head, nothing in the tree uses LDFLAGS_${abi}.

Harald's statements are correct, but not for the reasons you're thinking Nathan.  afaik, they were originally designed to be sent behind the back of the compiler driver and directly to the linker.  this is not the normal behavior of "LDFLAGS" itself of course.

also, your mangling of -L into -Wl is incorrect.  that should be passed to the compiler driver (gcc) and not sent behind its back directly to the linker.

i dont think it makes sense to try and continue the crap we have today with gcc-config and CFLAGS_${abi}.  it's known to cause problems with frontend wrappers like ccache and distcc, and we've already started to phase it out of gcc-config.  we should follow this trend and punt LDFLAGS_${abi} from the profiles and avoid even implying it ever existed.  people who want to invoke the linker directly (like the media-plugins/live package) should be fixed to invoke the compiler driver instead.  there is a lot of logic in it related to cross-compiling/multilib and it's not maintainable to try and reproduce in the linker or any linker wrappers.  same goes with trying to invoke the assembler directly (which will have similar problems).
Comment 7 Nathan Phillip Brink (binki) (RETIRED) gentoo-dev 2010-03-08 18:39:09 UTC
(In reply to comment #6)
> Harald's statements are correct, but not for the reasons you're thinking
> Nathan.  afaik, they were originally designed to be sent behind the back of the
> compiler driver and directly to the linker.  this is not the normal behavior of
> "LDFLAGS" itself of course.
OK.

> also, your mangling of -L into -Wl is incorrect.  that should be passed to the
> compiler driver (gcc) and not sent behind its back directly to the linker.
Oh, I wasn't thinking when I made that change; but in light of your response, I see that portage-multilib should not rely on LDFLAGS_${ABI}.
 
> people who want to invoke
> the linker directly (like the media-plugins/live package) should be fixed to
> invoke the compiler driver instead.
OK, this is exactly what I need to know to continue :-). Thanks for your response and help. I'll now try to fix buildsystems which directly invoke ld, as, and the like.
Comment 8 Nathan Phillip Brink (binki) (RETIRED) gentoo-dev 2010-03-08 18:46:33 UTC
Created attachment 222707 [details, diff]
-L flags are fixed just for completeness
Comment 9 SpanKY gentoo-dev 2010-03-08 18:48:36 UTC
it's sad you had to pick media-plugins/live as the example of running the linker directly as its build system is terrible.  ive done a bit of porting work with it before (see the Blackfin files in it), so i wouldnt be surprised if you had a tough time converting it.  or maybe i'm being overly pessimistic.
Comment 10 Nathan Phillip Brink (binki) (RETIRED) gentoo-dev 2010-04-06 23:20:30 UTC
(In reply to comment #9)
> it's sad you had to pick media-plugins/live as the example of running the
> linker directly as its build system is terrible.  ive done a bit of porting
> work with it before (see the Blackfin files in it), so i wouldnt be surprised
> if you had a tough time converting it.  or maybe i'm being overly pessimistic.

I was able to fix it hackily to use a system-installed libtool. See bug 309681 for the patch if you wouldn't mind criticizing my methodologies.

> we should follow this trend and punt LDFLAGS_${abi} from the
> profiles and avoid even implying it ever existed.

Would you say the same for ASFLAGS_${abi}?
Comment 11 SpanKY gentoo-dev 2010-04-09 04:58:39 UTC
i cant see much value in ASFLAGS_${abi} either.  reasonable gcc frontends should pass appropriate assembler flags transparently when given related CFLAGS.
Comment 12 Andreas K. Hüttel archtester gentoo-dev 2017-08-29 18:16:18 UTC
OK reading through all the comments I understand that everyone agrees the original request should not be fulfilled. Closing as obsolete then. Please file new bugs for new feature requests.