Date: Fri, 18 Jul 1997 14:06:34 +0930 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: Shimon@i-Connect.Net (Simon Shapiro) Cc: msmith@atrad.adelaide.edu.au, freebsd-current@FreeBSD.ORG Subject: Re: Errors (?) in building -current Message-ID: <199707180436.OAA04090@genesis.atrad.adelaide.edu.au> In-Reply-To: <XFMail.970717212105.Shimon@i-Connect.Net> from Simon Shapiro at "Jul 17, 97 04:41:26 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Simon Shapiro stands accused of saying: > > > > Um, are you building on an SMP machine, or with some degree of > > parallelism enabled? > > One of the machines is SMP, both are running UP kernel (one is 2.2 one is > -current. Ok. You don't have a "-j 4" anywhere on your make commandline? > > > ===> lkm/syscons/fade > > > install -c -o bin -g bin -m 555 fade_saver_mod.o /lkm > > > fcns.c:49: initializer element for `el_func[88]' is not constant > > > fcns.c:49: `vi_zero' undeclared here (not in a function) > > > fcns.c:49: initializer element for `el_func[89]' is not constant > > > In file included from editline.c:21: > > > /usr/src/3.0/src/lib/libedit/vi.c:674: warning: type mismatch with > > previous > > > impl > > > icit declaration > > > /usr/src/3.0/src/lib/libedit/common.c:114: warning: previous implicit > > > declaratio > > > n of `vi_command_mode' > > > /usr/src/3.0/src/lib/libedit/vi.c:674: warning: `vi_command_mode' was > > > previously > > > implicitly declared to return `int' > > > /usr/src/3.0/src/lib/libedit/vi.c:674: warning: `vi_command_mode' was > > > declared i > > > mplicitly `extern' and later `static' > > > *** Error code 1 (continuing) > > > > Care to tell me what is actually trying to compile fcns.c immediately > > after > > _installing_ the syscons fader LKM? > > I am really dumb when it cones to gigantic makes. I cd;make world;email > failure :-) Well, I dunno what's going on then; you appear to have some -serious- problems though. > > From _my_ -current build last night, fresh CVSup, cvs co -Pd : > > I always do (was told to) do cvs update, not cvs checkout. Does that > make a difference? Yes, when I give peopled bad information like that, they send me more mail. 8) You're quite right; it should have been 'update' not 'checkout'. > I went as far as removing the entire CVS tree (helped some), removing all > of /usr/obj (helped some others) and removing all of /usr/src (helped none). You're having a _lot_ of trouble with this; I can count on the fingers of one hand the number of times that I've had to do that sort of stuff in the last ~3 years. > This is what I am left with. Looks to me that I am not intelligent enough > for this process. I seem to have endless problems with it. It works well I think there is something circumstantial that is laying you low. > > You appear to have disk or memory corruption problems. common.h is > > automatically generated during the build (eep, this is Bad), and > > should look like : > > > > /* Automatically generated file, do not edit */ > > #ifndef _h_common_c > > #define _h_common_c > > protected el_action_t ed_end_of_file __P((EditLine *, int)); > > protected el_action_t ed_insert __P((EditLine *, int)); > > protected el_action_t ed_delete_prev_word __P((EditLine *, int)); > > Two separate machines? Both having the same corrupted memory? Four I don't know, Simon. All I _do_ know is that common.h should look like the above (it would help if you checked to make sure it did), and that a working compiler will digest the above correctly. I was running the same build process over what should have been almost the exact-same sources at almost the same time, and it worked just fine here. No magic, nothing special at all. This gives me reasonable confidence that those components _do_ work. What I'm trying to do is prod you to look more closely at the components of the problem rather than the failure of the entire process. -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199707180436.OAA04090>