On Lunes 27 Abril 2009, Matthew D. Swank wrote:
> On Mon, 27 Apr 2009 11:23:53 +0200
> Gábor Melis <mega@...> wrote:
> > On Domingo 26 Abril 2009, Matthew D. Swank wrote:
> > > > There is something else going on. Though the conditionals I
> > > > highlighted in run-program should probably be changed, I
> > > > reversed Gabor's patch (with the attached), and I still had the
> > > > same contribs fail.
> > > >
> > > > *sigh*
> > > >
> > > > The win32 build seems so fragile.
> > > >
> > > > Matt
> > >
> > > Sorry: this patch reverses Gabor's.
> > Maybe something is not getting cleaned. If running clean.sh before
> > make.sh does not help then a can you test the
> > > > (unless (= child -1)
> > > > (setf proc
> > > > ...
> > > > (when (= child -1)
> > > > (error
> > variant on a fresh checkout?
> Done. Contribs still fail.
> I tried rebuilding my current version of sbcl (184.108.40.206) with itself.
> In addition, I tried rebuilding 1.0.24 with 1.0.22. In each case the
> contribs failed. In each case I previously built these versions w/o
> incident. I think the run-program patch is a red herring. I had
> considered that it was something with my setup, but I have reproduced
> the problem on more than one pc. Also, I am not the only one
> reporting this behavior.
> I think something has changed in windows or the version of mingw that
> comes with cygwin that makes it impossible for sb-grovel to do its
> It would be helpful if someone else could test this. I challenge
> anyone to build a recent version of sbcl on an up-to-date
> installation windows(32) that successfully builds sb-posix and
> sb-bsd-sockets as well!
I checked in "(unless (= child -1)" as 220.127.116.11 which fixes run-program
for some. According to nyef you are having issues with cygwin and he
has a fix planned but for this release. The relevant part of the #lisp
16:02:53 <_3b> nyef: is your mingw/gcc/whatever recent?
16:03:42 --- quit: mrsolo_ (Read error: 110 (Connection timed out))
16:04:08 <nyef> Installed earlier this year, FWIW. Why?
16:04:23 <nyef> Having contrib build problems all over the place?
16:04:25 <_3b> nyef: (unless (= child -1) ...) fixes the contribs for me
too, but my mingw install is old, wonered if that was related
16:05:19 <nyef> Well, I actually build from cygwin, and I -know- that
the default setup can't build contribs because the gcc is messed up.
16:05:44 <_3b> default setup on cygwin?
16:06:00 --- quit: tritchey (Read error: 110 (Connection timed out))
16:06:14 <nyef> Yeah, it's a symlink to a symlink.
16:06:29 <nyef> And they're cygwin symlinks, so SBCL run-program chokes
16:06:50 <nyef> So I patch asdf-module.mk or whatever it is to say
CC=gcc-3, and it all works again.
16:06:52 <_3b> wonder if that is the problem the person on sbcl-devel is
having, he seems to use cygwin also
16:07:26 <nyef> If that happens to be the case, then they should still
have the same problem with the last major release.
16:07:27 <_3b> if so, that should probably be documented somewhere :)
16:07:45 <nyef> What, that cygwin is broken? I thought everybody knew
16:07:55 <_3b> he can't build .22 or .24 either
16:07:56 --- quit: alec ("Leaving")
16:08:21 <nyef> 1.0.22 or 18.104.22.168?
16:08:27 --- join: mrsolo_ (n=mrsolo@...)
16:08:30 <_3b> 1.0.22, 1.0.24
16:09:24 <nyef> In that case, I'd recommend he have a look (via ls -l)
at `which gcc` and see if it's a link. If it is, chase down the correct
executable and set it up in asdf-module.mk or whatever the file is.
16:09:29 --- quit: dwave (Read error: 110 (Connection timed out))
16:10:03 --- join: hugod
(n=hugod@...) joined #lisp
16:10:42 --- quit: fe[nl]ix ("Valete!")
16:11:04 --- join: fe[nl]ix (n=algidus@...)
16:12:09 <sepult> am i a server
16:13:01 <nyef> Okay, got a potential fix... But I'm not planning to
check it in during freeze, as it's actually a new behavior. :-P
16:13:24 <_3b> for the cygwin build stuff?
16:13:28 <nyef> Yup.
16:13:38 <nyef> Wait, you have mingw, don't you?
16:13:52 <_3b> right, i build from msys
16:14:02 <nyef> Can you "readlink -f `which gcc`" at the shell prompt
and tell me what you get?
16:14:31 <_3b> nothing
16:14:31 <nyef> (The actual use will be -fn, to elide the trailing
16:14:38 <nyef> Nothing?
16:14:54 <nyef> It -should- give a path to gcc, whatever it's called.
16:15:49 <_3b> yeah, nothing... i think it gets confused since it is
16:16:05 <_3b> or not, doesn't work with .exe either
16:16:37 <nyef> Wonderful.
16:16:42 <_3b> ah, my readlink is from gnuwin32, that might be a problem
16:17:17 <nyef> And people wonder why I don't like to involve the C
compiler in building my Lisp stuff...
16:18:31 <_3b> well, arguably the fault in this case is involving random
16:18:53 <nyef> So, a conditional readlink based on if the build
environment is cygwin, maybe?
16:18:55 --- join: srcerer (n=chatzill@...) joined
16:19:07 <_3b> sounds reasonable
16:19:24 <nyef> Sounds icky, really.
16:19:29 <_3b> well, that too
16:19:50 <_3b> but is is a cygwin specific problem, so reasonable to
limit the fix tothat
16:19:52 <nyef> So, -definately- not getting floated for inclusion
16:20:22 <_3b> yeah, wasn't conditionalizing scripts on cygwin breaking
everyone else's build lately? :)
16:22:55 --- quit: akcom (Read error: 60 (Operation timed out))
16:22:56 --- quit: ferada ("ERC Version 5.2 (IRC client for Emacs)")
16:23:55 <nyef> Even if it wasn't, we're talking about a build-system
change, which is always chancy, in the freeze period (which ends in,
what, four days time?) for one build environment that isn't even the
only build environment for the target, when there's a known workaround?
16:24:01 --- quit: disumu ("...")
16:25:07 <_3b> random google hit claims readlink isn't available on
solaris 10 also for that matter
16:26:40 <_3b> though another claims msys does have it, so possibly my
install is just too old
16:26:47 --- quit: athos ("leaving")
16:29:12 <nyef> I'm going to go with the "worry about it on friday"
16:29:24 <_3b> sounds like a good plan
16:32:16 --- join: never_where (n=user@...) joined #lisp
16:32:46 <nyef> Besides, if we leave it, we might come up with better
make-fu than I currently have for it.