This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.
See crosstool-NG for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Johannes, All, On Wednesday 17 October 2012 12:15:21 Johannes Stezenbach wrote: > > > On Mon, Oct 15, 2012 at 09:53:55PM +0200, Yann E. MORIN wrote: > > > > Here is an alternate implementation of debug-shell, that I was working on > > > > following your previous submission. > My patch had this test: > > + if [ -t 0 -a -t 6 -a -t 2 ]; then > + ... > + else > + CT_DoLog WARN "CT_DEBUG_CT_FIXUP_SHELL disabled due to I/O redirection" > + fi > > I haven't tested what happens if you run "c-ng build |& tee log" and > then try to run an interactive shell, but I guess it can't work? Right, I'll see what I can do to add ths check. > Then, I'm running in this: > > [INFO ] Checking C library configuration > [ERROR] You did not provide an eglibc config file! > [ERROR] > [ERROR] >> > [ERROR] >> Build failed in step '(top-level)' > [ERROR] >> > [ERROR] >> Error happened in: main[scripts/crosstool-NG.sh@585] > > > Current command (unknown), exited with error code: 1 > Please fix it up and finish by exiting the shell with one of these values: > 1 fixed, continue with next build command > 3 abort build > > ct-ng:~/tmp/tc/build> > > Where scripts/crosstool-NG.sh@585 is "for step in ${CT_STEPS}; do". > I guess we can live with that but since there is no command > to fix or re-run it is a bit odd. That's the question: for commands that are not run via CT_DoExecLog, do we want to spawn the debug-shell anyway, even if we can't display the command that failed? My opinion is: yes, because we ant to debug the fscking b!tch, even it it means a bit of rummaging... At least, with the location in the error message and/or the last INFO line of the log, it should be relatively easy to find the real location of the original error. And remember that the debug-shell is just that: a debug-shell. Stumbling across such a case can be fixed by adding a CT_DoExecLog in front of the offending command. In this specific case, I don't see what's wrong after just a quick glance, but I think it's better to fix CT_TestOrAbort (and the likes) to properly fail. I'll look at it tonight, when back home. Thanks for the review! Regards, Yann E. MORIN. -- .-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +0/33 662376056 | Software Designer | \ / CAMPAIGN | ^ | | --==< O_o >==-- '------------.-------: X AGAINST | /e\ There is no | | http://ymorin.is-a-geek.org/ | (*_*) | / \ HTML MAIL | """ conspiracy. | '------------------------------'-------'------------------'--------------------' -- For unsubscribe information see http://sourceware.org/lists.html#faq
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |