I've noticed this on x86 and ~x86 gentoo-hardened boxes, it works on amd64, but someone confirmed failures on plain ~x86, ~x86 hardened and ~sparc. anyone can confirm on other platforms? Reproducible: Always Steps to Reproduce: 1. run "gcc -ly" Actual Results: $ gcc -ly /usr/lib/gcc/i686-pc-linux-gnu/3.4.6/../../../../i686-pc-linux-gnu/bin/ld: cannot find -ly collect2: ld returned 1 exit status Expected Results: $ gcc -ly /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.2/../../../../lib64/liby.a(main.o): In function `main': (.text+0x18): undefined reference to `yyparse' collect2: ld returned 1 exit status
(In reply to comment #0) It's exactly the other way round - bison-1.875d ebuild fails to remove it on 64bit platforms... :) -rm -f "${D}"/usr/lib/liby.a +rm -f "${D}"/usr/$(get_libdir)/liby.a Anyway, it's not supposed to install this, closing.
So how am I supposed to compile sources that link against -ly?
(In reply to comment #2) > So how am I supposed to compile sources that link against -ly? Fixing the sources sounds like a good idea since nothing should ever need this dummy thing. The application compiled should supply its own main() and yyerror(). You have any example of real application that wants to link to this?
(In reply to comment #3) > (In reply to comment #2) > > So how am I supposed to compile sources that link against -ly? > > Fixing the sources sounds like a good idea since nothing should ever need this > dummy thing. The application compiled should supply its own main() and > yyerror(). > You have any example of real application that wants to link to this? > I do... ghsom http://www.ifs.tuwien.ac.at/~andi/ghsom/ (Growing Hierarchical Self-Organizing Map)
(In reply to comment #4) > (In reply to comment #3) > I do... ghsom http://www.ifs.tuwien.ac.at/~andi/ghsom/ (Growing Hierarchical > Self-Organizing Map) Erm... I definitely don't think this kaboom is due to bison... :P http://rafb.net/p/mdH6KE45.html
liby is required for systems supporting the POSIX C Language Development Utilities optional feature. The base-system folks may choose not to support that, but if they don't, bison/yacc should really be removed from system packages altogether, and added as an explicit dependency for whatever needs it. Forcing an implementation for everyone that lacks required functionality that *is* provided by upstream is extremely poor form at best, in my opinion. Regarding comment #5, that's a difference between GCC 3.4 and newer versions.
Created attachment 150259 [details, diff] installs liby.a I have no clue why the ebuild says " # We do not need this. rm -r "${D}"/usr/lib* || die " I do need this for compiling a parser and its obviously also needed by others.
Created attachment 150260 [details] installs liby.a
The library is still missing in bison 2.4.1 (and is used by the most recent mcast-tools by YOSHIFUJI Hideaki.
really - is there ONE good reason to remove the file? Because I can't think of one. On the other hand there is a lot of breakage caused by its absence. So - where are the valid reasons to remove it?
