Twice when trying to upgrade to the new mips 2007.1-dev profile and ~mips (as now expected), I trashed my system's ability to compile additional programs. I finally think I have traced this back to binutils-2.18-r1. For O2's where I keep binutils fixed at the "old" sys-devel/binutils-2.17, I can compile everything ~mips (with the exception of glibc and e2fsprogs). However, if one upgrades to binutils-2.18-r1, directly after the upgrade compiling of all subsequent programs fails during configuration with: checking whether the C compiler works... configure: error: cannot run C compiled programs. If you meant to cross compile, use `--host'. Reproducible: Always Steps to Reproduce: 1. upgrade from binutils-2.17 to binutils-2.18-r1 2. while binutils-2.18-r1 compiles and links, it kills subsequent compiling Actual Results: See attached (just one example of a subsequently borked environment after upgrade to binutls-2.18-r1.) Expected Results: No more compilations possible. All programs one attempts to upgrade (that I have checked) end up with the same configuration error. Best evidence I have to a problem with binutils is that a simple regression to binutils-2.17 (emerge --usepkgonly =sys-devel/binutils-2.17 from previously saved version) fixes the environment. Best counter argument is that perhaps one of the programs I have still yet been able to compile ~mips (glibc and e2fsprogs) under binutils-2.17 might have to be upgraded *BEFORE* upgrading binutils to 2.18-r1. If this counter argument is right, I would love to know *HOW* to upgrade glibc or e2fsprogs. I have submitted a bug report on e2fsprogs and will shortly on glibc too.
Created attachment 144796 [details] exemple of resulting spoiled environment (com_err won't even compile) It takes approx. 1 day to compile binutils on and old SGI O2, so additional testing will take time. I am purposefully NOT cross-compiling to make simplify debugging of the overall ~mips/new profile upgrade.
Created attachment 144798 [details] emerge --info (note: after regression to binutils 2.17) emerge --info with the only change to the borked environment of binutils-2.18 being regression to binutils-2.17.
> !!! Please attach the following file when seeking support: > !!! /var/tmp/portage/sys-libs/com_err-1.40.6/work/e2fsprogs-1.40.6/config.log Do it, please. Also emerge --info is missing.
(In reply to comment #3) > > !!! Please attach the following file when seeking support: > > !!! /var/tmp/portage/sys-libs/com_err-1.40.6/work/e2fsprogs-1.40.6/config.log > > Do it, please. Also emerge --info is missing. > Hi Jakub, I think you just didn't see them. Both were attached with yesterday's bugs submission. (At least they show up in bugzilla for me.) /Mike
That's not config.log what you've attached. The attach the file requested above.
(In reply to comment #5) Sorry about that. Why didn't you just *say* you wanted config.log? :-) Anyway, as may be evident from the earlier text, the regression test I did makes providing that particular log at least two days away since when I regressed to the working binutils, I tested to see if I could indeed successfully compile e2fsprogs and it was indeed no problem. The success wiped out the file you requested. Luckily (?) however, every program I tried to compile after the allegedly broken binutils bombed the same way so I provide all the files I can think of for findutils instead. e2fsprogs was just one example of a broken compile after binutils upgrade. Attachments coming as fast as I can upload them.
Created attachment 144816 [details] emerge log for findutils-4.3.13
Created attachment 144818 [details] findutils-4.3.13 config.log
Created attachment 144820 [details] findutils-4.3.13 ebuild environement
most likely due to GNU hash support add -Wl,--hash-style=sysv to your LDFLAGS and see if things build
(In reply to comment #10) Added LDFLAGS="-Wl,--hash-style=sysv" to /etc/make.conf but unfortunately things seems worse. Now binutils-2.18-r1 doesn't build and itself dies with "configure: error: C compiler cannot create executables" (precisely the problem it was causing for other programs *after* it was installed before. I will attach the emerge and config.log for the problem trying to build it now with LDFLAGS set.
Created attachment 144912 [details] binutils-2.18-r1 emerge log with LDFLAGS
Created attachment 144913 [details] binutils-2.18-r1/work/build/config.log with LDFLAGS
As a sort of (over simplified?) test that my environment for building binutils was not borked, (esp. since I regressed binutils back to 2.17) I did this in the interactive shell: louie ~ # binutils-config -l [1] mips-unknown-linux-gnu-2.17 * louie ~ # arch mips64
i'm guessing you switched to binutils-2.17 and *then* tried to use --hash-style. obviously that wont work as binutils-2.17 does not support hash-style. what i wanted you to do is trying building a simple test app using binutils-2.18 and -Wl,--hash-style=sysv and see if it works.
(In reply to comment #15) Your guess is correct. I am now in the process of building binutils-2.18, then added the LDFLAGS, then building some simple test app using that environment. I will report back.
(In reply to comment #16) OK, so far with the simple test, it worked fine. I upgrade ** Installing sys-devel/binutils-2.18-r1 ** Uninstalling sys-devel/binutils-2.17 Then added to make.conf: # grep LDFLAGS /etc/make.conf LDFLAGS="-Wl,--hash-style=sysv" Then rebuilt "which" as a test: # update -a which [ebuild R ] sys-apps/which-2.19 0 kB and which still seems to work. At this point my questions are: (1) Is this the fix I should use from here on out? Will it have any negative side effects, or do you consider this more of a temporary workaround? (2) Any suggestions on what software to (re)build next for an even more robust test? Just as a side note: "Yipee!" finally *everything* is compiled and runnnig under ~mips with the new 2007.1-dev profile we're supposed to use. I appreciate the help. /Mike
i actually want to remove mips gnu-hash from binutils-2.18 altogether. i've found it causes other (related?) problems ('relocation truncated to fit: R_MIPS_GOT16' errors) when building very large packages. the original patch[i] mentions that it doesn't take multiGOT into consideration, and i've found that removing gnu-hash support fixes my issues. kumba, any word on that? we'd have to drop 13_all_mips-gnu-hash-support.patch and make 77_all_generate-gnu-hash.patch conditional or something. [i] http://sourceware.org/ml/binutils/2007-08/msg00387.html
i have no problem droppin the patches ... kumba just needs to give The Word
Word is green. Supergreen. And we'll have to yank the mips glibc patch too (I think we have one there at last check). I had those tossed in for some reason....I think cause I *thought* .gnu.hash support would go into binutils mips, but I didn't know that it was rejected because it broke the MIPS ABI.
patch has been dropped in glibc-2.7-r2 ive also removed it from all binutils patchsets in cvs ... i'll push out an updated 2.18 patchset and close out the issue
The list of packages compiled successfully with LDFLAGS="-Wl,--hash-style=sysv" up to now is growing large, e.g., sys-apps/which-2.19 sys-libs/timezone-data-2008a app-portage/eix-0.12.1 dev-libs/glib-2.16.1 sys-apps/man-pages-2.79 sys-libs/com_err-1.40.8 sys-libs/ss-1.40.8 sys-fs/e2fsprogs-1.40.8 net-misc/rsync-3.0.0-r1 sys-fs/udev-119 ...just to name the first few. I have had zero problems so far... From a user perspective, is this wrong to proceed this way? Ryan Hills mentioned that he want to remove mips gnu-hash from binutils-2.18 altogether. From what I understand, which is perhaps not much, --hash-style=sysv is not --hash-style=gnu so if gnu-hash is going away, all these packages compiled with --hash-style=sysv should be OK. Is the idea that these LD flags will be needed on ~mips from here on out?
nope, once the new binutils is released the sysv hash will be the default for mips, so you can drop it from your LDFLAGS. all the packages you have built with --hash-style=sysv will also continue to work correctly.
dropped with binutils-2.18-r2
