app-admin/apache-tools needlessly appends -Wl,--no-as-needed to LDFLAGS. This package doesn't install any libraries, it installs only executables. Nothing is able to link against executables, so -Wl,--no-as-needed is needless. (www-servers/apache installs some libraries, so -Wl,--no-as-needed still should be appended to LDFLAGS in case of www-servers/apache.)
You'll just get broken binaries, not a big deal. Did you at least read the comments in the ebuild before filing this bug?
(In reply to comment #1) > You'll just get broken binaries, not a big deal. It's impossible. > Did you at least read the comments in the ebuild before filing this bug? Yes.
Created attachment 126975 [details] test.c
Libraries may have references which are resolved at run-time by other libraries, but executables aren't allowed to it. Try: gcc -fPIC -shared -o test.so test.c gcc -o test test.c
Kindly go read the bug referenced in the ebuild.
(In reply to comment #5) > Kindly go read the bug referenced in the ebuild. I have read that bug. It's about modules linking to libraries, not to executables. You can also add int main(); to see better messages: $ cat test.c void function_A () { function_B (); } int main () { function_A (); }
WTH are you talking about here? The binaries themselves (that link against apr) get broken when compiled w/ --as-needed. Leave this bug alone and if you can't live with that, you'll have to stick something into your overlay, we are not going to break this again.
(In reply to comment #7) > The binaries themselves (that link against apr) get broken when compiled > w/ --as-needed. You're wrong. Your lack of knowledge doesn't justify marking this bug as invalid. Please ask someone else, if you don't believe.
Please stop producing further noise here; the append-flags stuff is needed as explained in the ebuild, is not going away and if you dislike it, then you are free to maintain your own apache/apache-tools ebuilds in your own overlay. CLOSED.
(In reply to comment #9) > Please stop producing further noise here You are producing further noise here, not me. This bug is completely valid.
http://www.gentoo.org/proj/en/qa/asneeded.xml#doc_chap2 contains some evidence that I'm right: ---------------------------------------------------------------------------- Failure in final linking, undefined symbols This is the most common error that happens while using --as-needed. It happens during the final linking stage of an executable (libraries don't create problems, because they are allowed to have undefined symbols). The executable linking stage dies because of an undefined symbol that is present in one of the libraries fed to the command line. ---------------------------------------------------------------------------- app-admin/apache-tools doesn't contain any libraries. Only dev-libs/apr, dev-libs/apr-util and www-servers/apache do contain. Shared Apache modules are shared libraries (or shared objects (.so files)). And, of course, libraries (e. g. Apache modules) or executables cannot be linked to executables.
Great. You've produced 15 bugspams so far in mailboxes of every single person who's on bug-wranglers mailing list. Now you go on bugspamming userrel and apache maintainers in addition, because we apparently don't have better things to do than read your rants about overriding unsupported LDFLAGS which break this thing - as clearly shown on Bug 128505. This really rocks. Sp - will you stop this finally or what?
apache herd does not support as-needed
